LevelDB性能分析和表现

Leveldb是一个google实现的非常高效的kv数据库,目前的版本1.2能够支持billion级别的数据量了。 在这个数量级别下还有着非常高的性能,主要归功于它的良好的设计。特别是LSM算法。

那么数据库最怕的的随机IO他是如何解决的呢?

先说随机写,它的写都是先记录到日志文件去的,在日志文件满之前只是简单的更新memtable,那么就把随机写转化成了顺序写。在日志满了后,把日志里面的数据排序写成sst表同时和之前的sst进行合并,这个动作也是顺序读和写。大家都知道传统磁盘raid的顺序读写吞吐量是很大的,100M左右是没有问题。在写日志文件的时候,用到是buffer IO,也就是说如果操作系统有足够的内存,这个读写全部由操作系统缓冲,效果非常好。即使是sync写模式,也是以数据累计到4K为一个单位写的,所以效率高。

那么随机读呢?这个它解决不了。但是ssd盘最擅长随机读了。这个硬件很自然的解决了这个问题。

所以leveldb的绝配是ssd盘的raid.

leveldb标准版本编译见浅谈LevelDB在ubuntu 11.04下编译失败的问题,由于标准版本用到了c++ 0x的特性,在RHEL平台下没得到支持,所以为了移植性, basho为它做了标准c++版本的port, 见目录c_src/leveldb. 他之所以用c++ 0x标准主要是用到里面的原子库,basho的port用了libatomicops搞定这个问题.

我们的测试采用的就是这个版本, 我们分别测试了1000万, 1亿,10亿数据量下的leveldb表现,发现随着数据集的变化性能变化不大。

由于leveldb默认的sst文件是2M, 在数据集达到100G的时候要占用几万个文件,我修改了:

  1. version_set.cc:23 static const int kTargetFileSize = 32 * 1048576; 

让默认的文件变成32M,减少目录的压力。

我的测试环境是:

  1. $uname -r    
  2. 2.6.18-164.el5 #RHEL 5U4    
  3. # 10* SAS 300G raid卡,fusionIO 320G, Flashcache,内存96G,  24 * Intel(R) Xeon(R) CPU  

top说:

  1. 21782 root      18   0 1273m 1.1g 2012 R 85.3  1.2   1152:34 db_bench  

iostat说:

  1. $iostat -dx 5    
  2. ...    
  3. sdb1              0.40     0.00  3.40  0.00    30.40     0.00     8.94     0.02    4.65   4.65   1.58    
  4. fioa              0.00     0.00 2074.80  3.80 16598.40    30.40     8.00     0.00    0.13   0.00   0.00    
  5. dm-0              0.00     0.00 1600.00  0.00 16630.40     0.00    10.39     0.25    0.15   0.15  24.76    
  6. ...  

该测试中请注意snappy压缩没有打开,如果有压缩性能还会高很多,因为IO少了一半。

write_buffer_size=$((256*1024*1024)),log大小设成256M,这样减少切换日志的开销和减少数据合并的频率。

同时应该注意到db_bench是单线程程序,还有一个compact线程,所以最多的时候这个程序只能跑到200%的cpu, IO util也不是很高. 换句话说如果是多线程程序的话性能还要N倍的提高。

