54

I have read about Redis and RocksDB, I don't get the advantages of Redis over RocksDB.

I know that Redis is all in-memory and RocksDB is in-memory and uses flash storage. If all data fits in-memory, which one should I choose? do they have the same performance? Redis scales linearly with the number of CPU's? I guess that there are others differences that I don't get.

I have a dataset which fits in-memory and I was going to choose Redis but it seems that RocksDB offers me the same and if one day the dataset grows too much I wouldn't have to be worried about the memory.

Utkarsh Naiknaware
  • 126
  • 13
Guille
  • 2,248
  • 3
  • 24
  • 42

6 Answers6

111

They have nothing in common. You are trying to compare apples and oranges here.

Redis is a remote in-memory data store (similar to memcached). It is a server. A single Redis instance is very efficient, but totally non scalable (regarding CPU). A Redis cluster is scalable (regarding CPU).

RocksDB is an embedded key/value store (similar to BerkeleyDB or more exactly LevelDB). It is a library, supporting multi-threading and a persistence based on log-structured merge trees.

Didier Spezia
  • 70,911
  • 12
  • 189
  • 154
  • 3
    Thanks, I guess that it's much faster RocksDB since it's embedded and Redis is more used when you could have many application and they need to access some database in-memory. I didn't know that RocksDB was an embedded key/value store. – Guille Aug 05 '15 at 14:42
  • 2
    Apologies for my ignorance, but by "embedded key/value store", do you mean it runs on only a single computer? Basically a local database? – speedplane May 15 '17 at 03:30
  • 13
    I mean it only runs on a local computer and from a local process. It is a library, not a server. – Didier Spezia May 16 '17 at 15:47
  • use myrocks to have a 'server' rocksdb with mysql protocol – user2559936 Mar 18 '18 at 14:55
  • While they are different, they are also in fact compatible. Check out the Redis on Flash project, which uses RocksDB to spill data onto disk. https://redislabs.com/redis-enterprise/technology/redis-on-flash/ – nday Jul 15 '21 at 14:22
33

While Didier Spezia's answer is correct in his distinction between the two projects, they are linked by a project called LedisDB. LedisDB is an abstraction layer written in Go that implements much of the Redis API on top of storage engines like RocksDB. In many cases you can use the same Redis client library directly with LedisDB, making it almost a drop in replacement for Redis in certain situations. Redis is obviously faster, but as OP mentioned in his question, the main benefit of using RocksDB is that your dataset is not limited to the amount of available memory. I find that useful not because I'm processing super large datasets, but because RAM is expensive and you can get more milage out of smaller virtual servers.

Will Krause
  • 626
  • 6
  • 12
  • 3
    Redis is not obviously faster than RocksDB, actually the oppositie is true. RocksDB is designed to be faster because it is embedded DB that comes with a library and not a server that you must connect to. – Pawel Oct 01 '20 at 06:43
16
  1. Redis, in general, has more functionalities than RocksDB. It can natively understand the semantics of complex data structures such as lists and arrays . RocksDB, in contrast, looks at the stored values as a blob of data. If you want to do any further processing, you need to bring the data to your program and process it there (in other words, you can't delegate the processing to the database engine aka RocksDB).
  2. RocksDB only runs on a single server. Redis has a clustered version (though it is not free)
  3. Redis is built for in-memory computation, though it also support backing the data up to the persistent storage, but the main use cases are in memory use cases. RocksDB by contrast is usually used for persisting data and in most cases store the data on persistent medium.
  4. RocksDB has a better multi-threaded support (specially for reads --writes still suffer from concurrent access).

Many memcached servers use Redis (where the protocol used is memcached but underlying server is Redis). This doesn't used most of Redis's functionality but is one case that Redis and RocksDB both function similarly (as a KVS though still in different context, where Redis based memcached is a cache but RocksDB is a database, though not an enterprise grade one)

Reza Sadri
  • 198
  • 1
  • 5
5

Both are Key-Value Stores, so they have something in common.

As others mentioned RocksDB is embedded (as a library), while Redis is a standalone server. Moreover, Redis can sharded.

RocksDB Redis
persisted on disk stored in memory
strictly serializable eventually consistent
sorted collections no sorting
vertical scaling horizontal scaling

If you don't need horizontal scaling, RocksDB is often a superior choice. Some people would assume that an in-memory store would be strictly faster than a persistent one, but it is not always true. Embedded storage doesn't have networking bottlenecks, which matters greatly in practice, especially for vertical scaling on bigger machines.

If you need to server RocksDB over a network or need high-level language bindings, the most efficient approach would be using project UKV. It, however, also supports other embedded stores as engines and provides higher-level functionality, such as Graph collections, similar to RedisGraph, and Document collections, like RedisJSON.

ashvardanian
  • 424
  • 1
  • 6
  • 17
4

@Guille If you know the behavior of hot data(getting fetched frequently) is based of time-stamp then Rocksdb would a smart choice, but do optimize it for fallback using bloom-filters .If your hot data is random ,then go for Redis .Using rocksDB entirely in memory is not generally recommended in log-structured databases like Rocksdb and its specifically optimized for SSD and flash storage .So my recommendation would be to understand the usecase and pick a DB for that particular usecase .

sumit jha
  • 91
  • 1
  • 10
3

Redis is distributed, in-memory data store where as Rocks DB is embedded key-value store and not distributed.

Anil
  • 301
  • 4
  • 9