Horizontally Scalable Implementation of a Distributed DBMS Delivering Causal Consistency via the Actor Model
Abstract
:1. Introduction
- Data modelling constraints: CC DBMSs typically restrict themselves to key-value or abstract data type paradigms, limiting expressiveness.
- Developer-unfriendly interfaces: The current CC DBMS implementations often require bespoke application design tailored to their specific semantics, failing to shield developers from distributed computing complexities [11].
- Ecosystem incompatibility: The proprietary data formats employed by CC DBs create isolation, impeding interoperability with external data consumers.
2. Definitions
- Thread of Execution: Within a process P, if P performs a before b, then .
- Reads From: If operation b reads the result of a WRITE operation a, then .
- Transitivity: If and , then .
- Let and define a WRITE operation on a data item identified by key , in and , respectively.
- Let represent an operation that sets the value v to the data element identified by key k.
- Let .
- Let .
3. Literature Review
3.1. Causally Consistent Databases
3.2. Thespis
- The actor mathematical model for concurrent computation [22], which defines computation as a hierarchical society of “experts”. These communicate by passing messages asynchronously. An actor comprises (a) a mailbox to queue incoming messages; (b) the actor’s behaviour, which is the function that executes in response to the received messages; and (c) the actor’s state, which is the data that the actor holds at a given time. Actors process messages one at a time and operate within the scope of actor Systems [23], allowing for hierarchical formations.
- Event Sourcing (ES) [26], another software architectural pattern which defines that data modifications are recorded in terms of sequences of events. These events can be stored in an append-only event log and subsequently applied sequentially. This approach allows a system using ES to reconstruct its state at any point in time based on the recorded events.
3.3. The Design of D-Thespis
- The data centre clock, which serves as the source of truth that provides physical timestamps within its DC;
- The data cluster clock, which is the source of truth of the SVV within its DC;
- A scalable event log that provides key-based multi-record lookups, key-based event queueing, durability, key-level atomicity, key-level isolation and horizontal scalability;
- A version cache for operation concurrency, which is a cache layer installed in every DC. This layer preserves the latest causally consistent version of any data entity. The version stored in this cache layer is the one inferred by a READ operation within the same DC. This cache layer is also mutualised, such that all the nodes within a DC refer to a single cache layer. This promotes a higher cache hit ratio, i.e., the ratio of calls to the cache layer requesting data entities that are stored within the cache (cache hits) versus the total number of calls to the cache layer, including those that request data entities that are not stored in the cache (cache misses). The D-Thespis READ and WRITE operations are also tuned with cache maintenance functionality.
4. D-Thespis Implementation
- Key-based lookups are supported via the GET command, which runs efficiently in complexity;
- Key-based version storage is supported via the SET command, which also executes in complexity;
- Key-level atomicity and isolation are guaranteed since Redis executes all operations on a single thread [37]. Therefore, all operations are atomic and execute sequentially;
- Horizontal scalability is supported by Redis in different configurations (e.g., master–slave and Redis cluster) and can also be built in custom logic executing against stand-alone Redis databases.
- Key-based multi-record lookups are supported via the LRANGE command. This operation takes two positional values as arguments and returns the elements within the list that are stored at the given key and reside within the range of positions defined by the given arguments. The LRANGE operation has a computational complexity of , with N being the number of items in the list;
- Key-based event queuing is supported by the RPUSH command, which adds a new item to the end of the list corresponding to the event log of a particular data entity. RPUSH for a single item is an operation with complexity;
- Durability is supported given that two specific configurations are set for Redis, namely, ‘appendonly=yes’ and ‘appendfsync=always’;
- Key-level atomicity and isolation are guaranteed due to the single-threaded nature of Redis;
- Horizontal scalability can be supported by Redis as discussed for the cache layer in our definition of a version cache for operation concurrency [13].
5. D-Thespis Middleware Performance Evaluation
- DB_1S_1DC: An application that exposes the same REST API as D-Thespis, executing operations directly on the relational DBMS (DB), running on a single server (1S) in one data centre (1DC).
- DB_NS_1DC: The same as DB_1S_1DC but with the REST API running on multiple (N) servers (NS), while the relational DBMS runs on a single server.
- DT_1S_1DC_O: D-Thespis (DT) deployed on a single server (1S) within a single data centre (1DC) using the Microsoft Orleans actor framework (O), enabling concurrent READ operations over cached data and using the server cluster clock implementation.
- DT_NS_1DC_O: D-Thespis (DT) deployed on multiple (N) servers (NS) within a single data centre (1DC) using the Microsoft Orleans actor framework (O), enabling concurrent READ operations over cached data and using the middleware cluster clock implementation.
- DT_1S_1DC_A: D-Thespis (DT) deployed on a single server (1S) within a single data centre (1DC) using the Akka.NET actor toolkit (A) with caching disabled and using the server cluster clock implementation.
- DT_NS_2DC_O: D-Thespis (DT) deployed across two data centres (2DC) with each data centre running the same configuration as DT_NS_1DC_O.
- Q1:
- What is the impact of the workload profile (i.e., read/write ratio) on the performance of D-Thespis under every configuration?
- Q2:
- Does the dataset size have any bearing on the performance of D-Thespis under every configuration?
- Q3:
- How does the performance of all D-Thespis configurations change in relation to the number of requests submitted?
- Q4:
- How does the performance of D-Thespis under every configuration compare to the DB_1S_1DC and DB_NS_1DC SUTs, under all the different workload conditions?
- Q5:
- For DT_NS_1DC_O, what is the effect of horizontally scaling D-Thespis within a single data centre?
- Q6:
- What is the update visibility latency of D-Thespis? Thus, for DT_NS_2DC_O, how long does it take for an event to be visible in a remote data centre?
- Q7:
- How can the memory footprint of D-Thespis be characterised?
5.1. Benchmark Hardware Infrastructure
- The database server hosts an instance of PostgreSQL;
- The PGBouncer Server runs four instances of PGBouncer, configured with the option SO_REUSEPORT such that all instances share the same TCP port;
- The load server from which the requests to the D-Thespis API dictated by the benchmark workload for each execution are generated.
5.2. System under Test Configuration
5.2.1. Compute Engine Instances
5.2.2. Redis for Event Log and Cache Storage
5.2.3. Redis for Grain Directory
5.2.4. D-Thespis with Microsoft Orleans
- d-thespis-client includes the REST API, the middleware engine and the actor provider client components
- d-thespis includes the actor provider and related components
- d-thespis-internal includes the internal API exposed over GRPC (for message packing with Protobuf), the server cluster clock, the data replication job and the event snapshotting job.
5.2.5. D-Thespis with Akka.NET
5.2.6. REST API over Relational DBMS
5.3. Benchmarking Tool and Dataset
- A D-Thespis client that has knowledge of the D-Thespis REST API and can send READ and WRITE queries in the correct format. The D-Thespis client can also be configured with a list of URLs such that the workload is distributed across these endpoints, thus, allowing a workload to exercise multiple servers without necessarily relying on load balancing equipment;
- An extension of the BasicDB module of YCSB to support asynchronous requests and, therefore, allow YCSB clients to make better use of application thread pools where the target database supports asynchronous requests. In the case of the D-Thespis client, the benchmark uses this interface to perform asynchronous HTTP requests.
5.4. Performance Benchmarks: Variations and Procedure
- The type of SUT: D-Thespis with the Microsoft Orleans framework (i.e., DT_NS_1DC_O) and the REST API that executes queries directly on the RDBMS (i.e., DB_NS_1DC).
- The number of servers, i.e., N in the SUT type, with N varied for values 1, 2, 3 and 5. For example, for the specific SUT DB_3S_1DC, the benchmark workload is handled by three instances of the REST API application, running on three servers in the application tier of the GKE cluster. Conversely, for the specific SUT DT_3S_1DC_O, three servers in the application tier of the GKE cluster host the d-thespis-client workload, whilst another three servers in the application tier of the GKE cluster host the d-thespis workload.
- The type of workload, with each type performing a different ratio of READ and WRITE operations. Nine workloads were tested: 100% READ/0%WRITE, 99% READ/1% WRITE, 95% READ/5% WRITE, 90% READ/10% WRITE, 85% READ/15% WRITE, 80% READ/20% WRITE, 75% READ/25% WRITE, 70% READ/30% WRITE and 65% READ/35% WRITE. The spectrum of workload ratios selected is consistent with other works that benchmark web-scale transactional databases [40], and includes the ratios WRITE and 65% READ/35% WRITE and WRITE, 90% READ/10% WRITE, which are defined by the popular transactional workloads from the standard TPC-C and TPC-E benchmarks, respectively [41].
- The data set size over which the workload executes. Four data set sizes were tested: 10,000 records; 100,000 records, 500,000 records; 1,000,000 records.
- The number of virtual users, i.e., the number of threads that the YCSB benchmarking tool spawns in parallel. Seven variations were tested: 60, 120, 240, 480, 960, 1920 and 3840 virtual users.
Algorithm 1 Benchmark routine executed for every type of SUT |
|
5.5. Performance Benchmarks: Tool Calibration
5.6. Performance Benchmarks: Results
- Let , and ≡ the throughput (operations per second) of the D-Thespis SUT under study, obtained by executing three (3) benchmark workloads for a particular benchmark variation (i.e., a particular set of values for each dimension discussed in Section 5.4).
- Let , and ≡ the throughput (operations per second) obtained like , and , but for the DBMS SUT under study.
5.6.1. The Cache Effect
5.6.2. D-Thespis and the RDBMS
5.6.3. Horizontal Scalability
5.7. Update Visibility Latency Benchmark: Configuration and Procedure
- The time of event generation does not include any latency encountered in saving the event to the event log in us-west1-c, while the replication protocol can only consider the event for replication once it is saved;
- The clocks in the different data centres were not assumed to be highly synchronised and the measure could be happening in the presence of some clock skew. The computer processors are equipped with in-built physical clocks. These operate independently can have a different rate of progress, resulting in different frequencies. This, in turn, produces clock skew, which is the difference between the time produced by a clock and time produced by the perfect clock or by another physical clock [46].
5.8. Update Visibility Latency Benchmark: Results
5.9. Memory Profile Benchmark: Configuration and Procedure
5.10. Memory Profile Benchmark: Results
6. Discussion
6.1. Synopsis
- Q1:
- What is the impact of the workload profile (i.e., read/write ratio) on the performance of D-Thespis under every configuration?Summary: The D-Thespis approach introduces the “cache effect”, as discussed in Section 5.6.1. Our results show that the throughput of D-Thespis is higher as the read ratio increases. Nonetheless, our benchmarks show that D-Thespis configuration is able to produce higher throughput from an RDBMS across all workload profiles.
- Q2:
- Does the dataset size have any bearing on the performance of D-Thespis under every configuration?Summary: The throughput of D-Thespis is generally higher for smaller data sets when running on a single server but generally higher for larger data sets when running on multiple servers and sustaining a sufficiently large workload. Here, we see that a higher cache–hit ratio is achieved in a shorter time in smaller data sets; however, the effects of contention (i.e., a larger chance of concurrent requests to the same data record) on a smaller data set causes overheads when running on multiple servers (therefore, using a distributed cache rather than an in-memory actor-based cache). We consider this a positive result; running D-Thespis on a single server fits better for use cases that handle smaller data sets, while a larger data set is likely to require D-Thespis to run on multiple servers.
- Q3:
- How does the performance of all D-Thespis configurations change in relation to the number of requests submitted?Summary: Our results show that, in general, the throughput of D-Thespis increases as the workload increases. This correlates with our observation that the hardware infrastructure was not saturated in most of our tests. Naturally, this pattern is not considered infinite, i.e., given a fixed infrastructure size, the system throughput will degrade as the workload size increases to a level that saturates the available hardware resources. Indeed, the last case in Figure 16 is such an example: with D-Thespis running on a single server, increasing the workload to 3840 virtual users with a read/write ratio of 65%/35% yields lower throughput than the same type of workload with 1920 virtual users. Nonetheless, by introducing the concept of elastic horizontal scalability in D-Thespis, larger workloads can be handled by introducing additional hardware capacity.
- Q4:
- How does the performance of D-Thespis under every configuration compare to the DB_1S_1DC and DB_NS_1DCSUTs, under all the different workload conditions?Summary: D-Thespis is generally faster than the DB_1S_1DC and DB_NS_1DC SUTs, with two exceptions. Firstly, D-Thespis is slower than the DB_1S_1DC SUT when running on a single server and not configured correctly (i.e., when not configured to use the Akka.NET actor provider), as shown in Figure 15. Secondly, D-Thespis is slower than the DB_NS_1DC SUT when running on multiple servers and the workload is not sufficiently high, as shown, for example, in several graphs of Figure 12, where the workload was generated by 60 virtual users. We consider this a positive result in that D-Thespis should be configured correctly to achieve its best performance, and the system should not be horizontally scaled unless it needs to sustain a substantial workload.
- Q5:
- For DT_NS_1DC_O, what is the effect of horizontally scaling D-Thespis within a single data centre?Summary: The effect is generally positive, as discussed in Q4, and as shown in Figure 17, by horizontally scaling D-Thespis, the throughput could be improved by more than 300% in some scenarios. However, as shown in the results of Figure 19, scaling D-Thespis by a single machine might actually result in loss of performance, and therefore, our results indicate that a horizontally scaled installation of D-Thespis would benefit from running on three machines or more.
- Q6:
- What is the update visibility latency of D-Thespis? Thus, for DT_NS_2DC_O, how long does it take for an event to be visible in a remote data centre?Summary: As detailed in Section 5.8, our experiments indicate that, on average, the update visibility latency varies between 400 and 700 ms. The results also indicate a correlation between the update visibility latency, the network round trip time between the data centres, as well as the volume of events that need to be replicated at any point in time.
- Q7:
- How can the memory footprint of D-Thespis be characterised?Summary: During our experiments, D-Thespis did not require additional memory than that allocated to the machines on which it was installed, i.e., 32GB. By the results presented in Section 5.10, when D-Thespis was scaled horizontally, the memory requirements were evenly distributed across the available machines.
6.2. Strengths and Weaknesses
7. Conclusions
7.1. Contributions and Innovations
7.2. Future Work
Author Contributions
Funding
Data Availability Statement
Conflicts of Interest
References
- Brewer, E.A. Towards robust distributed systems. In Proceedings of the PODC, Portland, OR, USA, 16–19 July 2000; Volume 7. [Google Scholar]
- Gilbert, S.; Lynch, N. Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services. ACM SIGACT News 2002, 33, 51–59. [Google Scholar] [CrossRef]
- Herlihy, M.P.; Wing, J.M. Linearizability: A correctness condition for concurrent objects. ACM Trans. Program. Lang. Syst. (TOPLAS) 1990, 12, 463–492. [Google Scholar] [CrossRef]
- Vogels, W. Eventually consistent. Commun. ACM 2009, 52, 40–44. [Google Scholar] [CrossRef]
- Lamport, L. The part-time parliament. ACM Trans. Comput. Syst. (TOCS) 1998, 16, 133–169. [Google Scholar] [CrossRef]
- Elbushra, M.M.; Lindström, J. Eventual Consistent Databases: State of the Art. Open J. Databases (OJDB) 2014, 1, 26–41. [Google Scholar]
- Ahamad, M.; Neiger, G.; Burns, J.E.; Kohli, P.; Hutto, P.W. Causal memory: Definitions, implementation, and programming. Distrib. Comput. 1995, 9, 37–49. [Google Scholar] [CrossRef]
- Mahajan, P.; Alvisi, L.; Dahlin, M. Consistency, Availability, and Convergence; Technical Report; University of Texas at Austin: Austin, TX, USA, 2011; Volume 11. [Google Scholar]
- Bailis, P.; Ghodsi, A.; Hellerstein, J.M.; Stoica, I. Bolt-on causal consistency. In Proceedings of the 2013 ACM SIGMOD International Conference on Management of Data, New York, NY, USA, 22–27 June 2013; pp. 761–772. [Google Scholar]
- Spirovska, K.; Didona, D.; Zwaenepoel, W. Optimistic Causal Consistency for Geo-Replicated Key-Value Stores. IEEE Trans. Parallel Distrib. Syst. 2020, 32, 527–542. [Google Scholar] [CrossRef]
- Braun, S.; Bieniusa, A.; Elberzhager, F. Advanced Domain-Driven Design for Consistency in Distributed Data-Intensive Systems. In Proceedings of the 8th Workshop on Principles and Practice of Consistency for Distributed Data, Online, 26 April 2021; pp. 1–12. [Google Scholar]
- Camilleri, C.; Vella, J.G.; Nezval, V. Thespis: Actor-Based Causal Consistency. In Proceedings of the 2017 28th International Workshop on Database and Expert Systems Applications (DEXA), Lyon, France, 28–31 August 2017; pp. 42–46. [Google Scholar] [CrossRef]
- Camilleri, C.; Vella, J.G.; Nezval, V. D-Thespis: A Distributed Actor-Based Causally Consistent DBMS. In Transactions on Large-Scale Data-and Knowledge-Centered Systems LIII; Springer: Berlin/Heidelberg, Germany, 2023; pp. 126–165. [Google Scholar]
- Lamport, L. Time, clocks, and the ordering of events in a distributed system. Commun. ACM 1978, 21, 558–565. [Google Scholar] [CrossRef]
- Corbett, J.C.; Dean, J.; Epstein, M.; Fikes, A.; Frost, C.; Furman, J.J.; Ghemawat, S.; Gubarev, A.; Heiser, C.; Hochschild, P.; et al. Spanner: Google’s globally distributed database. ACM Trans. Comput. Syst. (TOCS) 2013, 31, 8. [Google Scholar] [CrossRef]
- Terry, D.B.; Theimer, M.M.; Petersen, K.; Demers, A.J.; Spreitzer, M.J.; Hauser, C.H. Managing update conflicts in Bayou, a weakly connected replicated storage system. ACM SIGOPS Oper. Syst. Rev. 1995, 29, 172–182. [Google Scholar] [CrossRef]
- Lakshman, A.; Malik, P. Cassandra: A decentralized structured storage system. ACM SIGOPS Oper. Syst. Rev. 2010, 44, 35–40. [Google Scholar] [CrossRef]
- Lloyd, W.; Freedman, M.J.; Kaminsky, M.; Andersen, D.G. 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, Cascais, Portugal, 23–26 October 2011; pp. 401–416. [Google Scholar]
- Du, J.; Iorgulescu, C.; Roy, A.; Zwaenepoel, W. Gentlerain: Cheap and scalable causal consistency with physical clocks. In Proceedings of the ACM Symposium on Cloud Computing, Seattle, WA, USA, 3–5 November 2014; pp. 1–13. [Google Scholar]
- Spirovska, K.; Didona, D.; Zwaenepoel, W. Wren: Nonblocking reads in a partitioned transactional causally consistent data store. In Proceedings of the 2018 48th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN), Luxembourg, 25–28 June 2018; pp. 1–12. [Google Scholar]
- Kulkarni, S.; Demirbas, M.; Madeppa, D.; Bharadwaj, A.; Leone, M. Logical Physical Clocks and Consistent Snapshots in Globally Distributed Databases; Springer: Berling/Heidelberg, Germany, 2014. [Google Scholar]
- Hewitt, C.; Bishop, P.; Steiger, R. A universal modular actor formalism for artificial intelligence. In Proceedings of the 3rd International Joint Conference on Artificial Intelligence, Standford, CA, USA, 20–23 August 1973; Morgan Kaufmann Publishers Inc.: Burlington, MA, USA, 1973; pp. 235–245. [Google Scholar]
- Agha, G.A. Actors: A Model of Concurrent Computation in Distributed Systems; MIT AI-TR; MIT Press: Cambridge, MA, USA, 1986; Volume 844. [Google Scholar]
- Young, G. CQRS Documents. 2010. Available online: https://cqrs.files.wordpress.com/2010/11/cqrs_documents.pdf (accessed on 2 February 2024).
- Meyer, B. Eiffel: The Language; Prentice-Hall, Inc.: Hoboken, NJ, USA, 1992. [Google Scholar] [CrossRef]
- Fowler, M. Event Sourcing. 2005. Available online: https://martinfowler.com/eaaDev/EventSourcing.html (accessed on 2 February 2024).
- Abadi, D. Consistency tradeoffs in modern distributed database system design: CAP is only part of the story. Computer 2012, 45, 37–42. [Google Scholar] [CrossRef]
- Camilleri, C.; Vella, J.G.; Nezval, V. ThespisTRX: Initial Results for Causally-Consistent Read Transactions. In Proceedings of the Information Systems and Management Science, Valletta, Malta, 22–23 February 2018. [Google Scholar]
- Camilleri, C.; Vella, J.G.; Nezval, V. ThespisDIIP: Distributed Integrity Invariant Preservation. In Proceedings of the Database and Expert Systems Applications; Elloumi, M., Granitzer, M., Hameurlain, A., Seifert, C., Stein, B., Tjoa, A.M., Wagner, R., Eds.; Springer: Cham, Switzerland, 2018; pp. 21–37. [Google Scholar]
- Barbará-Millá, D.; Garcia-Molina, H. The demarcation protocol: A technique for maintaining constraints in distributed database systems. VLDB J.-Int. J. Very Large Data Bases 1994, 3, 325–353. [Google Scholar] [CrossRef]
- Neumann, T.; Mühlbauer, T.; Kemper, A. Fast serializable multi-version concurrency control for main-memory database systems. In Proceedings of the 2015 ACM SIGMOD International Conference on Management of Data, Melbourne, Australia, 31 May–4 June 2015; pp. 677–689. [Google Scholar]
- Bernstein, P.A.; Hadzilacos, V.; Goodman, N. Concurrency Control and Recovery in Database Systems; Addison-Wesley: Reading, MA, USA, 1987; Volume 370. [Google Scholar]
- Camilleri, C.; Vella, J.G.; Nezval, V. Actor model frameworks: An empirical performance analysis. In Proceedings of the International Conference on Information Systems and Management Science; Springer: Berlin/Heidelberg, Germany, 2022; pp. 461–472. [Google Scholar]
- Himschoot, P. Efficient Communication with gRPC. In Microsoft Blazor; Springer: Berlin/Heidelberg, Germany, 2022; pp. 465–482. [Google Scholar]
- Liu, S.; Benson, T.A.; Reiter, M.K. Efficient and safe network updates with suffix causal consistency. In Proceedings of the Fourteenth EuroSys Conference 2019, Dresden, Germany, 25–28 March 2019; pp. 1–15. [Google Scholar]
- Roohitavaf, M.; Ahn, J.S.; Kang, W.H.; Ren, K.; Zhang, G.; Ben-Romdhane, S.; Kulkarni, S.S. Session guarantees with raft and hybrid logical clocks. In Proceedings of the 20th International Conference on Distributed Computing and Networking, Bangalore, India, 4–7 January 2019; pp. 100–109. [Google Scholar]
- Paksula, M. Introduction to store data in Redis, a persistent and fast key-value database. In Proceedings of the AMICT 2010–2011 Advances in Methods of Information and Communication Technology; University of Helsinki: Helsinki, Finland, 2010; p. 39. [Google Scholar]
- Bernstein, P.A.; Burckhardt, S.; Bykov, S.; Crooks, N.; Faleiro, J.M.; Kliot, G.; Kumbhare, A.; Rahman, M.R.; Shah, V.; Szekeres, A.; et al. Geo-distribution of actor-based services. Proc. ACM Program. Lang. 2017, 1, 1–26. [Google Scholar] [CrossRef]
- Camilleri, C.; Vella, J.G.; Nezval, V. ThespisTRX: Causally-Consistent Read Transactions. Int. J. Inf. Technol. Web Eng. (IJITWE) 2020, 15, 1–16. [Google Scholar] [CrossRef]
- Dey, A.; Fekete, A.; Nambiar, R.; Röhm, U. YCSB+ T: Benchmarking web-scale transactional databases. In Proceedings of the 2014 IEEE 30th International Conference on Data Engineering Workshops, Chicago, IL, USA, 31 March–4 April 2014; pp. 223–230. [Google Scholar]
- Chen, S.; Ailamaki, A.; Athanassoulis, M.; Gibbons, P.B.; Johnson, R.; Pandis, I.; Stoica, R. TPC-E vs. TPC-C: Characterizing the new TPC-E benchmark via an I/O comparison study. ACM SIGMOD Rec. 2011, 39, 5–10. [Google Scholar] [CrossRef]
- Yang, Y.; Zhu, J. Write skew and zipf distribution: Evidence and implications. ACM Trans. Storage (TOS) 2016, 12, 1–19. [Google Scholar] [CrossRef]
- Sidhanta, S.; Mukhopadhyay, S.; Golab, W. DYN-YCSB: Benchmarking adaptive frameworks. In Proceedings of the 2019 IEEE World Congress on Services (SERVICES), Milan, Italy, 8–13 July 2019; Volume 2642, pp. 392–393. [Google Scholar]
- Yamada, H.; Nemoto, J. Scalar DL: Scalable and practical Byzantine fault detection for transactional database systems. In Proceedings of the VLDB Endowment, Sydney, Australia, 5–9 September 2022; VLDB Endowment Inc.: Sydney, Australia, 2022; Volume 15, pp. 1324–1336. [Google Scholar]
- Rossi, F.; Falvo, S.; Cardellini, V. GOFS: Geo-distributed scheduling in OpenFaaS. In Proceedings of the 2021 IEEE Symposium on Computers and Communications (ISCC), Athens, Greece, 5–8 September 2021; pp. 1–6. [Google Scholar]
- Kshemkalyani, A.D.; Singhal, M. Distributed Computing: Principles, Algorithms, and Systems; Cambridge University Press: Cambridge, UK, 2011. [Google Scholar]
- Bernstein, P.; Bykov, S.; Geller, A.; Kliot, G.; Thelin, J. Orleans: Distributed Virtual Actors for Programmability and Scalability. Available online: https://www.microsoft.com/en-us/research/publication/orleans-distributed-virtual-actors-for-programmability-and-scalability/ (accessed on 2 February 2024).
- Camilleri, C.; Vella, J.G.; Nezval, V. Thespis: Causally-consistent OLTP. In Proceedings of the 2021 16th Conference on Computer Science and Intelligence Systems (FedCSIS), Sofia, Bulgaria, 2–5 September 2021; pp. 261–269. [Google Scholar]
- Akkoorath, D.D.; Tomsic, A.Z.; Bravo, M.; Li, Z.; Crain, T.; Bieniusa, A.; Preguiça, N.; Shapiro, M. Cure: Strong semantics meets high availability and low latency. In Proceedings of the 2016 IEEE 36th International Conference on Distributed Computing Systems (ICDCS), Nara, Japan, 27–30 June 2016; pp. 405–414. [Google Scholar]
Role | Kubernetes Cluster Nodes | Database Server | Load Server | PGBouncer Server |
Operating System | Container-Optimized OS | Debian Linux 9.13 (stretch) | Debian Linux 10 (buster) | Debian Linux 11 (bullseye) |
CPU | 8x Xeon @ 2.80 GHz | 8x Xeon @ 2.80 GHz | 60x Xeon @ 2.80 GHz | 8x Xeon @ 2.80 GHz |
RAM | 32 GB | 32 GB | 240 GB | 32 GB |
Disk | 10 GB SSD | 100 GB SSD | 10 GB Spindle | 60 GB SSD |
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content. |
© 2024 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https://creativecommons.org/licenses/by/4.0/).
Share and Cite
Camilleri, C.; Vella, J.G.; Nezval, V. Horizontally Scalable Implementation of a Distributed DBMS Delivering Causal Consistency via the Actor Model. Electronics 2024, 13, 3367. https://doi.org/10.3390/electronics13173367
Camilleri C, Vella JG, Nezval V. Horizontally Scalable Implementation of a Distributed DBMS Delivering Causal Consistency via the Actor Model. Electronics. 2024; 13(17):3367. https://doi.org/10.3390/electronics13173367
Chicago/Turabian StyleCamilleri, Carl, Joseph G. Vella, and Vitezslav Nezval. 2024. "Horizontally Scalable Implementation of a Distributed DBMS Delivering Causal Consistency via the Actor Model" Electronics 13, no. 17: 3367. https://doi.org/10.3390/electronics13173367