为什么选 kt (kyoto tycoon) + leveldb - 海量数据查询的方案选型
关于上十亿的数据查询的数据方案
业务需求
- key-value数据结构，随机读，低延时。
- 数据量大（10亿+)，机器紧张。
- 一次性写（一天一次），多次读。
- 支持主要的协议，高可用，易扩展。
入选
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
0
See Also
- Kyoto Tycoon + LevelDB 组合
- HyperLevelDB 提高了LevelDB 性能的一个分支
- 用Tornado 做 leveldb server
- leveldb + python 的数据库方案
- leveldb+bottle+gevent 是个不错的组合
Nearby
- 上一篇 › Memcached 数据持久化 MemcachedDB
- 下一篇 › youBBS去头像版1.0