我们来看下实际的性能数字:

 

  1. #1千万条记录    
  2. $sudo ./db_bench --num=10000000 --write_buffer_size=$((256*1024*1024))    
  3. LevelDB:    version 1.2    
  4. Date:       Fri May 27 17:14:33 2011    
  5. CPU:        24 * Intel(R) Xeon(R) CPU           X5670  @ 2.93GHz    
  6. CPUCache:   12288 KB    
  7. Keys:       16 bytes each    
  8. Values:     100 bytes each (50 bytes after compression)    
  9. Entries:    10000000    
  10. RawSize:    1106.3 MB (estimated)    
  11. FileSize:   629.4 MB (estimated)    
  12. write_buffer_size=268435456    
  13. WARNING: Snappy compression is not enabled    
  14. ------------------------------------------------    
  15. fillseq      :       2.134 micros/op;   51.8 MB/s    
  16. fillsync     :      70.722 micros/op;    1.6 MB/s (100000 ops)    
  17. fillrandom   :       5.229 micros/op;   21.2 MB/s    
  18. overwrite    :       5.396 micros/op;   20.5 MB/s    
  19. readrandom   :      65.729 micros/op;    
  20. readrandom   :      43.086 micros/op;    
  21. readseq      :       0.882 micros/op;  125.4 MB/s    
  22. readreverse  :       1.200 micros/op;   92.2 MB/s    
  23. compact      : 24599514.008 micros/op;    
  24. readrandom   :      12.663 micros/op;    
  25. readseq      :       0.372 micros/op;  297.4 MB/s    
  26. readreverse  :       0.559 micros/op;  198.0 MB/s    
  27. fill100K     :     349.894 micros/op;  272.6 MB/s (10000 ops)    
  28. crc32c       :       4.759 micros/op;  820.8 MB/s (4K per op)    
  29. snappycomp   :       3.099 micros/op; (snappy failure)    
  30. snappyuncomp :       2.146 micros/op; (snappy failure)    
  31.  
  32. #1亿条记录    
  33. $sudo ./db_bench --num=100000000 --write_buffer_size=$((256*1024*1024))    
  34. LevelDB:    version 1.2    
  35. Date:       Fri May 27 17:39:19 2011    
  36. CPU:        24 * Intel(R) Xeon(R) CPU           X5670  @ 2.93GHz    
  37. CPUCache:   12288 KB    
  38. Keys:       16 bytes each    
  39. Values:     100 bytes each (50 bytes after compression)    
  40. Entries:    100000000    
  41. RawSize:    11062.6 MB (estimated)    
  42. FileSize:   6294.3 MB (estimated)    
  43. write_buffer_size=268435456    
  44. WARNING: Snappy compression is not enabled    
  45. ------------------------------------------------    
  46. fillseq      :       2.140 micros/op;   51.7 MB/s    
  47. fillsync     :      70.592 micros/op;    1.6 MB/s (1000000 ops)    
  48. fillrandom   :       6.033 micros/op;   18.3 MB/s    
  49. overwrite    :       7.653 micros/op;   14.5 MB/s    
  50. readrandom   :      44.833 micros/op;    
  51. readrandom   :      43.963 micros/op;    
  52. readseq      :       0.561 micros/op;  197.1 MB/s    
  53. readreverse  :       0.809 micros/op;  136.8 MB/s    
  54. compact      : 123458261.013 micros/op;    
  55. readrandom   :      14.079 micros/op;    
  56. readseq      :       0.378 micros/op;  292.5 MB/s    
  57. readreverse  :       0.567 micros/op;  195.2 MB/s    
  58. fill100K     :    1516.707 micros/op;   62.9 MB/s (100000 ops)    
  59. crc32c       :       4.726 micros/op;  826.6 MB/s (4K per op)    
  60. snappycomp   :       1.907 micros/op; (snappy failure)    
  61. snappyuncomp :       0.954 micros/op; (snappy failure)    
  62.  
  63. #10亿条记录    
  64. $sudo ./db_bench --num=1000000000 --write_buffer_size=$((256*1024*1024))    
  65. Password:    
  66. LevelDB:    version 1.2    
  67. Date:       Sun May 29 17:04:14 2011    
  68. CPU:        24 * Intel(R) Xeon(R) CPU           X5670  @ 2.93GHz    
  69. CPUCache:   12288 KB    
  70. Keys:       16 bytes each    
  71. Values:     100 bytes each (50 bytes after compression)    
  72. Entries:    1000000000    
  73. RawSize:    110626.2 MB (estimated)    
  74. FileSize:   62942.5 MB (estimated)    
  75. write_buffer_size=268435456    
  76. WARNING: Snappy compression is not enabled    
  77. ------------------------------------------------    
  78. fillseq      :       2.126 micros/op;   52.0 MB/s    
  79. fillsync     :      63.644 micros/op;    1.7 MB/s (10000000 ops)    
  80. fillrandom   :      10.267 micros/op;   10.8 MB/s    
  81. overwrite    :      14.339 micros/op;    7.7 MB/s    
  82. ...比较慢待补充  

总结: Leveldb是个很好的kv库,重点解决了随机IO性能不好的问题,多线程更新的性能非常好.

原文链接:http://blog.yufeng.info/archives/1327

【编辑推荐】

  1. LevelDB—一个超高性能的K/V数据库
  2. 浅谈LevelDB在ubuntu 11.04下编译失败的问题

 

 

文章来源网络,作者:运维,如若转载,请注明出处:https://shuyeidc.com/wp/300343.html<

(0)
运维的头像运维
上一篇2025-05-23 20:03
下一篇 2025-05-23 20:05

相关推荐

  • 个人主题怎么制作?

    制作个人主题是一个将个人风格、兴趣或专业领域转化为视觉化或结构化内容的过程,无论是用于个人博客、作品集、社交媒体账号还是品牌形象,核心都是围绕“个人特色”展开,以下从定位、内容规划、视觉设计、技术实现四个维度,详细拆解制作个人主题的完整流程,明确主题定位:找到个人特色的核心主题定位是所有工作的起点,需要先回答……

    2025-11-20
    0
  • 社群营销管理关键是什么?

    社群营销的核心在于通过建立有温度、有价值、有归属感的社群,实现用户留存、转化和品牌传播,其管理需贯穿“目标定位-内容运营-用户互动-数据驱动-风险控制”全流程,以下从五个维度展开详细说明:明确社群定位与目标社群管理的首要任务是精准定位,需明确社群的核心价值(如行业交流、产品使用指导、兴趣分享等)、目标用户画像……

    2025-11-20
    0
  • 香港公司网站备案需要什么材料?

    香港公司进行网站备案是一个涉及多部门协调、流程相对严谨的过程,尤其需兼顾中国内地与香港两地的监管要求,由于香港公司注册地与中国内地不同,其网站若主要服务内地用户或使用内地服务器,需根据服务器位置、网站内容性质等,选择对应的备案路径(如工信部ICP备案或公安备案),以下从备案主体资格、流程步骤、材料准备、注意事项……

    2025-11-20
    0
  • 如何企业上云推广

    企业上云已成为数字化转型的核心战略,但推广过程中需结合行业特性、企业痛点与市场需求,构建系统性、多维度的推广体系,以下从市场定位、策略设计、执行落地及效果优化四个维度,详细拆解企业上云推广的实践路径,精准定位:明确目标企业与核心价值企业上云并非“一刀切”的方案,需先锁定目标客户群体,提炼差异化价值主张,客户分层……

    2025-11-20
    0
  • PS设计搜索框的实用技巧有哪些?

    在PS中设计一个美观且功能性的搜索框需要结合创意构思、视觉设计和用户体验考量,以下从设计思路、制作步骤、细节优化及交互预览等方面详细说明,帮助打造符合需求的搜索框,设计前的规划明确使用场景:根据网站或APP的整体风格确定搜索框的调性,例如极简风适合细线条和纯色,科技感适合渐变和发光效果,电商类则可能需要突出搜索……

    2025-11-20
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注