Using Redis API as a True Distributed, Fault-Tolerant Database

Founder & CTO

January 18, 2018

YugabyteDB 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. This means that you do not need to worry about having an additional database like Apache Cassandra or MongoDB as the system of record for the data cached in Redis (to read from in case of failures). YugabyteDB provides an elastic Redis as a “unified cache + database” alternative that can span geographies or multiple datacenters — with built in automatic sharding and clustering.

You can try out YugabyteDB’s Redis-compatible YEDIS API using our very simple quick-start docs.

You can explore some of the core features that make YugabyteDB ideal for building Redis applications. Here are the 6 key benefits of using YugabyteDB’s Redis-compatible API.

1. Use Redis as your primary database

This is #1 in the list because we’ve heard this issue from many, many folks. Redis app architecture typically falls in one of the following paradigms:

If deployed as a cache, the app needs to fetch data from the DB into Redis on a read miss or invalidate data in Redis on a write/update to the DB
If deployed as an in-memory DB, the data needs to be written to a persistent store along with Redis, and in case of the Redis node failure data needs to be restored from the DB.

How YugabyteDB makes this simple

YugabyteDB with native support for Redis-compatible and Cassandra-compatible APIs

YugabyteDB is a fully-functional database which can serve as the source of truth for your data in Redis — so you neither need to page/invalidate data nor do you need a separate database.

At this point, you may be thinking…

“Ah, but I use BGSAVE checkpointing to persist my data!”

Great, but definitely read point #5 below.

2. No need to manually shard and re-shard your data.

If you need to shard your Redis data and run it as a cluster on multiple nodes, you know of this issue. Redis is a single threaded process that runs on a single core. This means the user needs to figure out

manual sharding of their data into Redis “databases”
how many databases to run per node
ensure master-slave replicas for databases don’t run on the same machine

That’s hard enough to do, but if you ever need to scale out by adding some nodes into this Redis cluster — you need to pretty much redo the whole exercise right from re-sharding your data.

How YugabyteDB makes this simple:

YugaByte automatically shards your data, and as a result it can scale both your queries and your data linearly as you add nodes.

3. Your entire dataset need not fit in memory

Very often, developers end up caching the entire dataset in Redis — which means the entire dataset is in memory even if a small percentage of it is being currently accessed. This is usually because:

most of the queries need low read latencies but the access pattern varies with time
the app gets very complex when paging data in on a miss and invalidating the cache on an update

The result is an expensive infrastructure and lower dev agility because of the complicated app.

How YugabyteDB makes this simple

Yugabyte has a built-in block cache where it can page data on demand and expire unused data automatically. You also don’t need to worry about invalidating data on writes, that is taken care of by the DB. Furthermore, YugaByte can deliver consistently low latencies in the order of 0.3ms — 1ms depending on the workload with a very stable p99 latency.

In fact, we recently published a benchmark on Google cloud for uncached, random reads on YugabyteDB — delivering 77K ops/sec with 0.88ms latency while serving results from disk!

4. If your app needs another DB with Redis, it is readily available.

A lot of apps need other functionality from a database in addition to what Redis provides. This could be things such as:

organizing data into multiple tables with a well-defined schema
sorting columns in an ascending or descending manner
access patterns such as a Spark analytics, graph databases, etc
need for consistent secondary indexes
ability to perform ACID transactions

This is usually achieved by supplementing Redis with one or more databases, which makes the setup very complex.

How YugabyteDB makes this simple

YugabyteDB offers polyglot persistence to power these diverse workloads and access patterns in a unified database. You are no longer forced to pick multiple products and incur the operational learning curves and overheads for these varied access patterns/workloads.

YugabyteDB supports NoSQL with ACID transactions and secondary indexes. You can use the Cassandra query language for tables with schema and column sorting. YugabyteDB is also well integrated with Apache Spark and JanusGraph, a popular, open-source graph database API. Additionally, YugabyteDB is excellent at handling a lot of data volume per node, has strong consistency and very high performance.

5. No need to worry about BGSAVE or master/slaves replicas.

If you are using Redis checkpointing with the BGSAVE command to persist your data, you already know that it could affect your query latencies. To get around this, most users perform the BGSAVE based checkpointing on a master, and read from a slave.

How YugaByte makes this simple

YugaByte makes all nodes symmetric and automatically saves incoming the data incrementally — without you having to do any manual configuration. So there is no expensive periodic flush of the entire dataset required!

6. Built-in replication and caching for global data distribution

Apps often need to deal with geographically dispersed users and prefer to keep copies of the data closer to the users for low read latencies. Thanks to public clouds offering data centers in many geographic regions, this demand has become much more commonplace. When using vanilla Redis, you have to take care of a number of things manually such as:

setting up the replication of data across regions
writing the app in such a way that user-writes are consistent and user-reads are served from the closest region
the run-book on how to recover when failures happen
scaling this setup or changing things such as machine types or deployed regions is a very laborious, error-prone manual process.

How YugabyteDB makes this simple

YugaByte offers a simple, intent based way to setup global replication within minutes. As for the replication choices, YugaByte offers sync and async options depending on the latencies and recovery objectives. For reads, YugaByte offers tunable consistency — with the option of reading the primary data like a database would or performing local DC reads to get a timeline consistent cache-like behavior.