How does Leveldb compare with Redis or Riak or Tokyo Tyrant? [closed]

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 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 2:

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 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.