This project provides a simulation interface for a distributed database system using written SQL transactions and customizable isolation levels. Using De La Salle University's CCS Cloud Platform, the distributed database is hosted across three virtual machines with MySQL. The structure of the distributed database follows a master-slave architecture, which has exactly three nodes:
- Central Node (Master)
- Contains all appointment records
- Luzon Node (Slave 1)
- Contains appointment records only from Luzon
- Visayas/Mindanao Node (Slave 2)
- Contains appointment records only from Visayas and Mindanao
The project is hosted on Render using a Docker image from a Docker Hub repository, which can be accessed through this link. However, it can also be launched locally by following these instructions:
- Clone the repository on your local machine.
- Create an
application.propertiesfile in thesrc/main/resourcesdirectory with the following environmental variables:spring.application.namespring.autoconfigure.excludespring.jpa.hibernate.ddl-autospring.datasource.urlspring.datasource.slave1.urlspring.datasource.slave2.urlspring.datasource.usernamespring.datasource.passwordspring.datasource.driver-classserver.port
- Build the application using the
gradle buildcommand in the command prompt. - Run the application using the
gradle bootRuncommand in the command prompt. - Using the specified port number, launch the application in your browser via
localhost:<port number>
The dependencies of the project are located in the build.gradle file of the repository under the src directory.
- Spring Data JPA
- Used to create JPA-based (Java Persistence API) repositories
- Spring Web
- Used to build the RESTful web application using Spring MVC (Model-View-Controller)
- Spring Boot DevTools
- Used for faster application relaunches and configurations for enhanced development experience
- MySQL JDBC Driver
- Used to connect to the MySQL databases in the virtual machines
Discussion of the Distributed Database System's Design, Concurrency Control and Consistency, and Global Failure and Recovery Strategy
The significant details of the distributed database design, concurrency control and consistency, and global failure and recovery strategy are documented in this paper. This database application was designed, tested, evaluated, undergoing a series of edge test cases, including central node failures, replication failures, and the like.
The data stored in the distributed database system is a fraction of the SeriousMD appointments dataset, consisting of exactly more or less appointment records out of the original nine million records. Unlike the original dataset, this distributed database system is denormalized into one table for faster access of data between nodes.
Listed below are the sample transactions that you can use in running the application for the different operation types. However, you can also try testing the different test case scenarios stated in this paper for better learning outcomes. The id field can be any number between 1 to 1000 on any node since the node redirection of the distributed database system allows reading from any node of any data despite the region difference.
- Read
SELECT * FROM appointments WHERE id = ?;
- Write (Update)
UPDATE appointments SET <field_1> = <value_1>, ..., <field_n> = <value_n> WHERE id = ?;
- Write (Delete)
DELETE FROM appointments WHERE id = ?;
- Find All
- Only the node, transaction, and operation type are required in this operation type
SELECT * FROM appointments;