Distributed SQL Simplifies Cloud Application Architecture
We often get asked, “why another database”? Between NoSQL and traditional relational stores, aren’t we covered? In reality, the world is moving to the cloud and distributed services. There needs to be a relational database that fits this new environment. The answer is Distributed SQL.
In this webinar, we walk through the what and why of Distributed SQL, and give you real-world examples of how organizations are using this new approach to simplify cloud applications and get reliable, global access to their data.
Topics covered in the webinar:
- A high-level architecture of a globally distributed database
- How organizations use Distributed SQL
- Why and where you should consider Distributed SQL instead of traditional databases and NoSQL
- How Distributed SQL fits with microservices and Kubernetes
What are the key concepts of Distributed SQL?
We believe that Distributed SQL is a proper evolution of the database and the future of the way we manage data in the cloud. When you discuss distributed SQL with your vendor, we encourage you to go deep on concepts like consistency and locality. While everyone has read the same papers, ultimately it comes down to implementation and more importantly, production use.
Once you live in a distributed world, it becomes apparent that the database itself could actually take care of domiciling data. With participants located in various regions or data centers, it becomes possible to understand the location of each and then tie the data that it stores to a location. Some application architects have implemented this as part of an application but this approach is error-prone and brittle. Using the database to geo-partition data based on some field in a table is a new requirement for Distributed SQL. This allows you to use the database to address data sovereignty concerns. It can also be used to have data follow a user so you can ensure low latency access to their information or to tie data to an explicit cloud so you can minimize egress charges.
A distributed SQL database must deliver a high level of isolation in a distributed environment. In a cloud-based world with distributed systems and microservices are the default architectures, transactional consistency becomes difficult as multiple operators may be trying to work on the same data. The database should mediate contention and deliver the same level of isolation of transactions as we expect in a single instance database.
Other important concepts that are unique to distributed SQL and should be kept in mind during an evaluation of any distributed database are Latency, Resilience, and Compliance. Make sure that the latency goal is to achieve the speed of light, because, well, that’s as good as it gets. Confirm that the database will not experience any downtime when, inevitably, a node fails. And make sure that the data locality that is being discussed will help you achieve compliance with the suddenly proliferant data storage regulation laws around the world.
For a more detailed analysis of Distributed SQL architecture please watch this webinar.
After you’ve watched the webinar please join our CockroachDB Community Slack channel to chat with CockroachDB users and engineers.