python 哪个键/值存储最有前途/最稳定？

Which key/value store is the most promising/stable?

提问by Mike Trpcic

I'm looking to start using a key/value store for some side projects (mostly as a learning experience), but so many have popped up in the recent past that I've got no idea where to begin. Just listing from memory, I can think of:

我希望开始在一些副项目中使用键/值存储（主要是作为一种学习经验），但最近出现了太多这样的项目，我不知道从哪里开始。只是凭记忆列举，我能想到：

1. CouchDB
2. MongoDB
3. Riak
4. Redis
5. Tokyo Cabinet
6. Berkeley DB
7. Cassandra
8. MemcacheDB

1. 沙发数据库
2. MongoDB
3. 里亚克
4. Redis
5. 东京内阁
6. 伯克利数据库
7. 卡桑德拉
8. 内存缓存数据库

And I'm sure that there are more out there that have slipped through my search efforts. With all the information out there, it's hard to find solid comparisons between all of the competitors. My criteria and questions are:

而且我确信还有更多的东西从我的搜索工作中溜走了。有了所有信息，很难在所有竞争对手之间找到可靠的比较。我的标准和问题是：

1. (Most Important) Which do you recommend, and why?
2. Which one is the fastest?
3. Which one is the most stable?
4. Which one is the easiest to set up and install?
5. Which ones have bindings for Python and/or Ruby?

1. （最重要）您推荐哪个，为什么？
2. 哪个最快？
3. 哪个最稳定？
4. 哪一个最容易设置和安装？
5. 哪些有 Python 和/或 Ruby 的绑定？

Edit:
So far it looks like Redis is the best solution, but that's only because I've gotten one solid response (from ardsrk). I'm looking for more answers like his, because they point me in the direction of useful, quantitative information. Which Key-Value store do youuse, and why?

编辑：
到目前为止，Redis 是最好的解决方案，但这只是因为我得到了一个可靠的回应（来自 ardsrk）。我正在寻找更多像他这样的答案，因为它们为我指明了有用的定量信息的方向。您使用哪个键值存储，为什么？

Edit 2:
If anyone has experience with CouchDB, Riak, or MongoDB, I'd love to hear your experiences with them (and even more so if you can offer a comparative analysis of several of them)

编辑 2：
如果有人对 CouchDB、Riak 或 MongoDB 有经验，我很想听听您的经验（如果您能对其中的几个进行比较分析，则更是如此）

采纳答案by ardsrk

Which do you recommend, and why?

你推荐哪个，为什么？

I recommend Redis. Why? Continue reading!!

我推荐Redis。为什么？继续阅读！！

Which one is the fastest?

哪个最快？

I can't say whether it's the fastest. But Redis is fast. It's fast because it holds all the data in RAM. Recently, virtual memory feature was added but still all the keys stay in main memory with only rarely used values being swapped to disk.

我不能说它是否是最快的。但是 Redis很快。它很快，因为它将所有数据保存在 RAM 中。最近，添加了虚拟内存功能，但所有键仍然保留在主内存中，只有很少使用的值被交换到磁盘。

Which one is the most stable?

哪个最稳定？

Again, since I have no direct experience with the other key-value stores I can't compare. However, Redis is being used in production by many web applications like GitHuband Instagram, among many others.

同样，由于我对其他键值存储没有直接经验，因此无法进行比较。但是，Redis 正被许多 Web 应用程序（如GitHub和Instagram等）用于生产。

Which one is the easiest to set up and install?

哪一个最容易设置和安装？

Redis is fairly easy to setup. Grab the sourceand on a Linux box run make install. This yields redis-serverbinary that you could put it on your path and start it.

Redis 相当容易设置。获取源代码并在 Linux 机器上运行make install。这会生成redis-server二进制文件，您可以将其放在路径上并启动它。

redis-serverbinds to port 6379 by default. Have a look at redis.confthat comes with the source for more configuration and setup options.

redis-server默认绑定到端口 6379。查看redis.conf源代码中的更多配置和设置选项。

Which ones have bindings for Python and/or Ruby?

哪些有 Python 和/或 Ruby 的绑定？

Redis has excellent Rubyand Pythonsupport.

Redis 具有出色的Ruby和Python支持。

In response to Xorlev's commentbelow: Memcached is just a simple key-value store. Redis supports complex data typeslike lists, sets and sorted sets and at the same time provides a simple interfaceto these data types.

回应以下Xorlev 的评论：Memcached 只是一个简单的键值存储。Redis 支持复杂的数据类型，如列表、集合和排序集合，同时为这些数据类型提供了一个简单的接口。

