有没有人成功使用过大型数据集的 Tokyo Cabinet / Tokyo Tyrant？我正在尝试上传维基百科数据源的子图。在达到大约 3000 万条记录后，我的速度呈指数级下降。HDB 和 BDB 数据库都会出现这种情况。我将 bnum 调整为 HDB 案例的预期记录数的 2-4 倍，只是略微加快了速度。我还将 xmsiz 设置为 1GB 左右，但最终还是碰壁了。
东京暴君似乎基本上是一个内存数据库，在超过 xmsiz 或 RAM 后，你会得到一个几乎不可用的数据库。以前有没有其他人遇到过这个问题？你能解决吗？
我想我可能已经破解了这个，而且我在其他任何地方都没有看到这个解决方案。在 Linux 上，东京开始放缓通常有两个原因。让我们看看通常的罪魁祸首。首先，如果您将 bnum 设置得太低，您希望它至少等于散列中项目数的一半。（最好更多。）其次，您想尝试将 xmsiz 设置为接近存储桶数组的大小。要获取存储桶数组的大小，只需使用正确的 bnum 创建一个空数据库，Tokyo 会将文件初始化为适当的大小。（例如，对于一个空数据库，bnum=200000000 大约为 1.5GB。）
但是现在，您会注意到它仍然变慢了，尽管慢了一点。我们发现诀窍是关闭文件系统中的日志——由于某种原因，当您的哈希文件大小超过 2-3GB 时，日志（在 ext3 上）会出现峰值。（我们意识到这是 I/O 峰值与磁盘上文件的更改不对应，以及 kjournald 的守护进程 CPU 爆发）
对于 Linux，只需将 ext3 分区卸载并重新挂载为 ext2。建立你的数据库，并重新安装为 ext3。当日志功能被禁用时，我们可以毫无问题地构建 180M 密钥大小的数据库。
东京规模惊人！！但是你必须适当地设置你的 bnum 和 xmsiz。bnum 应该比您计划存储的记录大 0.025 到 4 倍。xmsiz 应该与 BNUM 的大小相匹配。如果您计划存储超过 2GB，也请设置 opts=l。
有关获取 xmsiz 大小的值，请参阅上面 Greg Fodor 的帖子。请注意，在设置 xmsiz 时，该值以字节为单位。
最后，如果您使用的是基于磁盘的哈希，那么关闭 tokyo 数据所在文件系统上的日志记录非常非常重要。这适用于 Linux、Mac OSX 和可能的 Windows，尽管我还没有在那里测试过。
如果打开日志，当您接近 30+ 百万行时，您将看到性能严重下降。关闭日记功能并适当设置其他选项，东京是一个很好的工具。
我开始研究一种解决方案，将分片添加到名为 Shardy 的 tokyo cabinet。
Tokyo Cabinet 的 key-value store 真的很不错。我认为人们称之为慢，因为他们使用东京内阁的桌子式商店。
如果要存储文档数据，请使用 mongodb 或其他一些 nosql 引擎。