tokyo-cabinet - 为什么东京暴君即使调整了 bnum 也会指数级减速？

Question

有没有人在大型数据集上成功使用 Tokyo Cabinet/Tokyo Tyrant？我正在尝试上传维基百科数据源的子图。在达到大约 3000 万条记录后，我的速度呈指数级下降。 HDB 和 BDB 数据库都会出现这种情况。我将 bnum 调整为 HDB 案例预期记录数的 2-4 倍，但速度略有提高。我还将 xmsiz 设置为 1GB 左右，但最终我还是碰壁了。

Tokyo Tyrant 似乎基本上是一个内存数据库，当您超过 xmsiz 或您的 RAM 后，您将获得一个几乎无法使用的数据库。有没有其他人遇到过这个问题？你能解决吗？

Answer 1

我想我可能已经破解了这个，但我在其他任何地方都没有看到这个解决方案。在 Linux 上，东京开始变慢通常有两个原因。让我们来看看常见的罪魁祸首。首先，如果您将 bnum 设置得太低，您希望它至少等于散列中项目数的一半。 (最好更多。)其次，您想尝试将 xmsiz 设置为接近桶数组的大小。要获得桶数组的大小，只需创建一个具有正确 bnum 的空数据库，Tokyo 就会将文件初始化为适当的大小。 (例如，对于空数据库，bnum=200000000 大约为 1.5GB。)

但是现在，您会注意到它仍然在减速，尽管速度要慢一些。我们发现诀窍是关闭文件系统中的日志记录——出于某种原因，当哈希文件大小超过 2-3GB 时，日志记录(在 ext3 上)会出现峰值。 (我们意识到这是 I/O 的峰值与磁盘上文件的变化不对应，以及 kjournald 的守护进程 CPU 爆发)

对于 Linux，只需将您的 ext3 分区卸载并重新挂载为 ext2。构建您的数据库，并重新挂载为 ext3。禁用日志记录后，我们可以毫无问题地构建 180M key 大小的数据库。