动态水平可扩展键值存储

Posted 2023-02-23

技术标签:

【中文标题】动态水平可扩展键值存储【英文标题】：dynamically horizontal scalable key value store 【发布时间】：2011-01-06 17:36:23 【问题描述】：

是否有一个键值存储可以为我提供以下信息：

请允许我简单地添加和删除节点，并将自动重新分配数据请允许我删除节点，但仍有 2 个额外的数据节点来提供冗余允许我存储最大为 1GB 的文本或图像可存储高达 100TB 数据的小型数据快速（因此允许在其上执行查询）让所有这些对客户透明适用于 Ubuntu/FreeBSD 或 Mac 免费或开源

我基本上想要一些我可以使用“单一”的东西，而不必担心拥有 memcached、一个数据库和几个存储组件，所以是的，我确实想要一个可以说的数据库“银弹”。

谢谢

祖拜尔

到目前为止的答案：在 BackBlaze 之上的 MogileFS - 据我所知，这只是一个文件系统，经过一些研究，它似乎只适用于大图像文件

东京暴君 - 需要光云。当您添加新节点时，这不会自动缩放。我确实对此进行了研究，但对于适合单个节点的查询来说似乎非常快

Riak - 这是我正在调查自己的一个，但我还没有任何结果

Amazon S3 - 有人在生产中使用它作为他们唯一的持久层吗？从我所见，它似乎用于存储图像，因为复杂的查询太昂贵了

@shaman 建议 Cassandra - 绝对是我正在研究的一个

到目前为止，似乎没有满足我提到的标准的数据库或键值存储，即使在提供 100 分的赏金之后，问题也没有得到回答！

【问题讨论】：

到目前为止，似乎没有满足我提到的标准的数据库或键值存储，即使在提供 100 分的赏金之后，问题也没有得到回答！我正在开发一个可以满足您要求的系统。存储后端即将推出，它是一个名为 aodbm (sf.net/projects/aodbm) 的单独项目。 【参考方案1】：

你对开源软件的要求太高了。

如果您有几十万美元的预算来购买某些企业级软件，那么有几种解决方案。开箱即用无法满足您的需求，但有些公司的产品与您正在寻找的产品相近。

“快速（因此将允许在其上执行查询）”

如果您有键值对存储，那么一切都应该非常快。然而，问题变成了如果没有构建在键值存储之上的本体或数据模式，您最终将针对每个查询遍历整个数据库。您需要一个包含要存储的每种“类型”数据的键的索引。

在这种情况下，您通常可以对大约 15,000 台机器并行执行查询。瓶颈在于便宜的硬盘驱动器每秒可进行 50 次寻道。如果您的数据集适合 RAM，那么您的性能将非常高。但是，如果键存储在 RAM 中但没有足够的 RAM 来存储值，则系统将在几乎所有键值查找时转到磁盘。每个键都位于驱动器上的随机位置。

这将您限制为每台服务器每秒 50 次键值查找。而当键值对存储在 RAM 中时，在商用硬件（例如 Redis）上每台服务器每秒执行 10 万次操作的情况并不罕见。

然而，串行磁盘读取性能非常高。我在串行读取时寻求驱动器达到 50 MB/s (800 Mb/s)。因此，如果您将值存储在磁盘上，则必须构建存储结构，以便可以串行读取需要从磁盘读取的值。

这就是问题所在。除非您将键值对完全存储在 RAM 中（或 RAM 中的键与 SSD 驱动器上的值），否则您无法在 vanilla 键值存储上获得良好的性能，或者如果您在密钥，然后将数据聚集在磁盘上，以便可以通过串行磁盘读取轻松检索给定类型的所有密钥。

如果一个键有多种类型（例如，如果您在数据库中有数据类型继承关系），那么该键将是多个索引表的一个元素。在这种情况下，您将不得不进行时空权衡来构造这些值，以便可以从磁盘中连续读取它们。这需要存储键值的冗余副本。

您想要的将比键值存储更高级，尤其是在您打算进行查询时。然而，存储大文件的问题不是问题。假装您的系统最多可以键入 50 兆。然后，您只需将 1 gig 文件分解为 50 meg 段，并为每个段值关联一个键。使用简单的服务器，可以直接将您想要的文件部分转换为键值查找操作。

