小编Kai*_*vin的帖子

我很难在我的SSD上存储数亿个16/32字节的键/值对和一个哈希数组.

京都内阁:当它工作正常时,它以70000记录/秒的速度插入.一旦下降,它就会下降到10-500记录/秒.使用默认设置,在大约一百万条记录之后发生丢弃.查看文档,这是数组中默认的桶数,因此它是有意义的.我将这个数字增加到了2500万,事实上,它可以正常工作,直到大约2500万条记录.问题是,只要我将桶数推到3000万或以上,插入速率就会从一开始就降低到10-500条记录/秒.Kyoto Cabinet不是为了在创建数据库后增加存储桶数量而设计的,因此我无法插入超过2500万条记录.

1/一旦铲斗数超过25M,为什么KC的插入率会变得非常低？

使用Berkeley DB:我得到的最佳速度略低于KC,接近50000记录/秒,但仍然可以.使用默认设置,就像KC一样,在大约一百万条记录之后,速度会突然下降.我知道BDB旨在逐步扩展其桶数.无论如何,它试图增加初始数量,与HashNumElements和FillFactor一起玩,但是这些尝试都使情况变得更糟.所以我仍然无法使用DBD插入超过1-2百万条记录.我尝试激活非同步事务,尝试不同速率的检查点,增加缓存.什么都没有改善下降.

2/在1-2百万次插入后,什么可能导致BDB的插入率下降？

注意:我正在使用java,当速度下降时,CPU使用率降低到0-30%,而在正常速度下工作时,CPU使用率降低到100%.
注意:停止进程并恢复插入不会改变任何内容.所以我认为这与内存限制或垃圾收集无关.

谢谢.

我确信:

• 我正在使用Linux上的Java/Eclipse,并尝试在磁盘上分别存储大量16/32字节的键/值对.密钥是完全随机的,使用SecureRandom生成.
• 速度恒定在~50000插入/秒,直到达到约100万个条目.
• 达到此限制后,java进程每隔1-2秒从0%CPU振荡到100%,从150MB内存振荡到400MB,从10插入/秒振荡到100.
• 我试过Berkeley DB和Kyoto Cabinet以及Btrees和Hashtables.结果相同.

可能有什么贡献:

• 它是在SSD上写的.
• 对于每个插入,平均有1.5次读取 - 不断读取和写入.

我怀疑在达到某个缓存/缓冲区限制之前,50000的速率很快.然后,大缓慢可能是由于SSD没有处理混合在一起的读/写,正如这个问题所建议的:SSD的低延迟键值存储.

问题是:
这种极端减速可能来自哪里？它不是所有SSD的故障.很多人乐于使用SSD进行高速数据库处理,我相信它们会混合读写.

谢谢.

编辑:我已确保删除任何内存限制,并且java进程始终有空间分配更多内存.
编辑:删除读数和仅执行插入不会更改问题.

上次编辑:对于记录,对于哈希表,它似乎与初始数字桶有关.在京都内阁,这个数字不能改变,默认为~100万,所以最好在创建时获得数字(存储的最大记录数的1到4倍).对于BDB,它被设计为逐渐增加桶的数量,但由于它是资源消耗,因此更好地预先确定数量.