为什么选 kt (kyoto tycoon) + leveldb - 海量数据查询的方案选型

关于上十亿的数据查询的数据方案

业务需求

1. key-value数据结构，随机读，低延时。
2. 数据量大（10亿+)，机器紧张。
3. 一次性写（一天一次），多次读。
4. 支持主要的协议，高可用，易扩展。

入选

redis

• 优点：纯内存，读取性能很好，但是占内存。rehash机制可以保证更新数据数据时，不影响读性能。
• 缺点：需要几台机器才能放下。 如果要提供热备，机器数x2。 同时分布式管理不方便。

测试结果：读写性能应该最好，但是没有机器资源，放弃。

leveldb

• 优点：leveldb为随机写做了很多优化，比如log和memtable。
• 缺点：随机读性能一般，相比下面的kyoto cabinet 和lmdb。

测试后的结论：leveldb比其他数据库稳定，而且数据量增大后，读写性能下降平缓。
10亿数据平均下来12ms/req

kyoto cabinet（HashDB ，TreeDB）

• 优点：mmap可以减少read，write 等从内核拷贝数据。 同时hashDB直接hash，应该会比leveldb快
• 缺点：随机写和批量写性能低

测试后的结论：HashDB和TreeDB的入库太慢，完全无法忍受。尤其到后面几亿的时候，没有反应了，一个晚上没有入库成功,放弃。
但发现kyoto tycoon性能不错，支持各种协议。

lmdb

• 优点：看kc和leveldb对比报告时，发现该作者号称性能搞过leveldb很多倍。
• 缺点：除了openldap在用，好像没有其他使用者，而且是12年整出来的。

测试后的结论：小数据时，由于mmap的作用性能很好，过5亿后急剧下降。切换确实是个大问题。
10亿数据平均下来14ms/req，和leveldb相差不大。

最后选择了kyoto tycoon+leveldb。
具体测试数据因机器不同，写了也没有意义，不贴了，大概4G内存情况下，性能在5ms/req左右。

http://sunjiangang.blog.chinaunix.net/uid-14874549-id-3568949.html