成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

LevelDB性能分析和表現

數據庫 其他數據庫
Leveldb是一個google實現的非常高效的kv數據庫,目前的版本1.2能夠支持billion級別的數據量了。 在這個數量級別下還有著非常高的性能,主要歸功于它的良好的設計。特別是LSM算法。

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下編譯失敗的問題

 

 

責任編輯:艾婧 來源: Erlang非業余研究
相關推薦

2009-07-14 17:58:55

Jython性能

2021-09-20 11:41:56

Windows 11硬盤空間占用微軟

2021-09-27 14:33:01

Windows 11Windows微軟

2019-03-12 11:11:25

開源Leveldb存儲

2009-03-28 16:56:55

NehalemIntel服務器

2013-04-01 09:50:15

Web框架Web

2011-11-18 15:01:32

筆記本評測

2013-07-26 17:07:33

Foglight容量

2009-12-01 11:43:59

浪涌

2010-03-24 14:06:04

APC

2018-11-30 16:04:32

Macbook Pro顯卡性能

2011-06-09 08:52:30

LevelDB

2010-02-05 16:10:37

全千兆交換機

2011-02-23 11:18:48

MongoDBMySQL性能測試

2023-02-22 08:15:13

壓測模擬計算

2015-08-18 11:44:02

PHP性能分析宏觀分析

2015-09-14 10:41:51

PHP性能分析微觀分析

2015-10-30 15:30:54

LevelDBSSTableSybase

2011-06-28 13:35:39

HP ProLiant服務器G7

2011-09-16 17:00:31

惠普激光打印機
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 久久久99国产精品免费 | 欧美激情在线精品一区二区三区 | 欧美日韩精品综合 | 精品亚洲永久免费精品 | 一级黄色在线 | 夫妻午夜影院 | 免费在线a视频 | 久久国产精品一区二区三区 | 久久久久久久久久久久久久av | 99精品热视频| jlzzjlzz国产精品久久 | 国产精品一卡 | 天天天操天天天干 | 亚洲a在线视频 | 欧美精品一区二区三区四区五区 | 中文字幕av一区二区三区 | 亚洲精品国产a久久久久久 中文字幕一区二区三区四区五区 | 精品国产欧美一区二区三区不卡 | 日韩中文一区 | 午夜免费av | 日日草夜夜草 | 青青草av网站 | 拍戏被cao翻了h承欢 | 91在线精品秘密一区二区 | 中文字幕在线观 | 成人毛片网站 | 亚洲啪啪一区 | 手机av网 | 成人影院在线 | 亚洲视频在线观看一区二区三区 | 天天操天天射天天 | 欧美视频在线播放 | 一区二区久久 | 婷婷狠狠| 天堂亚洲 | 精品视频一区二区 | 欧美一区在线看 | 一区二区成人在线 | 久久精品亚洲精品国产欧美 | 国产在线精品一区二区三区 | 人人玩人人添人人澡欧美 |