There is also make 32bitthat makes all pointers only 32-bits in size even on 64 bit machines. This saves considerable memory on machines with less than 4GB of RAM.

make 32bit即使在 64 位机器上，这也使得所有指针的大小只有 32 位。这可以在 RAM 小于 4GB 的机器上节省大量内存。

回答by Vagif Verdi

You need to understand what modern NoSQL phenomenon is about.
It is not about key-value storages. They've been available for decades (BerkeleyDB for example). Why all the fuss now ?

您需要了解现代 NoSQL 现象是关于什么的。
这与键值存储无关。它们已经可用了几十年（例如 BerkeleyDB）。为什么现在这么大惊小怪？

It is not about fancy document or object oriented schemas and overcoming "impedance mismatch". Proponents of these features have been touting them for years and they got nowhere.

它不是关于花哨的文档或面向对象的模式和克服“阻抗不匹配”。这些功能的支持者多年来一直在吹捧它们，但他们一无所获。

It is simply about adressing 3 technical problems: automatic (for maintainers) and transparent (for application developers) failover, sharding and replication. Thus you should ignore any trendy products that do not deliver on this front. These include Redis, MongoDB, CouchDB etc. And concentrate on truly distributed solutions like cassandra, riak etc.

它只是解决 3 个技术问题：自动（对于维护人员）和透明（对于应用程序开发人员）故障转移、分片和复制。因此，您应该忽略任何不在这方面交付的时尚产品。其中包括 Redis、MongoDB、CouchDB 等。并专注于真正的分布式解决方案，如 cassandra、riak 等。

Otherwise you'll loose all the good stuff sql gives you (adhoc queries, Crystal Reports for your boss, third party tools and libraries) and get nothing in return.

否则，您将失去 sql 为您提供的所有好东西（即席查询、老板的 Crystal Reports、第三方工具和库）而得不到任何回报。

回答by AdamKG

At this year's PyCon, Jeremy Edberg of Reddit gave a talk:

在今年的 PyCon 上，Reddit 的 Jeremy Edberg 发表了演讲：

http://pycon.blip.tv/file/3257303/

http://pycon.blip.tv/file/3257303/

He said that Reddit uses PostGres as a key-value store, presumably with a simple 2-column table; according to his talk it had benchmarked faster than any other key-value store they had tried. And, of course, it's very mature.

他说 Reddit 使用 PostGres 作为键值存储，大概是一个简单的 2 列表；根据他的谈话，它的基准测试速度比他们尝试过的任何其他键值存储都要快。而且，当然，它非常成熟。

Ultimately, OverClocked is right; your use case determines the best store. But RDMBSs have long been (ab)used as key-value stores, and they can be very fast, too.

最终，超频是正确的；您的用例决定了最佳商店。但是 RDMBS 长期以来一直（ab）用作键值存储，它们也可以非常快。

回答by MattGrommes

I've been playing with MongoDB and it has one thing that makes it perfect for my application, the ability to store complex Maps/Lists in the database directly. I have a large Map where each value is a list and I don't have to do anything special just to write and retrieve that without knowing all the different keys and list values. I don't know much about the other options but the speed and that ability make Mongo perfect for my application. Plus the Java driver is very simple to use.

我一直在玩 MongoDB，它有一件事使它非常适合我的应用程序，即直接在数据库中存储复杂的地图/列表的能力。我有一个大地图，其中每个值都是一个列表，我不必做任何特殊的事情就可以在不知道所有不同的键和列表值的情况下编写和检索它。我对其他选项知之甚少，但速度和这种能力使 Mongo 非常适合我的应用程序。此外，Java 驱动程序使用起来非常简单。

回答by OverClocked

They all have different features. And don't forget Project Voldemortwhich is actually used/tested by LinkedIn in their production before each release.

他们都有不同的特点。并且不要忘记伏地魔项目，在每次发布之前，LinkedIn 在他们的产品中实际使用/测试过这个项目。

It's hard to compare. You have to ask yourself what you need: e.g. do you want partitioning? if so then some of them, like CouchDB, won't support it. Do you want erasure coding? Then most of them don't have that. Etc.

很难比较。你必须问自己你需要什么：例如你想要分区吗？如果是这样，那么其中一些，如 CouchDB，将不支持它。你想要擦除编码吗？那么他们中的大多数人都没有。等等。

Berkeley DB is a very basic, low level storage engine, that perhaps can be excused from this discussion. Several key-value systems are built on top of it, to provide additional features like replication, versioning, coding, etc.

