This is the first post in a series about building real-world, distributed cloud services using a transactional cloud database like YugabyteDB.
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.
…
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.
This post is a sneak peak into just one of the aspects of YugabyteDB’s innovative storage engine,
…
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.
…
YugabyteDB is an open source, transactional, high-performance database for your business-critical data —and it is compatible with the Redis API. Over the years, many of us fell in love with the simplicity and the intuitiveness of the various Redis commands and data structures. We are excited to share the same love with all the Redis developers out there.
When using your Redis application with YugabyteDB, your data is replicated and persisted with strong consistency.
…
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 YugabyteDB 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.
The graph above shows how you can achieve linear scalability with YugabyteDB.
…
We have spoken to several developers that have a need to model time series like data in Redis. A few examples of such applications are:
In general time series data has the following characteristics:
…
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.
…
YugabyteDB 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 YugabyteDB includes the YCQL and YEDIS APIs that are compatible with Cassandra Query Language (CQL) and Redis APIs respectively. PostgreSQL-compatible YSQL API is under development. A fundamental design goal for YugabyteDB has been to provide the same transactional, performance and operational simplicity guarantees irrespective of the API used.
…
Today, we are launching Yugabyte out of stealth and announcing the availability of YugabyteDB’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. Our ultimate goal is to simplify data that is critical to businesses.
…
In the world of databases today, consistency is one of the most misunderstood concepts. It is also one of the big reasons NoSQL databases are difficult to reason about.
The CAP theorem states that “in the presence of a network partition, one has to choose between consistency and availability”. In order to provide higher write availability, some NoSQL databases implement a weaker form of consistency called eventual consistency.
…