有没有人成功使用过大型数据集的 Tokyo Cabinet / Tokyo Tyrant？我正在尝试上传*数据源的子图。在达到大约 3000 万条记录后，我的速度呈指数级下降。 HDB 和 BDB 数据库都会出现这种情况。我将 bnum 调整为 HDB 案例的预期记录数的 2-4 倍，只是略微加快了速度。我还将 xmsiz 设置为 1GB 左右，但最终还是碰壁了。
似乎东京暴君基本上是一个内存数据库，当你超过 xmsiz 或你的 RAM 后，你会得到一个几乎不可用的数据库。以前有没有其他人遇到过这个问题？你能解决吗？
【问题讨论】：
标签： tokyo-cabinet
我想我可能已经破解了这个，而且我还没有在其他任何地方看到过这个解决方案。在 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+ 百万行时，您会发现性能严重下降。关闭日记功能并适当设置其他选项，Tokyo 是一个很好的工具。
【讨论】：
我开始研究一种解决方案，将分片添加到名为 Shardy 的 tokyo cabinet。
【讨论】：
东京内阁的key-value store真的很不错。我认为人们称它为慢是因为他们使用的是东京内阁的桌子式商店。
如果您想存储文档数据，请使用 mongodb 或其他一些 nosql 引擎。
【讨论】：