我正在尝试创建一个键/值数据库，其中包含 300,000,000 个键/值对，每个键/值对 8 个字节（用于键和值）。要求是有一个非常快的键/值机制，每秒可以查询大约 500,000 个条目。
我尝试了 BDB、Tokyo DB、Kyoto DB 和 levelDB，但在这种规模的数据库中，它们的表现都非常糟糕。 （他们的表现甚至与 1,000,000 个条目的基准比率相差无几）。
由于硬件限制（32 位软件），我无法将数据库存储在内存中，因此无法使用 memcached。
我也不能使用外部服务器软件（只有一个数据库模块），根本不需要多用户支持。当然，服务器软件无论如何都无法每秒处理来自单个端点的 500,000 次查询，因此 Redis、Tokyo tyrant 等就被排除在外了。
【问题讨论】：
标签： database hash berkeley-db key-value tokyo-cabinet
大卫·塞格洛，在这里。 Berkeley DB 产品经理。
BDB 性能最常见的问题是人们没有配置缓存大小，而是将其保留为默认值，这非常小。第二个最常见的问题是人们编写的应用程序行为模拟器会进行随机查找（即使他们的应用程序并不是完全随机的），这会迫使他们从缓存中读取数据。然后，随机 I/O 将他们带入一条关于性能的结论路径，这些结论不是基于模拟应用程序而不是实际应用程序行为。
根据您的描述，我不确定您是否遇到了这些常见问题，或者可能完全遇到了其他问题。无论如何，我们的经验是 Berkeley DB 的性能和扩展性都非常好。我们很乐意帮助您识别任何瓶颈并提高您的 BDB 应用程序吞吐量。在这方面获得帮助的最佳地点是 BDB 论坛：http://forums.oracle.com/forums/forum.jspa?forumID=271。当您在论坛上发帖时，显示应用程序代码的关键查询段和显示数据库环境性能的 db_stat 输出会很有用。
您可能希望使用 BDB HA/Replication 来对多台服务器上的查询进行负载平衡。 500K 查询/秒可能需要更大的多核服务器或一系列更小的复制服务器。我们经常在商用硬件上看到每秒 100-200K 查询的 BDB 应用程序，但是在 32 位应用程序中对 300M 记录每秒 500K 查询可能需要一些仔细的调整。我建议专注于优化在单个节点上运行的 BDB 应用程序的查询性能，然后使用 HA 将负载分配到多个系统，以扩展查询/秒吞吐量。
我希望这会有所帮助。
祝您申请顺利。
问候，
戴夫
【讨论】：
我找到了一个很好的基准比较网页，它基本上比较了 5 个知名数据库：
您应该在做出选择之前检查一下：http://symas.com/mdb/microbench/。
P.S - 我知道您已经对其进行了测试，但您还应该考虑到您的每个测试的配置都没有像基准测试显示的那样进行优化。
【讨论】：
试试ZooLib。
它提供了一个带有 C++ API 的数据库，该 API 最初是为一个名为 Knowledge Forum 的教育机构的高性能多媒体数据库而编写的。它可以同时处理 3,000 个 Mac 和 Windows 客户端（也是用 ZooLib 编写的——它是一个跨平台的应用程序框架），所有这些客户端都流式传输音频、视频并处理由教师和学生创建的图形丰富的文档。
它有两个用于将字节实际写入磁盘的低级 API。一个非常快，但不是容错的。另一个是容错的，但没有那么快。
我是 ZooLib 的开发人员之一，但我对 ZooLib 的数据库组件没有太多经验。也没有文档 - 您必须阅读源代码才能了解它是如何工作的。那是我自己该死的错，因为我在十多年前承担了编写 ZooLib 手册的工作，但几乎没有开始。
ZooLib 的主要开发人员Andy Green 是一个很棒的人，总是乐于回答问题。我建议您在 SourceForge 订阅 ZooLib 的开发人员列表，然后在列表中询问如何使用该数据库。安迪很可能会亲自回答您，但也许我们的其他开发人员之一会。
ZooLib 在 MIT 许可下是开源的，并且是真正高质量、成熟的代码。它从 1990 年左右开始不断发展，并于 2000 年被开源。
不要担心自 2003 年以来我们还没有发布 tarball。我们可能应该这样做，因为这会导致许多潜在用户认为它已被放弃，但它被非常积极地使用和维护。只需从 Subversion 获取源代码即可。
Andy 是一名自雇顾问。如果您没有时间但有预算，他会很好地编写自定义、可维护的顶级 C++ 代码以满足您的需求。
如果它是 ZooLib 的任何部分而不是数据库，我也会这样做，正如我所说的我不熟悉。我已经使用 ZooLib 的 UI 框架完成了很多自己的咨询工作。
【讨论】：
300 M * 8 字节 = 2.4GB。这可能适合内存（如果操作系统不将地址空间限制为 31 位） 由于您还需要处理溢出，（通过重新散列方案或通过链接）内存变得更加紧张，对于线性探测，您可能需要 > 400M 个插槽，链接会将项目的 sizeof 增加到 12 个字节（位摆弄可能会让您受益）几位）。这会将总占用空间增加到大约 3.6 GB。
在任何情况下，您都需要一个特制的内核，将它自己的“保留”地址空间限制在几百 MB。不是不可能，而是一项重大手术。在所有情况下，转义到基于磁盘的东西都太慢了。 （PAE可以救你，但很棘手）
恕我直言，您最好的选择是迁移到 64 位平台。
【讨论】：
每秒 500,000 个条目而不将工作集保存在内存中？哇。
在一般情况下，使用 HDD 甚至是困难的 SSD 是不可能的。
您是否有任何位置属性可能有助于使任务更容易一些？您有哪些疑问？
【讨论】：
我们使用Redis。用 C 语言编写，仅比设计的 memcached 稍微复杂一些。从来没有尝试过使用那么多行，但对我们来说延迟非常重要，它可以很好地处理这些延迟并让我们将数据存储在磁盘中
这里是bench mark blog entry，比较redis和memcached。
【讨论】：
Berkely DB 可以为您做到这一点。 大约 8 年前，我实现了每秒 50000 次插入和一个包含 700 亿条记录的最终数据库。
【讨论】：