为什么即使调整了bnum后东京暴君也会成倍地减速？

Question

有没有人成功使用东京内阁/东京暴君的大型数据集？我正在尝试上传维基百科数据源的子图。在达到约3000万条记录后，我的指数变慢了。 HDB和BDB数据库都会出现这种情况。我将bnum调整为HDB案例的预期记录数的2-4倍，只是稍微加快了。我还将xmsiz设置为1GB左右，但最终我还是碰壁了。

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

Answer 1

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

但是现在，你会注意到它仍然会放慢速度，尽管有点远。我们发现诀窍是关闭文件系统中的日志记录 - 由于某种原因，当你的哈希文件大小超过2-3GB时，日志记录（在ext3上）会出现峰值。 （我们意识到这一点的方式是I / O中的峰值不对应于磁盘上文件的更改，以及kjournald的守护进程CPU突发）

对于Linux，只需将ext3分区卸载并重新安装为ext2即可。构建你的数据库，并重新安装为ext3。当禁用日志记录时，我们可以构建180M密钥大小的数据库而没有问题。

Answer 2

东京鳞片很棒！但你必须适当地设置你的bnum和xmsiz。 bnum应该是您计划存储的记录的.025到4倍。 xmsiz应该与BNUM的大小相匹配。如果您计划存储超过2GB，还要设置opts = l。

请参阅Greg Fodor上面关于获取xmsiz大小值的帖子。请注意，设置xmsiz时，该值以字节为单位。

最后，如果您使用基于磁盘的哈希，那么关闭托管数据所在的文件系统上的日记非常非常非常重要。对于Linux，Mac OSX和Windows可能都是如此，尽管我还没有测试过它。

如果启用了日记功能，当您接近3000多万行时，您会看到性能严重下降。关闭日记功能并适当设置其他选项东京是一个很好的工具。

Answer 3

我开始研究一种解决方案，为称为Shardy的东京机柜添加分片。

http://github.com/cardmagic/shardy/tree/master

Answer 4

东京内阁的超值商店非常好。我认为人们称它为慢，因为他们使用东京内阁的桌子式商店。

如果要存储文档数据，请使用mongodb或其他一些nosql引擎。