实现冗余的问题更加困难。很容易为服务器“源代码”或“部分文件”键值表，以便在特定服务器死机时，可以以线速 (1 Gb/s) 将服务器的数据重建到备用服务器上。通常，您可以使用“心跳”系统检测服务器死亡，如果服务器在 10 秒内没有响应，则会触发该系统。甚至可以针对部分文件编码的键值表进行键值查找，但这样做效率低下，但仍然为您提供了服务器故障事件的备份。一个更大的问题是，几乎不可能使备份保持最新，并且数据可能已经存在 3 分钟。如果您进行大量写入，备份功能会引入一些性能开销，但如果您的系统主要进行读取，则开销将可以忽略不计。

我不是在故障模式下维护数据库一致性和完整性约束的专家，所以我不确定这个要求会带来什么问题。如果您不必担心这一点，它会大大简化系统的设计及其要求。

快速（因此将允许在其之上执行查询）

首先，当您的数据库这么大时，忘记连接或任何比 n*log(n) 扩展速度更快的操作。您可以做两件事来替换通常用连接实现的功能。您可以对数据进行结构化以便不需要进行连接，也可以“预编译”正在执行的查询并进行时空折衷并预先计算连接并将它们存储起来以供提前查找.

对于语义网络数据库，我认为我们将看到人们预先编译查询并进行时间-空间权衡，以便在即使是中等大小的数据集上也能获得不错的性能。我认为这可以由数据库后端自动且透明地完成，而无需应用程序程序员的任何努力。然而，我们才刚刚开始看到企业数据库为关系数据库实施这些技术。据我所知，没有任何开源产品能做到这一点，如果有人试图为水平可扩展数据库中的链接数据这样做，我会感到惊讶。

对于这些类型的系统，如果您有额外的 RAM 或存储空间，出于性能原因，最好使用它来预先计算和存储常见子查询的结果，而不是为键值添加更多冗余店铺。预先计算结果并按您要查询的键排序，以将 n^2 连接转换为 log(n) 查找。任何比 n*log(n) 扩展性更差的查询或子查询都需要执行其结果并将其缓存在键值存储中。

如果您正在执行大量写入，缓存的子查询将比它们处理的更快地失效，并且没有性能优势。处理缓存子查询的缓存失效是另一个棘手的问题。我认为一个解决方案是可能的，但我还没有看到它。

欢迎来到地狱。您不应该期望再过 20 年才能免费获得这样的系统。

到目前为止，似乎没有满足我提到的标准的数据库或键值存储，即使在提供 100 分的赏金之后，问题也没有得到回答！

你在祈求奇迹。等待 20 年，直到我们拥有开源奇迹数据库，否则您应该愿意为根据您的应用程序需求定制的解决方案付费。

【讨论】：

【参考方案2】：

Amazon S3 是一种存储解决方案，而不是数据库。

如果您只需要简单的键/值，您最好将 Amazon SimpleDB 与 S3 结合使用。大文件存储在 S3 上，而用于搜索的元数据存储在 SimpleDB 中。这为您提供了一个可以直接访问 S3 的水平可扩展键/值系统。

【讨论】：

【参考方案3】：

还有另一个解决方案，这似乎正是您正在寻找的：Apache Cassandra 项目：http://incubator.apache.org/cassandra/

目前 twitter 正在从 memcached+mysql 集群切换到 Cassandra

【讨论】：

是的，Cassandra 一直看起来更有吸引力。【参考方案4】：

HBase 和 HDFS 一起满足了这些要求中的大部分。 HBase 可用于存储和检索小对象。 HDFS 可用于存储大型对象。 HBase 压缩小对象并将它们作为较大的对象存储在 HDFS 上。速度是相对的 - HBase 在从磁盘随机读取时不如 mysql 快（例如） - 但从内存中读取的速度非常快（类似于 Cassandra）。它具有出色的写入性能。 HDFS 是底层存储层，对丢失多个节点具有完全的弹性。它还可以跨机架复制，并允许进行机架级维护。它是一个基于 Java 的堆栈，具有 Apache 许可证 - 几乎可以运行大多数操作系统。

此堆栈的主要弱点是没有达到最佳随机磁盘读取性能和缺乏跨数据中心支持（这是一项正在进行的工作）。

【讨论】：

【参考方案5】：

我可以建议您两种可能的解决方案：

