admin avatar

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

🕑 by admin

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

业务需求

  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

💘 相关文章

写一条评论

Based on Golang + fastHTTP + sdb | go1.17.3 Processed in 0ms