YugabyteDB features two services: the YB-TServer for database-level operations and the YB-Master for cluster-level controls and metadata storage. Its unique structure divides tables and indexes into tablets, leading to RAFT groups with a distinct leader-follower dynamic based on the replication factor.
Learn how YugabyteDB ensures stability when a downed node rejoins the cluster. Our latest blog covers the essential 15-minute RAFT timeout and the built-in fault tolerance mechanisms that keep your data secure and accessible.
Note: This post contains interactive animations that explain how some of these complex algorithms work. Please view this post in a suitable media (at least 1000px by 600px screen resolution) for best results.
In this blog post, we are going to dive deep into the read performance of Raft – why read performance can take a hit and how it can be improved using leader leases. Additionally, we will also look at how to make the correctness guarantees around leader leases stronger.
…
You can join the discussion on HackerNews here.
We crossed the three year mark of developing the YugabyteDB database in February of 2019. It has been a thrilling journey thus far, but not without its fair share of technical challenges. There were times when we had to go back to the drawing board and even sift through academic research to find a better solution than what we had at hand.
…
In this post, we dive into the architecture of the distributed storage layer of YugabyteDB, which is inspired by Google Spanner’s design
Editor’s note: This post was originally published August 8, 2018 and has been updated as of May 28, 2020.
As we saw in ”How Does Consensus-Based Replication Work in Distributed Databases?”, Raft has become the consensus replication algorithm of choice when it comes to building resilient, strongly consistent systems. YugabyteDB uses Raft for both leader election and data replication. Instead of having a single Raft group for the entire dataset in the cluster,
…
Explore how consensus-based replication gets implemented in distributed databases, and dive into Paxos and Raft, the most commonly used leader-based consensus protocols
Updated April 2019.
The famed CAP Theorem has been a source of much debate among distributed systems engineers. Those of us building distributed databases are often asked how we deal with it. In this post, we dive deeper into the consistency-availability tradeoff imposed by CAP which is only applicable during failure conditions. We also highlight the lesser-known-but-equally-important consistency-latency tradeoff imposed by the PACELC Theorem that extends CAP to normal operations.
…
In an earlier blog on database consistency, we had a detailed discussion on the risks and challenges applications face in dealing with eventually consistent NoSQL databases. We also dispelled the myth that eventually consistent DBs perform better than strongly consistent DBs. In this blog, we will look more closely into how YugabyteDB provides strong consistency while outperforming an eventually consistent DB like Apache Cassandra. Note that YugabyteDB retains drop-in compatibility with the Cassandra Query Language (CQL) API.
…