1) 购买亚马逊的服务（Amazon S3）。对于 100 TB，每月需要花费 14 512 美元。 2) 更便宜的解决方案：

构建两个自定义 backblaze 存储 pod (link) 并在其上运行 MogileFS。

目前我正在研究如何使用类似的解决方案来存储 PB 级的数据，所以如果你发现了一些有趣的东西，请发表你的笔记。

【讨论】：

谢谢，我正在检查这个。我也在看基于 Erlang 的 Riak。与分布式键值存储相比，使用基于 MogileFS 的系统有什么优势？【参考方案6】：

看看Tokyo Tyrant。它是一个非常轻量级、高性能的复制守护进程，将Tokyo Cabinet 键值存储导出到网络。我听说过它的好消息。

【讨论】：

我使用过 Tokyo Cabinet 和 networklayer Tokyo Tyrant，但它们绝对不可扩展，因为它们需要在顶部有一个名为 Lightcloud 的层来执行分区，这是固定分区。 Lightcloud 本身并不是需要。这只是这样做的一种方式。没有什么可以阻止您在 Tokyo Tyrant 上编写自己的一致哈希实现。 @z8000。是的，你是对的，因为东京内阁不提供动态分区，它需要自定义编写。谢谢【参考方案7】：

从我在您的问题中看到的Project Voldemort 似乎是最接近的问题。看看他们的Design page。

我看到的唯一问题是它如何处理大文件，根据this thread，事情并不全是好的。但是你总是可以很容易地使用文件来解决这个问题。最后 - 这是文件系统的确切目的。看看wikipedia list of file systems - 列表很大。

【讨论】：

根据我在网上找到的信息，除了它的创造者之外，没有人在生产中使用 voldemort【参考方案8】：

您可能想看看MongoDB。

据我所知，您正在寻找数据库/分布式文件系统组合，这可能很难甚至不可能找到。

您可能想看看像MooseFS 或Gluster 这样的分布式文件系统，并将您的数据保存为文件。两个系统都是容错和分布式的（您可以根据需要放入和取出节点），并且对客户端都是透明的（构建在 FUSE 之上）——您使用的是简单的文件系统操作。这包括以下特征：1)、2)、3)、4)、6)、7)、8)。我们将 MooseFS 用于存储大约 1.5 PB 的数字电影存储，并且上传/下载速度与网络设置允许的一样快（因此性能取决于 I/O，而不取决于协议或实现）。您的列表中不会有查询（功能 5）），但您可以将此类文件系统与 MongoDB 之类的东西或什至诸如 Lucene 之类的搜索引擎（它具有聚集索引）结合起来，以查询存储在文件系统中的数据。

【讨论】：

是的，我更关注 MongoDb【参考方案9】：

祖拜尔，

我正在开发一个键值对存储，到目前为止是faster than anything else。

它没有（还）使用复制，缺少您的 2 个首要要求，但这个问题启发了我 - 谢谢！

否：允许我简单地添加和删除节点，并自动重新分配数据否：允许我删除节点，但仍然有 2 个额外的数据节点来提供冗余 ok：允许我存储最大 1GB 大小的文本或图像（是：无限制） ok：可以存储最多 100TB 的小数据（是：无限制） ok：快速（因此将允许在其上执行查询）（是的：比 Tokyo Cabinet 的 TC-FIXED 数组快） ok：让所有这些对客户端透明（是：集成到 Web 服务器） 好的：适用于 Ubuntu/FreeBSD 或 Mac （是：Linux） ok：免费或开源（是：免费软件）

除了优于哈希表和 B 树的单线程性能之外，这个 KV 存储是我所知道的唯一一个“无等待”（不阻塞，也不延迟任何操作）。

【讨论】：

你有一个指向你的数据库的链接，我可以在这里阅读更多信息【参考方案10】：

MarkLogic 正朝着这个方向发展。不过，根本不是免费的……

【讨论】：

【参考方案11】：

除了其他人提到的 - 你可以看看 OrientDB - http://code.google.com/p/orient/ 一个看起来很有前途的文档和 K/V 存储。

【讨论】：

【参考方案12】：

查看BigCouch。它是 CouchDB，但针对集群进行了优化（以及集群适用的所有大数据问题）。 BigCouch 收到了merged into the CouchDB project，正如我们所说，Cloudant 的人，其中许多人是 CouchDB 的核心提交者。

您的要求概要：