为什么在调整bnum之后，东京暴君的速度仍然呈指数级下降？

Question

有没有人成功地使用过Tokyo Cabinet / Tokyo Tyrant处理大型数据集？我试图上传维基百科数据源的子图。在达到约3000万条记录后，速度呈指数级减缓。这种情况发生在HDB和BDB数据库中。我将HDB的bnum调整为预期记录数量的2-4倍，但只有轻微加速。我还将xmsiz设置为1GB左右，但最终仍然遇到了瓶颈。

看起来Tokyo Tyrant基本上是一个内存数据库，当您超出xmsiz或RAM时，您会得到一个几乎无法使用的数据库。有其他人遇到过这个问题吗？您能解决它吗？

- HenryL

---

有人之前遇到过这个问题吗？显然这些人遇到过，可以看看这里：http://bjclark.me/2009/08/04/nosql-if-only-it-was-that-easy/ - Jeff Atwood

该链接已经失效，现在在http://mod.erni.st/2009/08/nosql-if-only-it-was-that-easy/。 - BJ Clark

Answer 1

我认为我可能破解了这个问题，并且我没有在其他地方看到这个解决方案。在Linux上，东京变慢通常有两个原因。让我们来看看通常的罪魁祸首。首先，如果您将bnum设置得太低，则希望它至少等于哈希中项数的一半。（最好更多）。其次，您要尝试将xmsiz设置为接近桶数组的大小。要获取桶数组的大小，只需使用正确的bnum创建空db，Tokyo将初始化文件以适当的大小。（例如，bnum = 200000000差不多是一个空db的1.5GB）。

但现在，你会注意到它仍然变慢，尽管稍微远一些。我们发现诀窍是关闭文件系统中的日志记录 - 出于某种原因，在哈希文件大小超过2-3GB时，日志记录（在ext3上）会急剧增加。（我们意识到这一点的方式是I / O的峰值与磁盘上的文件更改不对应，同时伴随着kjournald的守护程序CPU爆发）

对于Linux，只需卸载并重新挂载ext3分区作为ext2。构建您的数据库，然后重新挂载为ext3。禁用日志记录后，我们可以轻松构建180M键大小的数据库。

- Greg Fodor

Answer 2

东京缩放功能非常出色！但您必须适当设置Bnum和Xmsiz。bnum应为要存储的记录数的0.025到4倍，xmsiz应与BNUM的大小匹配。如果您计划存储超过2GB，则还应将opts = l设置为“是”。

请参见Greg Fodor上面的帖子，了解如何获取xmsiz的值。请注意，在设置xmsiz时，该值以字节为单位。

最后，如果您使用基于磁盘的哈希，则非常重要在东京数据所在的文件系统上关闭日志记录。这对于Linux、Mac OSX和可能的Windows都是正确的，尽管我尚未在那里进行测试。

如果打开日志记录，您将看到性能急剧下降，当接近3000万行时。关闭日志记录并适当设置其他选项后，东京是一个很好的工具。

- Anwar Abdus-Samad

Answer 3

我开始着手解决给Tokyo Cabinet添加分片的问题，这个方案被称为Shardy。 http://github.com/cardmagic/shardy/tree/master

- Lucas Carlson

Answer 4

Tokyo Cabinet的键值存储非常好。我认为人们之所以称其为慢，是因为他们使用了Tokyo Cabinet的类似表格的存储方式。

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

- muyufan

---

你有没有仔细阅读问题？他正在使用哈希数据库和B+树数据库。 - ibz