Berkeley DB 是一个非常基础的、低级的存储引擎，也许可以从这个讨论中得到原谅。几个键值系统建立在它之上，以提供额外的功能，如复制、版本控制、编码等。

Also, what does your application need? Several of the solutions contain complexity that may not be necessary. E.g. if you just store static data that won't change, you can store them under data's SHA-1 content hash (i.e. use the content-hash as key). In this case, you don't have to worry about freshness, synchronization, versioning, and lots of complexities can be removed.

另外，您的应用程序需要什么？一些解决方案包含可能没有必要的复杂性。例如，如果您只存储不会更改的静态数据，则可以将它们存储在数据的 SHA-1 内容哈希下（即使用内容哈希作为密钥）。在这种情况下，您不必担心新鲜度、同步、版本控制，并且可以消除许多复杂性。

回答by tommy chheng

One distinction you have to make is what will you use the DB for? Don't jump on board just because it's trendy. Do you need a key value store? or do you need a document based store? What is your memory footprint requirement? running it on a small VM or a separate one?

您必须做出的一个区别是您将使用数据库做什么？不要仅仅因为它很时髦就加入。你需要一个键值存储吗？或者你需要一个基于文档的存储？您的内存占用要求是多少？在小型 VM 或单独的 VM 上运行它？

I recommend listing your requirements first and then seeing which ones overlap with your requirements.

我建议首先列出您的要求，然后查看哪些与您的要求重叠。

With that said, I have used CouchDB/MongoDB and prefer to use MongoDB for its ease of setup and best transition from mysql style queries. I chose mongodb over sql because of dynamic schemas(no migration files!) and better data modeling(arrays, hashes). I did not evaluate based on scalability.

话虽如此，我已经使用了 CouchDB/MongoDB 并且更喜欢使用 MongoDB，因为它易于设置和从 mysql 样式查询的最佳转换。由于动态模式（没有迁移文件！）和更好的数据建模（数组、哈希），我选择了 mongodb 而不是 sql。我没有根据可扩展性进行评估。

MongoMapper is a great MongoDB orm mapper for Ruby and there's already a working Rails 3 fork.

MongoMapper 是一个伟大的 MongoDB orm 映射器，适用于 Ruby，并且已经有一个可用的 Rails 3 分支。

I listed some more details about why I prefered mongodb in my scribd slides http://tommy.chheng.com/index.php/2010/02/mongodb-for-natural-development/

我在我的 scribd 幻灯片中列出了更多关于为什么我更喜欢 mongodb 的细节 http://tommy.chheng.com/index.php/2010/02/mongodb-for-natural-development/

回答by drr

I notice how everyone is confusing memcached with memcachedb. They are two different systems. The op asked about memcachedb.

我注意到每个人都是如何将 memcached 与 memcachedb 混淆的。它们是两个不同的系统。操作员询问了 memcachedb。

memcached is memory storage. memcachedb uses Berkeley DB as its datastore.

memcached 是内存存储。memcachedb 使用 Berkeley DB 作为其数据存储。

回答by Ferruccio

I only have experience with Berkeley DB, so I'll mention what I like about it.

我只有 Berkeley DB 的经验，所以我会提到我喜欢它的地方。

• It is fast
• It is very mature and stable
• It has outstanding documentation
• It has C,C++,Java & C# bindings out of the box. Other language bindings are available. I believe Python comes with bindings as part of its "batteries".

• 它很快
• 它非常成熟和稳定
• 它有出色的文档
• 它具有开箱即用的 C、C++、Java 和 C# 绑定。其他语言绑定可用。我相信 Python 附带绑定作为其“电池”的一部分。

The only downside I've run into is that the C# bindings are new and don't seem to support every feature.

我遇到的唯一缺点是 C# 绑定是新的，似乎并不支持所有功能。

回答by Bert

Which key value store is the most promising/stable?

哪个键值存储最有前途/最稳定？

G-WAN KV storelooks rather promising:

G-WAN KV 商店看起来很有前途：

DB engine            Traversal
-----------          ----------------------------
SQLite               0.261 ms  (b-tree)
Tokyo-Cabinet (TC)   4.188 ms  (hash table)
TC-FIXED             0.103 ms  (fixed-size array)
G-WAN KV             0.010 ms  (unamed)

Also, it is used internally by G-WAN webserver, known for its high concurrency performances (that's for the stabilityquestion).

此外，它由 G-WAN 网络服务器内部使用，以其高并发性能而闻名（这是为了稳定性问题）。

回答by mikerobi

There is also zodb.

还有zodb。