Scaling geo-replicated databases to the MEC environment Alejandro Z. Tomsic, Tyler Crain and Marc Shapiro LIP6 (INRIA/UPMC)
[email protected] [email protected] [email protected] Abstract— The Mobile-Edge Computing standard promises co-locating edge servers with mobile phone base stations. Web services running on this new ecosystem will have to address the challenges of this new model in order to see its benefits. In this work, we briefly discuss design guidelines for scaling strongly consistent geo-distributed databases to the MEC environment. Following these guidelines, we present the design of a MEC database tailored for a specific kind of web services and a protocol for ensuring transactional non-monotonic snapshot isolation (NMSI) at MEC scale.
I. INTRODUCTION The use of mobile devices such as smartphones and tablets is rapidly expanding to the vast majority of the human population [2]. Cellular network technologies continuously bring new services and improve interaction between users and Internet-served content. Their development focuses, among other goals, on reducing latency and increasing availability and bandwidth. Future networks promise to bring along the tactile Internet, where the latency of a user perceived interaction will be 1ms; the response of human tactile to visual feedback control [19]. On the road to the tactile internet, there is MobileEdge Computing (MEC), a recently defined ETSI (European Telecommunications Standards Institute) standard. MEC aims at providing cloud-computing capabilities and an IT service environment at the edge of the mobile network, within the RAN (Radio Access Network) [18]. I.e., commodity or specifically-designed edge servers will be co-located with cellular base stations [20], [24]. A key proposition of the MEC standard is to create an open environment, where mobile phone carriers open the edge infrastructure to third-party web service providers [18], allowing them to deploy application components at possibly millions of edge servers, close to the user. Such new scenario will help improve QoE of existing applications (e.g., reduced latency, increased availability and contextaware tuning, among others), and the proliferation of new types of applications. In this work, we introduce locallyrelevant web services (LRWS), a kind of application we believe is naturally leveraged by the MEC environment. In LRWSs, users mostly interact with data which is strongly relevant to her current geographical location. Web services present a layered architecture, normally comprised of the front-end, the application logic, and the database. Web service providers typically install multiple
copies of these components at a number of data centers (DCs) situated at different locations around the globe. This technique, called geo-replication, is attractive for (i)scalability; as more DCs allow for globally processing more operations per time unit, (ii)low latency; as users connect to their closest DC, reducing round-trip times, and (iii)highavailability; as users connected to a failed DC can fail-over to an operational one. A challenging task when building geo-replicated databases is to provide strong consistency, allowing web services to access data in a manner similar to how they would in a centralised database. This is an important requirement as relaxing consistency directly penalises ease of programmability of the application logic. In a geo-replicated environment, network partitions are unavoidable and, as the CAP theorem proves, such condition prevents these systems from achieving strong consistency and high-availability (and low latency) together [21]. In the past few years, multiple systems have been designed for addressing the issues of database replication while exploring the spectrum of consistency vs. availability and performance in DC deployments [3]–[5], [8], [11], [12], [15], [17], [25], [28], [29], [34], [36]. Differently from these geo-replicated DC database implementations, content delivery networks (CDNs) further improve scalability, availability and latency by using georeplication at a larger number of points of presence. These CDNs have evolved from acting as mere static content caches to host application logic and even database components [10], [14], [22], [27], [30]–[32], [35]. Unfortunately, as our related work section (Section V) summarises, there is no existing DC or CDN distributed database’s design able to scale to the MEC environment. In this work, we study how to architecture a geo-replicated database to be deployed in a MEC ecosystem, i.e., at a large number of sites, while providing full-functionality, low latency, high-availability, and strong consistency. When considering LRWSs, we identify the importance of having the geographically relevant data only take updates at the edge, allowing fast and consistent access for nearby users, but lowering availability and penalising latency for users who wish to update distant data. We find that NMSI (non-monotonic snapshot isolation), a state of the art of transactional consistency criterion, is the most appropriate consistency for LRWSs under MEC [5]. NMSI presents the programmer with strong semantics which, while weaker than
serialisability and snapshot-isolation (SI), are still easy to reason about, while its definition allows for the most scalable implementations. A. Intorducting the MEC ecosystem There are three stakeholders involved in the MEC ecosystem: (i)mobile devices, that are used by end-users to interact with their applications, (ii)network operators owning, managing, and operating base stations, MEC servers, and the mobile core network, and (iii)application service providers (ASPs) hosting applications within edge servers, data centers and content delivery networks (CDN). Mobile devices (UE) connect to the mobile base stations through high-speed (e.g., LTE) links. MEC Servers are colocated with base stations. ASPs can deploy components of their applications at MEC servers. MEC-to-DC network connections are of variable (normally limited) bandwidth. MEC servers receive user requests that they either process and respond directly to the mobile devices, or the request is forwarded to remote data centers. B. Non-Monotonic Snapshot Isolation Snapshot isolation (SI) is a popular isolation level provided by commercial database systems such as Oracle and SQLServer [9]. It guarantees that transactions read from a snapshot that reflects a single (total) commit ordering of transactions, preventing write-write conflicts. Transactions under SI take a strictly consistent snapshot (SCONS) when they start [6], which satisfies two properties: (i) the snapshot represents the state of the database at a given point; and (ii) it includes the effects of all transactions that have committed up to that point. Parallel snapshot isolation (PSI) is a weakened version of SI that allows different sites to present different commit orders for transactions that modify disjoint sets of objects [36]. A transaction under PSI takes a consistent snapshot (CONS) at its starting point. A CONS does not satisfy the second property of a SCONS, i.e., it does not include the effects of all transactions before that point, but only the ones of transactions that causally precede it [26]. This relaxation enables asynchronous replication of updates; a transaction can commit without coordination and asynchronously propagate its updates to the remaining replicas. Non-monotonic snapshot isolation (NMSI) makes a further relaxation over SI (and PSI); it lets a transaction snapshot violate both properties of a SCONS. I.e, A transaction is allowed to take a CONS that advances while the transaction executes, as long as there are no update operations that generate conflicts or violate causality. Allowing a transaction to see the effects of transactions committed after its starting point is called forward freshness. This means that snapshots are not frozen when transactions begin (base freshness). Forward freshness allows NMSI to avoid more write-write conflicts than PSI and SI, which reduces the transaction abort rate, favouring scalability [6]. Finally, NMSI does not introduce any new consistency anomalies over PSI and, therefore, it does not affect ease of programmability [5].
NMSI’s relaxations over snapshot isolation are acceptable for web services where each user communicates with one site at a time and there is no need for a global ordering of all actions across all users (in contrast, snapshot isolation requires the same ordering at all sites) [5], [36]. This is particularly the case for locally-relevant web services, as we will explain in Section III. II. S CALING TO THE MEC ENVIRONMENT Distributed systems find their performance and infrastructure scalability limits in communication and storage overheads. In this section, we discuss how to scale database replication (subsection II-A) and the enforcement of strong consistency (subsection II-B) to MEC, i.e., where the number of sites grows unbounded. A. Replicating to a large number of sites To replicate a database is to store multiple copies of its data items at multiple sites. We argue that in order to scale, a replicated system should respect the following design guidelines: 1) Partial replication. Even when simple, full-replication is not scalable [7], [8], [13], [34], [37], as it requires storing a full copy of the database at each site. Furthermore, every update operation is shipped to every site. As a consequence, full replication is costly both in terms of storage and communication. Partial replication aims at reducing the scalability bottlenecks of fullreplication. Under partial replication, each site stores only a subset of the database. Nevertheless, partial replication generates overhead in the form of metadata for keeping information regarding which part of the database each site replicates [8]. We discuss that, for unlimited scalability, simple partial replication does not suffice. 2) Bounded replication factor. The replication factor is the number of times an object is replicated throughout the system. The number of sites storing an object cannot be arbitrary, as this translates into significant overhead for transferring updates to each replica, storing an arbitrary number of times the same items, and metadata to keep replication information. 3) Structured data clustering and data placement. A cluster represents a set of data items to be replicated together. It is the minimum replication unit. If there is no structure on how data is clustered and at which sites clusters are stored, maintaining information on which replicas store which data items becomes a hard and expensive task. For achieving scalability, the way data is clustered and placed needs to be structured. 4) Bounded clustering and data placement dynamism. Mechanisms for dynamic clustering and data placement aim at modifying how data is arranged in clusters and at which sites clusters are stored according to changing conditions, like access patterns, in order to optimise performance according to different metrics, e.g., user access latency. When the number of replicas
is in the order of millions, dynamic clustering can generate unbearable traffic overhead for rearranging data placement and maintaining replication information. B. Scaling NMSI Enforcing consistency poses additional constrains on distributed databases. I.e., it introduces a new source of overhead; synchronisation. In order to scale, a system ensuring NMSI should further follow these design guidelines: 5) Bounded number of replicas taking updates. NMSI ensures that if concurrent transactions exhibit write-write conflicts, one will abort. This means that transactions containing update operations need to synchronise with all replicas able to take updates to ensure that this property is not violated. This introduces a latency and an availability issue as this check is performed in the critical path of the transaction. Reducing the number of replicas that can take updates for a given object reduces this penalty. 6) Bounded metadata for tracking causal dependencies. A system that takes causally-consistent snapshots (CONS) needs to track causal dependencies. For that purpose, existing systems incur in variable sized metadata [4], [5], [16], [17], [28], [29], [36], [37] which is at best, in the order of sites. For handling a large number of sites, metadata size needs to be kept as small as possible. 7) Genuine partial replication (GPR). In brief, this property states that for executing a transaction, only sites that replicate data items read or written by the transaction exchange messages [33]. NMSI has been proven to achieve GPR along with wait-free read-only transactions and non-blocking updates [5]. 8) Disjoint clustering The above two guidelines require that clusters are disjoint, i.e., that each object belongs to a single cluster. Otherwise, keeping and sending causality metadata becomes cumbersome and prevents systems from achieving GPR [5]. This fact further constrains guideline 3. In the next section, we will see in which of these points current state-of-art systems do not comply. C. State-of-art systems’ scalability 1) Walter (PSI): To implement PSI, Walter [36] relies on preferred sites. The system assigns each object to a preferred site, where objects can be updated without synchronisation. Other sites can perform updates but need to synchronise with all remaining replicas. Walter finds its scalability limits in the following design properties: Walter does not achieve GPR. After finishing a transaction, a site needs to propagate metadata to all remaining sites, regardless of the fact that some sites do not host objects involved in the transaction. Furthermore, Walter has an unbounded replication factor, requires metadata in the order of sites, and allows any arbitrary structure for data partitioning and placement.
2) Jessy (NMSI): Jessy implements NMSI [5]. Like Walter, Jessy employs deferred update replication: transactions are executed optimistically, then certified by a termination protocol. To implement NMSI and achieving GPR while using atomic multicast, Jessy resorts to disjoint replicas. Limiting its scalability, Jessy requires causality metadata in the order of objects or, at best, partitions (clusters) in the system. Additionally, its implementation is limited to having disjoint sets of partitions at a each site, otherwise needing reliable failure detectors (which assumes a synchronous system). Furthermore, it allows an unbounded number of replicas to take updates for an object and has an unbounded replication factor. In Section IV we describe the design of our system that respects the presented scalability guidelines and circumvents the mentioned existing protocol’s issues, but first let us introduce our target applications. III. L OCALLY- RELEVANT WEB SERVICES (LRWS) Locally-relevant web services are location-based services (LBS) that provide users with content that is relevant to their geographical position. LBS take as input the user position in order to provide more accurate results. LRWS have one distinctive characteristic; data is location-centric, and not user-centric (as, for instance, in a social network). This means that a user can interact with data which is relevant to its immediate surrounding with more accuracy and better performance than with data which is related, for instance, to another country. To illustrate a LRWS, we will consider a taxi booking application. As we develop the example, we will discuss what consistency criterion operations might need, and why MEC is a natural platform for efficiently implementing LWRSs. a) Taxi booking web service: Motivated by the popular Uber taxi service [1], the example of a locally-relevant taxi web service using the MEC environment could do more than sending a simple reservation to the taxi dispatch. Both the taxi drivers and the clients interact with the service through their smartphones. Drivers will use the application to register their taxi with the service, while clients will use the application to book the taxis. b) Up to date view of local data: The main use of the application is booking a taxi. In this situation the taxi driver will be continuously updating his status on the edge server, allowing clients to view nearby taxis that are available and their location on the map. While this information does not necessarily need to be displayed with low latency, doing so will improve clients’ experience as they can view the location of taxis with near real time precision and his reservation requests are less likely to conflict with concurrent requests. Additionally, this can be done without interacting with the application’s DC, allowing the application to work even when an ES is disconnected from the rest of the network. c) Efficient atomic and consistent updates to local data: Reserving a taxi should be an atomic operation changing a taxi from available to booked and assigning a client to this taxi. With strong consistency allowing transactions
across multiple objects, this can be ensured safely with little programming effort. d) View of both local and non-local data: When planning a route, traffic information should be used to ensure the destination is reached in the shortest amount of time possible. Viewing the status of traffic data further away from the taxi shouldn’t necessarily require strong consistency. For example, if each taxi driver observes traffic updates at his local edge server faster than those applied to external servers, then a total order of updates in the system might be violated, yet this does not break the application’s correctness. In fact, concurrent traffic updates coming from different sources at different locations do not have a meaningful total order and, therefore, imposing a total order among these updates would require unnecessary synchronisation. Instead, causal ordering across edge servers would be sufficient. e) Updates to non-local data: An ES will not always be able to execute updates locally. For example, a DC might store profiles for clients and drivers, allowing a client or driver to leave a review about the other after the trip has completed. By ensuring consistency between these events users will not be able to post reviews for trips they did not make. Additionally, a record of all transactions would be kept at the DC for record keeping purposes. This kind of long lived data that needs to be stable and that does not need low latency access is more likely to be kept at the DC where there are more storage and computing resources. IV. S YSTEM OVERVIEW In this section we present a basic overview of a distributed database tailored for LRWS under the MEC model, devised with the following features in mind: • Low latency. In line with MEC’s design goals, the database executes local transactions with minimal latency for improving user experience. • Disconnected operation. An edge server should be able to remain functional in case of being disconnected from the backbone network and continue to execute transactions that affect its partition. • Scalability. It should scale to be scattered across a large number of servers. Hence, it should follow the design guidelines presented in Section II. • Strong Consistency. In order to provide application logic programmers with semantics that allows them to easily reason about the system, the database implements a transactional NMSI protocol. A. System model We assume a multi-tiered system (see Figure 2), consisting of clients, edge servers, and a set of data centers (DCs). Mobile clients issue transactions. They interact with the application exclusively through their closest edge-server (ES). Edge servers (ES) are co-located with mobile base stations. We consider ESs to be single servers or small clusters that connect to a DC and replicate a subset (partition) of the database. A partition (a set of data clusters) is defined by
Fig. 1.
System overview
a server’s location and contains the information of its zone, i.e., its geographical surroundings. In figure 2, there are four geographical zones, each of them containing an ES storing the zone’s data and serving user requests. The partitions each of these servers store are disjoint, i.e., no pair of edge servers replicate the same content. Each ES asynchronously propagates updates to one data center. ESs can serve reads from and apply updates to their local partitions without synchronising with any other server or data center, i.e., they act as the preferred site of the partition they store. If an operation targets data item(s) not replicated at an ES, the ES executes the operation at its data center, Data centers store a number of partitions, but not necessarily a full-copy of the database (partial replication). A DC synchronises with the ESs that connect to it and acts as the primary DC of the partitions those ESs replicate. A primary DC can take update requests to a partition from ESs that do not replicate that partition. E.g., DC1 can take updates to partition 1 from ES2, ES3 and ES4, but in order to apply those updates, it needs to synchronise with the partition’s preferred site; its ES (ES1 in our example). If a DC receives an update operation for an object stored in a partition it is not primary of, it forwards it to its primary. For example, in Figure 2, DC1 acts as primary DC for partitions 1 and 3, as ES1 and ES3 are connected to it; DC2 is the primary DC of partitions 2 and 4 for the same reasons. Note that in the presence of a network partition, only a partition’s ES (preferred site) can continue to perform updates. This is a design choice driven by the preference of providing disconnected operation to users connected to a given ES, where locally-relevant content is stored. B. NMSI Transactional Protocol Preferred sites and primary DCs are critical for implementing NMSI while scaling. Their use reduces the probability of write-write conflicts and synchronization in the system. Our system ensures SI per edge server (partition), meaning that at each ES, updates are totally ordered. Across DCs, we are working on a variant of our ongoing work, Antidote [23], which supports NMSI and partial replication [13]. Our protocol takes consistent snapshots supporting forward freshness across partitions that reduces causality-tracking metadata to the order of DCs, and not of sites. Clients execute read and update operations within transactions. A client’s ES acts as a transaction’s coordinator. They interact with the database through the following operations:
T ← startT x(Vl ) starts a new transaction. It takes as parameter the latest version (a scalar value) the client has seen from the database (Vl ) to ensure that a the transaction includes the database state this client has already seen and returns a transaction descriptor T . • [v, deps] ← read(k, T ) takes as input a key k and a transaction descriptor T and returns an object’s value v, satisfying T ’s dependencies, and updates the transaction dependencies accordingly for not violating causality. • ok ← update(k, v, T ) buffers the update at the coordinator. • {[ok, Vl ]|abort} ← commit(T ) commits the transaction T . It first propagates updates to all partitions and returns ok and an updated Vl in case there are no writewrite conflicts, or error otherwise. Client transactions that operate over objects stored at their local ES commit locally, ensuring SI, with no synchronisation and, therefore, with minimal latency. Given the nature of LRWSs, we expect this to be the normal case. Updates are propagated to the ES’s primary DCs in the background, where transactions are assigned a causal order between sites. Reads performed on non-local objects are forwarded to the DC, where a causally consistent version is returned. A transaction executing operations on objects at multiple partitions respects NMSI. I.e., when performing updates to a non-local site these transactions execute slower as they need to contact a DC, that in turn has to synchronise with the preferred ESs updated in the transaction. When a transaction updating multiple partitions is submitted for termination, there is a two-phase commit protocol run across the partitions holding updated objects. 1) Durability: A failure of an ES can cause the loss of updates that have not yet been propagated to the DCs. This is a design choice that favours low-latency and disconnected operation over durability. When durability is necessary for certain operations/objects, our commitment protocol can be augmented with a two-phase commit phase among the ES and its primary DC or neighbour ESs. •
[8], [12], [15], [25], [28], [29], [34], [36], they are targeted for full- or partial-replication in a data center, where the number of replicas is in the order of tens. As their design is not suited for scaling to a large number of sites, they are not suitable for MEC. Swiftcloud [37] is a causally consistent database that provides partial replication at clients and full-replication across DCs. This system focuses mainly on how to provide off-line operation, durability, and DC roaming where clients exhibit frequent and long periods of disconnection. Swiftcloud allows each data center and client to commit update transactions locally and to lazily propagate updates to replicas, thus favoring availability over strong consistency. Content Delivery Networks (CDNs) are used by major internet applications such as Facebook and Amazon to cache content in edge clouds, close to the end users [30]. These solutions tackle many of the challenges of providing low latency and high-availability when provisioning content. Nevertheless, they do not address the issue of placing fullyfunctional database replicas at the edge. This penalises availability, latency and scalability. Lin et. al [27] propose moving full replicas of the database to CDNs. In order to provide the desired consistency guarantees, write operations incur in a two-phase commit (2PC) protocol that involves all replicas of the database. The fact that each replica replicates a full-copy of the database and that every replica in the system participates in the 2PC protocol poses serious latency, scalability, and availability issues. Sivasubramanian et. al [35] propose a mechanism for automatically clustering data items according to access patterns. Clients are able to read possibly-outdated eventuallyconsistent snapshots of the objects. In this solution, data-item clustering, cluster placement, and cluster primary replica are dynamic, and pose the need of tracking and communicating such information throughout the network, limiting the scalability. VI. C ONCLUSIONS AND F UTURE W ORK
C. Respecting scalability guidelines The presented design follows the design guidelines introduced in Section II-A. First, the database is partiallyreplicated; both at the DCs and the ESs. Second, ESs replicate disjoint sets of objects that are statically defined by their geographical position. Furthermore, there is a hierarchical replication scheme with a clear distinction of ESs from DCs. These two factors simplify maintaining replication metadata. Data clustering and data placement are, in principle, static and, therefore, bounded. For a given object, a bounded set of replicas can process updates. Namely, the system only takes updates at two sources; it’s preferred site (a SE) and its primary DC.
The MEC environment will introduce the possibility for application providers to interact with possibly millions of edge servers deployed in the user’s immediate proximity, but the designs of existing web services’ databases do not scale to such a large number of server replicas. In this initial work, we have discussed design guidelines for systems tailored for the MEC environment, as well as introduced locally-relevant web-services, and proposed a new data store architecture. This is work in an early stage and we foresee the following directions of future work: • •
V. R ELATED W ORK Database replication is a well-known technique for achieving high-availability, fault-tolerance, low latency and scalability. Even when many geo-replicated systems exist [3], [5],
•
Finish the definition and implementation of our transactional protocol and perform an extensive evaluation. Better defining use-cases for the MEC model and a deeper analysis for extracting their requirements in terms of consistency guarantees. Devise new design guidelines for scalable systems and perform an analytical and empirical study.
Introduce client roaming and dealing with the case of a client in range of multiple edge servers. • Consider ES failures and mobile clients failing over to neighbour ECs. The research leading to these results has received funding from the European Union Seventh Framework Programme (FP7/2007-2013) under grant agreement no.609551. •
R EFERENCES [1] Uber. https://www.uber.com. [2] Ericsson mobility report, June 2015. [3] M. K. Aguilera, A. Merchant, M. Shah, A. Veitch, and C. Karamanolis. Sinfonia: A new paradigm for building scalable distributed systems. ACM Trans. Comput. Syst., 27(3):5:1–5:48, Nov. 2009. [4] S. Almeida, J. a. Leit˜ao, and L. Rodrigues. Chainreaction: A causal+ consistent datastore based on chain replication. In Proceedings of the 8th ACM European Conference on Computer Systems, EuroSys ’13, pages 85–98, New York, NY, USA, 2013. ACM. [5] M. S. Ardekani, P. Sutra, and M. Shapiro. Non-monotonic snapshot isolation: Scalable and strong consistency for geo-replicated transactional systems. In Proceedings of the 2013 IEEE 32Nd International Symposium on Reliable Distributed Systems, SRDS ’13, pages 163– 172, Washington, DC, USA, 2013. IEEE Computer Society. [6] M. S. Ardekani, P. Sutra, M. Shapiro, and N. Preguic¸a. On the scalability of snapshot isolation. In Proceedings of the 19th International Conference on Parallel Processing, Euro-Par’13, pages 369– 381, Berlin, Heidelberg, 2013. Springer-Verlag. [7] J. E. Armend´ariz-I˜nigo, A. Mauch-Goya, J. R. G. de Mend´ıvil, and F. D. Mu˜noz Esco´ı. Sipre: A partial database replication protocol with si replicas. In Proceedings of the 2008 ACM Symposium on Applied Computing, SAC ’08, pages 2181–2185, New York, NY, USA, 2008. ACM. [8] N. Belaramani, M. Dahlin, L. Gao, A. Nayate, A. Venkataramani, P. Yalagandula, and J. Zheng. Practi replication. In Proceedings of the 3rd Conference on Networked Systems Design & Implementation - Volume 3, NSDI’06, pages 5–5, Berkeley, CA, USA, 2006. USENIX Association. [9] H. Berenson, P. Bernstein, J. Gray, J. Melton, E. O’Neil, and P. O’Neil. A critique of ansi sql isolation levels. In Proceedings of the 1995 ACM SIGMOD International Conference on Management of Data, SIGMOD ’95, pages 1–10, New York, NY, USA, 1995. ACM. [10] E. Cecchet, J. Marguerite, and W. Zwaenepole. C-jdbc: Flexible database clustering middleware. In Proceedings of the Annual Conference on USENIX Annual Technical Conference, ATEC ’04, pages 26–26, Berkeley, CA, USA, 2004. USENIX Association. [11] B. F. Cooper, R. Ramakrishnan, U. Srivastava, A. Silberstein, P. Bohannon, H.-A. Jacobsen, N. Puz, D. Weaver, and R. Yerneni. Pnuts: Yahoo!’s hosted data serving platform. Proc. VLDB Endow., 1(2):1277–1288, Aug. 2008. [12] J. C. Corbett, J. Dean, M. Epstein, A. Fikes, C. Frost, J. J. Furman, S. Ghemawat, A. Gubarev, C. Heiser, P. Hochschild, W. Hsieh, S. Kanthak, E. Kogan, H. Li, A. Lloyd, S. Melnik, D. Mwaura, D. Nagle, S. Quinlan, R. Rao, L. Rolig, Y. Saito, M. Szymaniak, C. Taylor, R. Wang, and D. Woodford. Spanner: Google’s globally distributed database. ACM Trans. Comput. Syst., 31(3):8:1–8:22, Aug. 2013. [13] T. Crain and M. Shapiro. Designing a causally consistent protocol for geo-distributed partial replication. In Proceedings of the First Workshop on Principles and Practice of Consistency for Distributed Data, PaPoC ’15, pages 6:1–6:4, New York, NY, USA, 2015. ACM. [14] A. Davis, J. Parikh, and W. E. Weihl. Edgecomputing: Extending enterprise applications to the edge of the internet. In Proceedings of the 13th International World Wide Web Conference on Alternate Track Papers &Amp; Posters, WWW Alt. ’04, pages 180–187, New York, NY, USA, 2004. ACM. [15] G. DeCandia, D. Hastorun, M. Jampani, G. Kakulapati, A. Lakshman, A. Pilchin, S. Sivasubramanian, P. Vosshall, and W. Vogels. Dynamo: Amazon’s highly available key-value store. In Proceedings of Twentyfirst ACM SIGOPS Symposium on Operating Systems Principles, SOSP ’07, pages 205–220, New York, NY, USA, 2007. ACM. [16] J. Du, S. Elnikety, A. Roy, and W. Zwaenepoel. Orbe: Scalable causal consistency using dependency matrices and physical clocks. pages 11:1–11:14, Santa Clara, CA, USA, Oct. 2013.
[17] J. Du, C. Iorgulescu, A. Roy, and W. Zwaenepoel. Gentlerain: Cheap and scalable causal consistency with physical clocks. In Proceedings of the ACM Symposium on Cloud Computing, SOCC ’14, pages 4:1– 4:13, New York, NY, USA, 2014. ACM. [18] ETSI. Mobile-Edge Computing - Introductory Technical Paper, 1 edition, September 2014. [19] G. Fettweis. The tactile internet: Applications and challenges. Vehicular Technology Magazine, IEEE, 9(1):64–70, March 2014. [20] G. Fettweis, W. Nagel, and W. Lehner. Pathways to servers of the future: Highly adaptive energy efficient computing (haec). In Proceedings of the Conference on Design, Automation and Test in Europe, DATE ’12, pages 1161–1166, San Jose, CA, USA, 2012. EDA Consortium. [21] S. Gilbert and N. Lynch. Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services. SIGACT News, 33(2):51–59, 2002. [22] T. Groothuyse, S. Sivasubramanian, and G. Pierre. Globetp: Templatebased database replication for scalable web applications. In Proceedings of the 16th International Conference on World Wide Web, WWW ’07, pages 301–310, New York, NY, USA, 2007. ACM. [23] A. https://github.com/SyncFree/antidote. [24] N. S. n. Intel. Increasing mobile operators’ value proposition with edge computing. 2013. [25] A. Lakshman and P. Malik. Cassandra: A decentralized structured storage system. SIGOPS Oper. Syst. Rev., 44(2):35–40, Apr. 2010. [26] L. Lamport. Time, clocks, and the ordering of events in a distributed system. Commun. ACM, 21(7):558–565, July 1978. [27] Y. Lin, B. Kemme, M. Patino-Martinez, and R. Jimenez-Peris. Enhancing edge computing with database replication. In Reliable Distributed Systems, 2007. SRDS 2007. 26th IEEE International Symposium on, pages 45–54, Oct 2007. [28] W. Lloyd, M. J. Freedman, M. Kaminsky, and D. G. Andersen. Don’t settle for eventual: Scalable causal consistency for wide-area storage with cops. In Proceedings of the Twenty-Third ACM Symposium on Operating Systems Principles, SOSP ’11, pages 401–416, New York, NY, USA, 2011. ACM. [29] W. Lloyd, M. J. Freedman, M. Kaminsky, and D. G. Andersen. Stronger semantics for low-latency geo-replicated storage. In Proceedings of the 10th USENIX Conference on Networked Systems Design and Implementation, nsdi’13, pages 313–328, Berkeley, CA, USA, 2013. USENIX Association. [30] E. Nygren, R. K. Sitaraman, and J. Sun. The akamai network: A platform for high-performance internet applications. SIGOPS Oper. Syst. Rev., 44(3):2–19, Aug. 2010. [31] C. Plattner and G. Alonso. Ganymed: Scalable replication for transactional web applications. In Proceedings of the 5th ACM/IFIP/USENIX International Conference on Middleware, Middleware ’04, pages 155– 174, New York, NY, USA, 2004. Springer-Verlag New York, Inc. [32] M. Rabinovich, Z. Xiao, and A. Aggarwal. Computing on the edge: A platform for replicating internet applications. In F. Douglis and B. Davison, editors, Web Content Caching and Distribution, pages 57–77. Springer Netherlands, 2004. [33] N. Schiper, P. Sutra, and F. Pedone. P-store: Genuine partial replication in wide area networks. In Proceedings of the 2010 29th IEEE Symposium on Reliable Distributed Systems, SRDS ’10, pages 214– 224, Washington, DC, USA, 2010. IEEE Computer Society. [34] D. Serrano, M. Patino-Martinez, R. Jimenez-Peris, and B. Kemme. Boosting database replication scalability through partial replication and 1-copy-snapshot-isolation. In Proceedings of the 13th Pacific Rim International Symposium on Dependable Computing, PRDC ’07, pages 290–297, Washington, DC, USA, 2007. IEEE Computer Society. [35] S. Sivasubramanian, G. Alonso, G. Pierre, and M. van Steen. Globedb: Autonomic data replication for web applications. In Proceedings of the 14th International Conference on World Wide Web, WWW ’05, pages 33–42, New York, NY, USA, 2005. ACM. [36] Y. Sovran, R. Power, M. K. Aguilera, and J. Li. Transactional storage for geo-replicated systems. In Proceedings of the Twenty-Third ACM Symposium on Operating Systems Principles, SOSP ’11, pages 385– 400, New York, NY, USA, 2011. ACM. [37] M. Zawirski, A. Bieniusa, V. Balegas, S. Duarte, C. Baquero, M. Shapiro, and N. Preguic¸a. SwiftCloud: Fault-tolerant georeplication integrated all the way to the client machine. Technical Report RR-8347, Aug. 2013.
