我需要将超过 10 亿个密钥加载到 Berkley DB 中,因此我想提前对其进行调整以获得更好的性能。使用标准配置,我现在需要大约 15 分钟来加载 1'000'000 个键,这太慢了。是否有适当的方法来调整例如 Berkley DB 的 B+Tree(节点大小等)?
(作为对比,在调优 tokyo cabinet 后,25 分钟内加载了 10 亿个键)。
PS我正在寻找作为代码而不是为正在运行的系统设置的参数的调整技巧(如jvm大小等......)
我需要将超过 10 亿个密钥加载到 Berkley DB 中,因此我想提前对其进行调整以获得更好的性能。使用标准配置,我现在需要大约 15 分钟来加载 1'000'000 个键,这太慢了。是否有适当的方法来调整例如 Berkley DB 的 B+Tree(节点大小等)?
(作为对比,在调优 tokyo cabinet 后,25 分钟内加载了 10 亿个键)。
PS我正在寻找作为代码而不是为正在运行的系统设置的参数的调整技巧(如jvm大小等......)
我很好奇,当 TokyoCabinet 在 25 分钟内加载 1B 键时,存储的键/值的大小是多少?您使用的 I/O 系统和存储系统是什么?您是否使用术语“负载”来表示对永久稳定存储的 1B 事务提交?那将是每秒约 666,666 次插入,考虑到我所知道的任何 I/O 系统,这在物理上是不可能的。将该数字乘以键和值的大小,现在您已经无可救药地超出了物理限制。
请查看Gustavo Duarte的博客,阅读一些有关 I/O 系统以及硬件如何工作的信息,然后查看您的声明。我非常有兴趣找出 TokyoCabinet 到底在做什么和没有做什么。如果我不得不猜测,我会说它正在提交操作系统中的文件系统缓存,而不是将这些缓冲区刷新(fdsync()-ing)到磁盘。
全面披露:我是 Oracle Berkeley DB(TokyoCabinet 的直接竞争对手)的 Oracle 产品经理,我已经使用这些数据库和最好的硬件大约十年了,所以我既存偏见又持怀疑态度.
Berkeley DB 具有您可以在事务句柄上设置的标志,这些标志模仿了这种方法和其他类似的权衡耐久性(ACID 中的“D”)以换取速度的方法。
至于如何使 Berkeley DB Java 版 (BDB-JE) 更快,您可以尝试以下方法:
清楚关于数据库性能的声明非常重要。它们看起来很简单,但要正确处理它们非常棘手,这样它们就不会损坏数据或丢失已提交的事务。
我希望这对你有所帮助。
如果将 BDB-JE 上的批量插入分组到单个事务中,则速度会快一个数量级。原因是每次提交都会导致(默认情况下)同步写入磁盘,而事务在提交时同步。在我的应用程序中,将 100'000 个小键作为单个提交写入需要一分钟以上,而在事务中只需要几秒钟。