大量条目的最佳C语言键/值数据库

Ron*_*ter 13 database hash berkeley-db key-value tokyo-cabinet

我正在尝试创建一个键/值数据库,其中包含300,000,000个每个8字节的键/值对(包括键和值).要求是拥有一个非常快速的键/值机制,每秒可以查询大约500,000个条目.

我尝试过BDB,Tokyo DB,Kyoto DB和levelDB,当涉及到那么大的数据库时,它们都表现得非常糟糕.(他们的表现甚至没有接近他们在1,000,000个参赛作品的基准价格).

由于硬件限制(32位软件),我无法将数据库存储在内存中,因此memcached是不可能的.

我也不能使用外部服务器软件(只有数据库模块),根本不需要多用户支持.当然,无论如何,服务器软件无法从单个端点每秒保存500,000个查询,因此不包括Redis,Tokyo tyrant等.

小智 16

David Segleau,在这里.Berkeley DB的产品经理.

BDB性能最常见的问题是人们没有配置缓存大小,而是将其保留为默认值,这非常小.第二个最常见的问题是人们编写应用程序行为模拟器,这些模拟器进行随机查找(即使它们的应用程序并非真正完全随机),这迫使它们从缓存中读取数据.然后,随机I/O将它们放在一条关于性能的结论路径上,这些结论不是基于模拟应用程序而是基于实际应用程序行为.

根据您的描述,我不确定您是否遇到了这些常见问题,或者可能完全陷入其他问题.无论如何,我们的经验是Berkeley DB往往表现得非常好.我们很乐意帮助您识别任何瓶颈并提高您的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在多个系统之间分配该负载,以便扩展查询/秒吞吐量.

我希望有所帮助.

祝你的申请顺利.

问候,

戴夫