How does Leveldb compare with Redis or Riak or Tokyo Tyrant?

Question

Leveldb seems to be a new interesting persistent key value store from Google. How does Leveldb differ from Redis or Riak or Tokyo Tyrant? In what specific use cases is one better than the other?

Solution 1

I find I disagree a bit with colum's criteria though the differences between leveldb and Redis he points out are spot on.

Do you need concurrency? I'd go with Redis. I say this because Redis already has the code written to handle it. Any time I can use well-written Other People's Code to handle concurrency, so much the better. I don't simply mean multi-threaded apps, but include in this the notion of multiple processes - be they on the same system or not. Even then, not needing to write and debug locking in a multi-threaded app has a big advantage in my eyes.

Do you want it completely self-contained within the app? Go with leveldb as it is a library. Do need or want more than just a k/v? Go with Redis.

I'm only commenting on the leveldb or Redis aspect as I don't consider myself fluent enough yet in Riak or TT to comment on their better suits.

In short if all you are looking for is persistent key-value store in a single-threaded app then leveldb is the option to choose among your list (another would be Tokyo cabinet or good ole BerkleyDB or even sqlite). But if you want more than that, choose one of the others.

[edit: updated explanation wrt. concurrency]

Solution 2

I only add this because in both of the previous answers I don't see this (important) distinction made...

• Redis: Is a database server. You communicate with it via a custom binary protocol (via client library typically).
• LevelDB: Is a library that implements a key-value store. You communicate with it by calling the C++ API directly.

If you are familiar with SQLite and how popular it has become as an embedded DB for client applications (I believe both Android and iOS ship it) then you see where something like LevelDB fits in.

Imagine you were writing a complex PIM app, maybe some enterprise address book manager meant to be installed on individual computers in the office. You wouldn't want to store all that data in XML or JSON that you wrote/parsed yourself inside your app -- if you could, you'd much rather store it in a DB to have easier access patterns.

But you also don't want to have to ship and install a local copy of Redis, running on some random port just so you can connect to it... you want a DB that you can call directly and natively from your app and not worry about "over the wire" communication... you want the raw guts of a DB without any of the network-ey stuff that you don't need in a client only app.

This is where LevelDB sits.

It is a different tool for a different job.

Solution 3

Differences:

• Redis is a server, while Leveldb is "a library that implements a fast persistent key-value store". Therefor, with Redis, you have to poll the server. With Leveldb, the database is stored on disk, making it a lot slower than Redis, which is stored in memory.
• Leveldb is only offers key/store. Redis has this as well, but also has a lot more functions and features

Similarities:

• They both have Key/Store methods

Reasons to choose one over another

If you are making a C/C++ app, then leveldb is the way to go, provided you just need a database that is not as resource heavy as mysql. Leveldb provides code level access, while with redis you need an interface that has to communicate with the server. In any other app, Redis is the way to go. Not only do you get an actual server, that more than one application can access, but you get other features like write to disk, sets, list, hashes, and it goes on.

Comments

[rafidude]

Please go through Hacker News thread for additional background.

[rafidude]

Not sure if I agree with your analysis. Please see Hacker News thread. Both in terms of concurrency and speed leveldb seems superior though I am still looking for objective studies.

[The Real Bill]

I guess it depends on why you are going with concurrency, and how you need it. I didn't advocate that Redis would be faster with concurrency though to be thorough I didn't say why (I'll fix that). But from the standpoint of "I don't have to write code to handle the concurrency", I view that as a major factor.

[The Real Bill]

Wow, down votes w/o explanation?

[beatgammit]

Redis can run on Unix domain sockets. I've done this on an embedded device to speed up boot (don't need networking to start Redis).

[Crescent Fresh]

> Redis, which is stored in memory Note to readers, this is slightly misleading. It is retained on disk and memory. Data stored in redis is not volatile, unlike say, memcached.

[skan]

any benchmark Redis vs MonetDB or VoltDB or RocksDB?

[superhero]

@CrescentFresh But it's impossible to remove the memory part from redis, correct? If one is looking to store multiple GB of data in the persistence and don't have the ram to cover it, then redis isn't something that could be used, right?

[Crescent Fresh]

@Erik: not only do you need the ram to cover it, but you need extra for background saves. Your question and this comment are explained in full at the faq.

[Erik Aronesty]

You can get both.. with ssdb. Leveldb's compression and speed, with the convenience of a server.

[jlh]

It is wrong to say that leveldb is slower than redis just because the former touches the disks. This mostly depends on the network latency between server and client and whether it's faster or slower than your disk accesses. The disks might very well be SSDs and the files might very well be in your cache; actually, having the working set fit into caches is generally recommended for any disk-based database. If you do that, your single-process, single-client leveldb will be a LOT faster than redis!

[Qqwy]

Side note: Riak uses LevelDB (or Bitcask) under the hood.