我在一篇名为“Hands-on Cassandra”的文章中读到 Tokyo Cabinet 不适合大数据。为什么？ TC 开始工作之前需要存储多少字节？是否可以确定一个近似值？
最佳答案
基于 this article ，确认性能下降超过 500GB。
基于 NoSQL 数据库的广泛比较，TC 中的问题始于 >20mm 的行。
大小依赖的可能原因之一是似乎 TC 是使用哈希实现的，并且在某些时候您会遇到哈希键冲突，这当然会破坏性能。默认情况下，键空间不是那么大(您需要调整“bnum”参数 - 存储桶数组的元素数 - 以提高性能)
基于各种比较，MongoDB 似乎是大型数据集的推荐方法。
关于database - Tokyo Cabinet 运作的最大尺寸是多少？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/4536170/