为什么东京暴君在调整了bnum后也会成倍地减速？
有没有人成功地将东京橱柜/东京暴君用于大型数据集？我正在尝试上传维基百科数据源的子图。在点击了大约3000万条记录后，我得到了指数级的减速。HDB和BDB数据库都会发生这种情况。我将bnum调整为HDB案例的预期记录数的2-4倍，但速度仅略有提高。我还将xmsiz设置为1 1GB左右，但最终还是遇到了问题。
似乎东京Tyrant基本上是一个内存中的数据库，当您超过xmsiz或RAM时，您得到的数据库几乎无法使用。其他人以前遇到过这个问题吗？你能解决这个问题吗？
回答 4
Stack Overflow用户
发布于 2010-03-07 08:05:42
我想我可能已经破解了这个问题，而且我在其他任何地方都没有看到过这个解决方案。在Linux上，东京开始变慢通常有两个原因。让我们来看看常见的罪魁祸首。首先，如果您将bnum设置得太低，您希望它至少等于散列中条目数量的一半。(最好更多。)其次，您希望将xmsiz设置为接近存储桶数组的大小。要获得存储桶数组的大小，只需使用正确的bnum创建一个空的db，然后Tokyo会将文件初始化为适当的大小。(例如，对于空数据库，bnum=200000000大约为1.5 db。)
但是现在，你会注意到它仍然变慢了，尽管走得更远了一点。我们发现诀窍是关闭文件系统中的日志记录--由于某些原因，当您的散列文件大小超过2-3 3GB时，日志记录(在ext3上)会达到峰值。(我们意识到这是I/O中的峰值，与磁盘上文件的更改不对应，以及kjournald的守护进程CPU突发)
对于Linux，只需卸载并重新挂载作为ext2的ext3分区即可。构建你的数据库，并以ext3的身份重新挂载。当日志被禁用时，我们可以毫无问题地构建180M密钥大小的数据库。
Stack Overflow用户
发布于 2010-05-21 01:54:21
东京的规模太棒了！但是您必须适当地设置bnum和xmsiz。bnum应该比你计划存储的记录大.025到4倍。xmsiz应与BNUM的大小匹配。如果你打算存储超过2 2GB的内存，也要设置opts=l。
请参阅Greg Fodor上面关于获取xmsiz大小的值的帖子。请注意，在设置xmsiz时，该值以字节为单位。
最后，如果您使用的是基于磁盘的散列，那么在东京数据所在的文件系统上关闭日志记录是非常非常重要的。这适用于Linux，Mac OSX，可能还有Windows，尽管我还没有在那里测试过它。
如果启用了日志记录，那么在接近30+百万行时，您将看到性能严重下降。关闭日志记录并适当设置其他选项后，东京是一个很好的工具。
Stack Overflow用户
发布于 2009-08-10 08:41:37
我正在着手研究一种名为Shardy的解决方案，将分片添加到东京机柜中。
http://github.com/cardmagic/shardy/tree/master
https://stackoverflow.com/questions/1051847
复制相似问题
腾讯云开发者
