The Distributed SQL Blog

Thoughts on distributed databases, open source and cloud native

A Primer on ACID Transactions: The Basics Every Cloud App Developer Must Know

ACID transactions were a big deal when first introduced formally in the 1980s in monolithic SQL databases such as Oracle and IBM DB2. Popular distributed NoSQL databases of the past decade including Amazon DynamoDB and Apache Cassandra initially focused on “big data” use cases that did not require such guarantees and hence avoided implementing them altogether. However, ACID transactions have made a strong comeback in the last several years with the launch of next-generation distributed databases that have built-in support for them.

Read More

A Busy Developer’s Guide to Database Storage Engines — Advanced Topics

In the first post of this two-part series, we learned about the B-tree vs LSM approach to index management in operational databases. While the indexing algorithm plays a fundamental role in determining the type of storage engine needed, advanced considerations highlighted below are equally important to take into account.

Consistency, Transactions & Concurrency Control

Monolithic databases,

Read More

YugaByte DB 1.0 — A Peek Under The Hood

Modern user-facing apps, like E-Commerce and SaaS, frequently require features from multiple databases (broadly — SQL, NoSQL and a cache) to support their multi-workload needs. App developers are responsible for understanding and managing which pieces of data should be stored in which SQL and NoSQL database. Furthermore, the app is also responsible for moving data across the tiers (e.g.

Read More

Yes We Can! Distributed ACID Transactions with High Performance

ACID transactions are a fundamental building block when developing business-critical, user-facing applications. They simplify the complex task of ensuring data integrity while supporting highly concurrent operations. While they are taken for granted in monolithic SQL/relational databases, distributed NoSQL/non-relational databases either forsake them completely or support only a highly restrictive single-row flavor (see sections below). This loss of ACID properties is usually justified with a gain in performance (measured in terms of low latency and/or high throughput).

Read More

Orchestrating Stateful Apps with Kubernetes StatefulSets

Kubernetes, the open source container orchestration engine that originated from Google’s Borg project, has seen some of the most explosive growth ever recorded in an open source project. The complete software development lifecycle involving stateless apps can now be executed in a more consistent, efficient and resilient manner than ever before. However, the same is not true for stateful apps — containers are inherently stateless and Kubernetes did not do anything special in the initial days to change that.

Read More

Overcoming MongoDB Sharding and Replication Limitations with YugabyteDB

A few of our early users have chosen to build their new cloud applications on YugabyteDB even though their current primary datastore is MongoDB. Starting with the v3.4 release in Nov 2016, MongoDB has made improvements in its sharding and replication architecture that has allowed it to be re-classified as a Consistent and Partition-tolerant (CP) database and move away from its Available and Partition-tolerant (AP) origins.

Read More

Achieving Sub-ms Latencies on Large Datasets in Public Clouds

One of our users was interested to learn more about YugabyteDB’s behavior for a random read workload where the data set does not fit in RAM and queries need to read data from disk (i.e. an uncached random read workload).

The intent was to verify if YugabyteDB was designed well to handle this case with the optimal number of IOs to the disk subsystem.

Read More

Scaling YugaByte DB to Millions of Reads and Writes

Here at YugaByte, we continuously push the limits of the systems we build. As a part of that, we ran some large cluster benchmarks to scale YugaByte DB to million of reads and writes per second while retaining low latencies. This post goes into the details about our 50 node cluster benchmark. We posted the results of the benchmark on a 25 node cluster in our community forum.

Read More