Leveldb 与 Redis 或 Riak 或 Tokyo Tyrant 相比如何？
Leveldb 似乎是 Google 推出的一个新的有趣的持久键值存储。 Leveldb 与 Redis 或 Riak 或 Tokyo Tyrant 有什么不同？在哪些具体用例中，其中一种比另一种更好？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我添加这个只是因为在前面的两个答案中我没有看到这个（重要的）区别......
如果您熟悉 SQLite 以及它作为客户端应用程序的嵌入式数据库的流行程度（我相信 Android 和 iOS 都提供了它），那么您就会看到像 LevelDB 这样的东西适合的地方。
想象一下您正在编写一个复杂的 PIM 应用程序，也许是一些企业地址簿管理器旨在安装在办公室的个人计算机上。您不想将您自己在应用程序中编写/解析的所有数据存储在 XML 或 JSON 中 - 如果可以，您宁愿将其存储在数据库中以获得更容易的访问模式。
但您也不希望必须运输和安装 Redis 的本地副本，在某个随机端口上运行，以便您可以连接到它...您想要一个可以直接从应用程序本地调用的数据库，而不是担心“通过线路”的通信...您想要数据库的原始内容，而不需要任何在仅客户端应用程序中不需要的网络内容。
这就是 LevelDB 所在的位置。
对于不同的工作，它是不同的工具。
I only add this because in both of the previous answers I don't see this (important) distinction made...
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.
我发现我有点不同意 colum 的标准，尽管他指出的 leveldb 和 Redis 之间的差异是正确的。
你需要并发吗？我会选择 Redis。我这样说是因为 Redis 已经编写了处理它的代码。任何时候我都可以使用编写良好的其他人的代码来处理并发，那就更好了。我不仅仅指多线程应用程序，还包括多个进程的概念 - 无论它们是否在同一系统上。即便如此，在我看来，不需要在多线程应用程序中编写和调试锁定也具有很大的优势。
您希望它在应用程序中完全独立吗？使用 leveldb，因为它是一个库。需要或想要的不仅仅是 ak/v 吗？与 Redis 一起使用。
我只评论 leveldb 或 Redis 方面，因为我认为自己在 Riak 或 TT 方面还不够流利，无法评论他们更好的套装。
简而言之，如果您正在寻找的是单线程应用程序中的持久键值存储，那么 leveldb 就是您的列表中的一个选项（另一个是 Tokyo Cabinet 或好的 ole BerkleyDB 甚至 sqlite）。但如果您想要更多，请选择其他之一。
[编辑：更新了解释。并发]
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]
区别：
相似之处：
选择其中一个的原因
如果你正在制作一个 C /C++ 应用程序，那么 leveldb 就是最佳选择，只要您只需要一个不像 mysql 那样占用大量资源的数据库。 Leveldb 提供代码级访问，而使用 redis，您需要一个与服务器通信的接口。在任何其他应用程序中，Redis 都是最佳选择。您不仅可以获得一台实际的服务器（多个应用程序可以访问），还可以获得其他功能，例如写入磁盘、集合、列表、哈希等等。
Differences:
Similarities:
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.