我正在尝试创建一个包含300,000,000个键值对，每个键和值都有8个字节的键值数据库。要求具有非常快的键值机制，每秒可以查询大约500,000个条目。
我尝试了BDB、Tokyo DB、Kyoto DB和LevelDB，但它们在处理如此大的数据库时性能都非常糟糕（它们的性能甚至远远达不到100万个条目的基准速度）。
由于硬件限制（32位软件），我不能将数据库存储在内存中，因此无法使用Memcached。
我也不能使用外部服务器软件（仅允许使用数据库模块），而且根本不需要多用户支持。当然，服务器软件也无法从单个端点处理每秒500,000次查询，所以Redis、Tokyo Tyrant等也无法使用。
我是David Segleau，负责伯克利数据库的产品管理。
伯克利数据库性能最常见的问题是人们没有配置缓存大小，而是保留默认值，这个默认值相当小。其次，人们编写应用程序行为仿真器进行随机查找（尽管他们的应用程序实际上并非完全随机），这迫使他们从缓存读取数据。然后随机I/O会导致他们得出关于性能的结论，并不基于模拟应用程序而是实际应用程序的行为。
根据您的描述，我不确定您是否遇到了这些常见问题，或者可能遇到了完全不同的问题。在任何情况下，我们的经验是，伯克利数据库往往表现出色且可扩展性强。我们很乐意帮助您识别任何瓶颈，并提高您的BDB应用程序吞吐量。在这方面获得帮助的最佳途径是通过BDB论坛：http://forums.oracle.com/forums/forum.jspa?forumID=271。当您在论坛上发布时，最好展示应用程序代码中的关键查询段以及显示数据库环境性能的db_stat输出。
很可能您需要使用BDB HA/Replication来负载均衡多个服务器上的查询。每秒500K个查询可能需要一个更大的多核服务器或一系列更小的复制服务器。我们经常看到在普通硬件上运行的BDB应用程序具有100-200K个查询/秒，但是在32位应用程序中每秒处理300M条记录的500K个查询/秒很可能需要进行精细调整。我建议专注于优化在单个节点上运行的BDB应用程序的查询性能，然后使用HA将该负载分布到多个系统中以扩展您的查询/秒吞吐量。
希望这有所帮助。
祝您的应用顺利。
敬礼，
Dave
试试ZooLib。
它提供了一个带有C++ API的数据库，最初是为教育机构的高性能多媒体数据库Knowledge Forum编写的。它可以处理3,000个同时运行的Mac和Windows客户端（也是用ZooLib编写的 - 它是一个跨平台应用程序框架），所有这些客户端都在流式传输音频、视频并使用由教师和学生创建的图形丰富的文档。
它有两个低级API，用于将字节实际写入磁盘。其中一个非常快，但不容错。另一个是容错的，但不如快速。
我是ZooLib的开发人员之一，但我对ZooLib的数据库组件没有太多经验。也没有文档 - 你必须阅读源代码才能弄清楚它的工作原理。这是我的错，因为十年前我接手编写ZooLib手册的工作，但几乎没有开始。
ZooLib的主要开发者Andy Green是个很棒的人，总是乐于回答问题。我建议你订阅ZooLib在SourceForge上的开发者列表，然后在列表上询问如何使用数据库。很可能Andy会亲自回答你，但也有可能是我们其他的开发者。300 M * 8 字节 = 2.4GB。如果操作系统没有将地址空间限制在31位，则可能适合内存。 由于您还需要处理溢出（通过重新散列方案或链接），因此内存变得更加紧张，对于线性探测，您可能需要> 400M个插槽，链接将使项的大小增加到12字节（位操作可能会为您节省一些位）。这将将总占用空间增加到约3.6 GB。
无论如何，您都需要一个特别设计的内核，将其自己的“保留”地址空间限制在几百MB。这并非不可能，但是是一项重大操作。在所有情况下，转移到基于磁盘的东西将太慢了。（PAE可以为您节省，但它很棘手）
我认为您最好的选择是迁移到64位平台。
每秒处理500,000个条目而不将工作集保留在内存中？哇。
一般情况下，使用硬盘驱动器甚至困难的固态硬盘也无法实现这一点。
您是否有任何本地化属性可以帮助简化任务？您有什么样的查询需求？
Berkely DB可以为您完成这项工作。 我在8年前实现了每秒50000个插入操作，并获得了最终的700亿条记录的数据库。
