是否有一个键值存储会给我以下内容:
我基本上想要一些我可以使用“单一”的东西，而不必担心有 memcached、一个数据库和几个存储组件，所以是的，我确实想要一个你可以说的数据库“银弹”。
谢谢
祖拜尔
到目前为止的答案:
BackBlaze 之上的 MogileFS - 据我所知，这只是一个文件系统，经过一些研究，它似乎只适用于大型图像文件
东京暴君 - 需要光云。当您添加新节点时，这不会自动缩放。我确实研究了这个，但对于适合单个节点的查询来说似乎非常快
Riak - 这是我正在研究自己的一个，但我还没有任何结果
Amazon S3 - 是否有人将其用作生产中唯一的持久层？从我所见，它似乎用于存储图像，因为复杂的查询太昂贵了
@shaman 建议使用 Cassandra - 绝对是我正在研究的
到目前为止，似乎没有满足我提到的标准的数据库或键值存储，即使在提供 100 分的悬赏之后，问题也没有得到回答!
最佳答案
你对开源软件的要求太多了。
如果您的预算中有几十万美元用于购买某些企业级软件，那么有几种解决方案。没有什么可以立即满足您的要求，但是有些公司的产品与您正在寻找的产品相近。
“快速(因此将允许在其上执行查询)”
如果你有一个键值存储，一切都应该非常快。然而问题是，如果没有建立在键值存储之上的本体或数据模式，您最终将针对每个查询遍历整个数据库。您需要一个包含要存储的每种“类型”数据的键的索引。
在这种情况下，您通常可以对所有约 15,000 台机器并行执行查询。瓶颈在于廉价硬盘的上限为每秒 50 次搜索。如果您的数据集适合 RAM，您的性能将非常高。但是，如果键存储在 RAM 中，但没有足够的 RAM 来存储值，系统将在几乎所有键值查找中转到磁盘。每个 key 都位于驱动器上的随机位置。
这将您限制为每台服务器每秒 50 次键值查找。而当键值对存储在 RAM 中时，在商用硬件(例如 Redis)上每台服务器每秒获得 10 万次操作并不罕见。
然而，串行磁盘读取性能非常高。我已经在串行读取中找到了 50 MB/s (800 Mb/s) 的驱动器。因此，如果您将值存储在磁盘上，则必须构建存储结构，以便可以串行读取需要从磁盘读取的值。
那就是问题所在。除非您将键值对完全存储在 RAM 中(或将值存储在 SSD 驱动器上的 RAM 中)，或者如果您在 key ，然后将数据聚集在磁盘上，以便可以通过串行磁盘读取轻松检索给定类型的所有 key 。
如果一个键有多种类型(比如你在数据库中有数据类型的继承关系)，那么这个键就是多个索引表的一个元素。在这种情况下，您将不得不进行时空权衡来构造这些值，以便可以从光盘中连续读取它们。这需要存储 key 值的冗余副本。
您想要的将比键值存储更高级一点，尤其是在您打算进行查询时。然而，存储大文件的问题不是问题。假设您的系统可以按键高达 50 兆。然后，您只需将 1 gig 文件分解为 50 meg 段，并为每个段值关联一个键。使用简单的服务器，可以直接将您想要的文件部分转换为键值查找操作。
实现冗余的问题更加困难。很容易为服务器的键值表“注入(inject)代码”或“部分文件”，这样服务器的数据可以以线速 (1 Gb/s) 重建到备用服务器上，如果特定服务器死机。通常，您可以使用“心跳”系统来检测服务器死亡，如果服务器在 10 秒内没有响应，就会触发该系统。甚至可以针对部分文件编码的键值表进行键值查找，但这样做效率低下，但仍可为您提供服务器故障事件的备份。一个更大的问题是几乎不可能使备份保持最新，并且数据可能是 3 分钟前的。如果您进行大量写入，备份功能将引入一些性能开销，但如果您的系统主要进行读取，则开销可以忽略不计。
我不是在故障模式下维护数据库一致性和完整性约束的专家，所以我不确定这个要求会带来什么问题。如果您不必担心这一点，它会大大简化系统的设计及其要求。
Fast (so will allow queries to be performed on top of it)
首先，当你的数据库这么大时，忘记连接或任何比 n*log(n) 扩展得更快的操作。您可以做两件事来替换通常使用连接实现的功能。您可以构建数据以便您不需要进行连接，或者您可以“预编译”您正在执行的查询并进行时空权衡并预先计算连接并存储它们以供提前查找.
对于语义 Web 数据库，我认为我们会看到人们预编译查询并进行时空权衡，以便在即使是中等大小的数据集上也能获得不错的性能。我认为这可以由数据库后端自动透明地完成，应用程序程序员无需付出任何努力。然而，我们才刚刚开始看到企业数据库为关系数据库实现这些技术。据我所知，没有任何开源产品可以做到这一点，如果有人试图对水平可扩展数据库中的链接数据执行此操作，我会感到惊讶。
对于这些类型的系统，如果您有额外的 RAM 或存储空间，出于性能原因，最好使用它来预先计算和存储常见子查询的结果，而不是向键值存储添加更多冗余。按您要查询的键预先计算结果和顺序，以将 n^2 连接转换为 log(n) 查找。任何比 n*log(n) 扩展性差的查询或子查询都需要执行其结果并将其缓存在键值存储中。
如果您进行大量写入，则缓存的子查询失效的速度将比处理它们的速度快，并且没有性能优势。处理缓存子查询的缓存失效是另一个棘手的问题。我认为解决方案是可能的，但我还没有看到。
欢迎来到 hell 。您不应该期望再过 20 年免费获得这样的系统。
So far it seems that there is no database or key value store that fulfills the criteria I mentioned, not even after offering a bounty of 100 points did the question get answered!
你在寻求奇迹。等待 20 年，直到我们拥有开源奇迹数据库，否则您应该愿意为根据您的应用程序需求定制的解决方案付费。
关于scalability - 动态水平可扩展的键值存储，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2092348/