3

我正在为我的一个项目开发一个全文索引系统。作为索引页面过程的一部分，它将数据分成非常非常多的非常小的片段。

我已经将片段的大小降至恒定的 20-30 字节，并且可能更小，它基本上是 2 个 8 字节整数和一个浮点数，构成了实际数据。

由于我正在寻找的规模和由此产生的件数，我正在寻找 mysql 的替代品，它在价值设置远低于我的目标时显示出重大问题。

我目前的想法是键值存储将是最好的选择，我已经相应地调整了我的代码。

我尝试了一个数字，但由于某种原因，它们的扩展性似乎都比 mysql 还要小。

我希望存储数亿或数十亿或更多的键值对，因此我需要一些不会随着大小而导致性能大幅下降的东西。

我已经尝试过 memcachedb、membase 和 mongo，虽然它们都很容易设置，但它们都没有适合我。

由于所需的密钥数量和可用内存有限，membase 的问题最多。写入速度在这里非常重要，因为这是一个非常接近均衡的工作量，我写了一次，然后读回几次并存储它以供最终更新。

我不需要太多的删除性能，我更喜欢可以很好地集群的东西，因为我希望最终能够跨机器扩展，但它现在需要在单台机器上工作。

我也希望使这个项目易于部署，因此简单的设置会更好。该项目是用 php 编写的，因此需要从 php 轻松访问。

我不需要行或其他更高级别的抽象，在这种情况下它们大多没用，我已经从我的其他一些测试中制作了代码以获取键值存储，这似乎很可能是最快的，因为我只有 2 个东西可以从第三个键控的行中检索到，所以使用键值存储几乎不需要做额外的工作。有谁知道任何可以像这样扩展的易于使用的项目？

我正在使用这个存储来存储三个数字的单个集合，（大小取决于它们在 mysql 中的存储方式，在其他存储位置可能不是真的） 2 个八字节整数，一个用于文档的 ID，一个用于对于单词的 ID 和该单词在文档中所占比例的浮点表示（作品出现的次数除以文档中的单词数）。此数据的索引是单词 id 和文档 id 所属的范围，每次我需要检索此数据时，它将是给定单词 id 的所有结果。我目前将单词 id、范围和该单词/范围组合的计数器分别转换为数字的二进制表示，并将它们连接起来形成密钥以及 2 位数字，以说明我存储的该密钥的值，

性能测量有点主观，查看将数据放入存储或从存储中提取数据的过程的输出，查看它处理文档的速度以及快速刷新我的统计计数器，以跟踪更准确的系统运行速度的统计信息并查看我使用每种存储方法时的差异。

4

2 回答 2

5

您需要提供更多关于您真正想要做什么的数据......

根据您定义快速大规模的方式，您有多种选择：

等等……名单变得非常大……

编辑1：

根据这篇文章的评论，我会说你看看 cassandra 或 voldemort。Cassandra 不是一个简单的 KV 存储per se，因为您可以存储更复杂的对象，而不仅仅是K -> V

如果您想使用 PHP 检查 cassandra，请查看phpcassa。但是如果你设置一个副本， redis也是一个不错的选择。

于 2011-12-26T17:54:33.563 回答
2

这里添加一些上面没有提到的产品和想法：

  • OrientDB - 这是一个图形/文档数据库，但您可以使用它来存储非常小的“文档” - 它非常快速、高度可扩展，并且针对处理大量记录进行了优化。

  • Berkeley DB - Berkeley DB 是一个键值存储，用于许多图形和文档数据库的核心 - 据说有一个与 PHP 兼容的 SQLite 兼容 API。

  • shmop - 如果您愿意做一些肮脏的工作，共享内存操作可能是一种可能的方法。如果您的记录很小并且具有固定大小，那么这可能对您有用 - 使用固定的记录大小并用零填充。

  • handlersocket - 这个已经开发了很长时间了，我不知道它有多可靠。它基本上让您可以在“较低级别”使用 MySQL，几乎就像键/值存储一样。因为你绕过了查询解析器等。它通常比 MySQL 快得多。

如果你有一个固定的记录大小、很少的写入和大量的读取，你甚至可以考虑读/写到/从一个平面文件。可能远不及读取/写入共享内存的速度，但可能值得考虑。我建议您专门针对您的项目要求权衡所有利弊，不仅针对产品，而且针对您能想到的任何方法。您的要求并不完全是“主流”，解决方案可能不如选择正确的产品那么明显。

于 2012-02-10T13:24:42.067 回答