The YugaByte Database Blog

Thoughts on open source, cloud native and distributed databases

Overcoming MongoDB Sharding and Replication Limitations with YugaByte DB

A few of our early users have chosen to build their new cloud applications on YugaByte DB 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

Building Scalable Cloud Services — An Instant Messaging App

Source: https://stackoverflow.com/questions/47276519/how-should-i-or-should-not-use-cassandra-and-redis-together-to-build-a-scalable

This is the first post in a series about building real-world, distributed cloud services using a transactional cloud database like YugaByte DB.

We are going to look at how to build a scalable chat or messaging application like Facebook Messages. This is close to heart to a number of us at YugaByte — we were the team behind the database platform that powers the Facebook Messages app.

Read More

Achieving Sub-ms Latencies on Large Datasets in Public Clouds

One of our users was interested to learn more about YugaByte DB’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 YugaByte DB was designed well to handle this case with the optimal number of IOs to the disk subsystem.

Read More

Practical Tradeoffs in Google Cloud Spanner, Azure Cosmos DB and YugaByte DB

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.

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

Building a Strongly Consistent Cassandra with Better Performance

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 YugaByte DB provides strong consistency while outperforming an eventually consistent DB like Apache Cassandra.

Read More

YugaByte DB Architecture: Diverse Workloads with Operational Simplicity

YugaByte DB is a transactional, high performance, geo-distributed operational database that converges multiple NoSQL and SQL interfaces into an unified solution. The v0.9 public beta of YugaByte DB is compatible with Apache Cassandra (CQL) and Redis APIs, with PostgreSQL under development. A fundamental design goal for YugaByte DB has been to provide the same transactional, performance and operational simplicity guarantees irrespective of the API used.

Read More

YugaByte Has Arrived!

Today, we are launching YugaByte out of stealth and announcing the availability of YugaByte DB’s first public beta release. YugaByte offers an open-source, cloud-native database for mission-critical applications. Yuga in Sanskrit represents an era or an epoch (about 4.32 million human years), a very long period of time. We picked the name YugaByte to signify data that lives forever without limits.

Read More