leveldb 성능 분석 및 표현

Leveldb 는 google 이 실현 하 는 매우 효율 적 인 kv 데이터 베이스 로 현재 버 전 1.2 는 billion 급 의 데 이 터 를 지원 할 수 있 습 니 다.이 수량 등급 에서 매우 높 은 성능 을 가지 고 있 는데 주로 그의 좋 은 디자인 덕분이다.특히 LSM 알고리즘 은
그렇다면 데이터베이스 에서 가장 무 서운 랜 덤 IO 는 어떻게 해결 할 것 인가?
먼저 랜 덤 으로 쓰 는 것 은 로그 파일 에 먼저 기록 하 는 것 입 니 다. 로그 파일 이 가득 차기 전에 memtable 을 간단하게 업데이트 하면 랜 덤 으로 쓰 는 것 을 순서 로 바 꿉 니 다.로그 가 가득 찬 후 로그 에 있 는 데 이 터 를 sst 표 로 정렬 하 는 동시에 이전 sst 와 통합 합 니 다. 이 동작 도 순서대로 읽 고 쓰 는 것 입 니 다.전통 적 인 디스크 raid 의 순서 읽 기와 쓰기 스루풋 이 매우 많 고 100 M 정도 에는 문제 가 없다 는 것 을 잘 알 고 있다.로그 파일 을 쓸 때 buffer IO 를 사용 합 니 다. 즉, 운영 체제 에 메모리 가 충분 하 다 면 이 읽 기와 쓰 기 는 모두 운영 체제 에서 버퍼 링 되 어 효과 가 매우 좋 습 니 다.sync 쓰기 모드 라 도 데이터 누적 4K 를 한 단위 로 쓰기 때문에 효율 이 높다.
그럼 랜 덤 으로 읽 을까요?이 건 해결 이 안 돼.하지만 ss d 판 은 랜 덤 으로 읽 는 것 이 가장 뛰어나다.이 하드웨어 는 매우 자 연 스 럽 게 이 문 제 를 해결 했다.
그래서 leveldb 의 절 배 는 ssd 디스크 의 raid. leveldb 표준 버 전 으로 컴 파일 되 었 습 니 다. 표준 버 전 은 c + 0x 의 특성 을 사 용 했 기 때문에 RHEL 플랫폼 에서 지원 을 받 지 못 했 습 니 다. 그래서 이식 성 을 위해 basho 는 여기 서 표준 c + 버 전의 port 를 만 들 었 습 니 다. 디 렉 터 리 c 참조.src / leveldb. 그 가 c + 0x 기준 을 사용 하 는 이 유 는 주로 안에 있 는 원자 라 이브 러 리 를 사용 하 는 것 이다. basho 의 port 는 libatomicops 로 이 문 제 를 해결 했다.
우리 의 테스트 는 바로 이 버 전 을 채택 했다. 우 리 는 각각 1000 만, 1 억, 10 억 데이터 양의 leveldb 표현 을 테스트 한 결과 데이터 집합의 변화 에 따라 성능 변화 가 크 지 않다 는 것 을 발견 했다.leveldb 의 기본 sst 파일 은 2M 이기 때문에 데이터 세트 가 100 G 에 이 를 때 수만 개의 파일 을 사용 해 야 합 니 다. 수정 하 였 습 니 다.version_set.cc：23  static   const   int   kTargetFileSize = 32 * 1048576;
기본 파일 을 32M 으로 만들어 디 렉 터 리 의 압력 을 줄 입 니 다.
나의 테스트 환경 은:$ uname   -r 2.6.18-164.el5  #RHEL 5U4 # 10* SAS 300G raid ，fusionIO 320G, Flashcache, 96G,  24 * Intel(R) Xeon(R) CPU
top 설:21782 root      18   0 1273m 1.1g 2012 R 85.3  1.2   1152:34 db_bench
iostat:

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

이 테스트 에 서 는 snappy 압축 이 열 리 지 않 았 음 을 주의 하 십시오. 압축 성능 이 있 으 면 IO 가 절반 이 부족 하기 때 문 입 니 다.
write_buffer_size = $(256 * 1024 * 1024), log 크기 를 256 M 으로 설정 하여 로그 전환 비용 을 줄 이 고 데이터 통합 빈 도 를 줄 입 니 다.
db벤 치 는 단일 스 레 드 프로그램 이 고 컴 팩 트 스 레 드 도 있 기 때문에 가장 많 을 때 이 프로그램 은 200% 의 cpu 만 달 릴 수 있 고 IO util 도 높 지 않다. 다시 말 하면 다 중 스 레 드 프로그램 이 라면 성능 이 N 배 더 향상 된다 는 것 이다.
우 리 는 실제 성능 숫자 를 살 펴 보 자.
view source
print

#1     
$sudo ./db_bench --num=10000000 --write_buffer_size=$((256*1024*1024))
LevelDB:    version 1.2
Date:       Fri May 27 17:14:33 2011
CPU:        24 * Intel(R) Xeon(R) CPU           X5670  @ 2.93GHz
CPUCache:   12288 KB
Keys:       16 bytes each
Values:     100 bytes each (50 bytes after compression)
Entries:    10000000
RawSize:    1106.3 MB (estimated)
FileSize:   629.4 MB (estimated)
write_buffer_size=268435456
WARNING: Snappy compression is not enabled
------------------------------------------------
fillseq      :       2.134 micros/op;   51.8 MB/s      
fillsync     :      70.722 micros/op;    1.6 MB/s (100000 ops)
fillrandom   :       5.229 micros/op;   21.2 MB/s      
overwrite    :       5.396 micros/op;   20.5 MB/s      
readrandom   :      65.729 micros/op;                  
readrandom   :      43.086 micros/op;                  
readseq      :       0.882 micros/op;  125.4 MB/s     
readreverse  :       1.200 micros/op;   92.2 MB/s     
compact      : 24599514.008 micros/op;
readrandom   :      12.663 micros/op;                  
readseq      :       0.372 micros/op;  297.4 MB/s     
readreverse  :       0.559 micros/op;  198.0 MB/s     
fill100K     :     349.894 micros/op;  272.6 MB/s (10000 ops)
crc32c       :       4.759 micros/op;  820.8 MB/s (4K per op)
snappycomp   :       3.099 micros/op; (snappy failure)
snappyuncomp :       2.146 micros/op; (snappy failure)

#1    
$sudo ./db_bench --num=100000000 --write_buffer_size=$((256*1024*1024))
LevelDB:    version 1.2
Date:       Fri May 27 17:39:19 2011
CPU:        24 * Intel(R) Xeon(R) CPU           X5670  @ 2.93GHz
CPUCache:   12288 KB
Keys:       16 bytes each
Values:     100 bytes each (50 bytes after compression)
Entries:    100000000
RawSize:    11062.6 MB (estimated)
FileSize:   6294.3 MB (estimated)
write_buffer_size=268435456
WARNING: Snappy compression is not enabled
------------------------------------------------
fillseq      :       2.140 micros/op;   51.7 MB/s       
fillsync     :      70.592 micros/op;    1.6 MB/s (1000000 ops)
fillrandom   :       6.033 micros/op;   18.3 MB/s       
overwrite    :       7.653 micros/op;   14.5 MB/s       
readrandom   :      44.833 micros/op;                   
readrandom   :      43.963 micros/op;                   
readseq      :       0.561 micros/op;  197.1 MB/s      
readreverse  :       0.809 micros/op;  136.8 MB/s      
compact      : 123458261.013 micros/op;
readrandom   :      14.079 micros/op;                   
readseq      :       0.378 micros/op;  292.5 MB/s      
readreverse  :       0.567 micros/op;  195.2 MB/s      
fill100K     :    1516.707 micros/op;   62.9 MB/s (100000 ops)
crc32c       :       4.726 micros/op;  826.6 MB/s (4K per op)
snappycomp   :       1.907 micros/op; (snappy failure)
snappyuncomp :       0.954 micros/op; (snappy failure)

#10    
$sudo ./db_bench --num=1000000000 --write_buffer_size=$((256*1024*1024))
Password: 
LevelDB:    version 1.2
Date:       Sun May 29 17:04:14 2011
CPU:        24 * Intel(R) Xeon(R) CPU           X5670  @ 2.93GHz
CPUCache:   12288 KB
Keys:       16 bytes each
Values:     100 bytes each (50 bytes after compression)
Entries:    1000000000
RawSize:    110626.2 MB (estimated)
FileSize:   62942.5 MB (estimated)
write_buffer_size=268435456
WARNING: Snappy compression is not enabled
------------------------------------------------
fillseq      :       2.126 micros/op;   52.0 MB/s 
fillsync     :      63.644 micros/op;    1.7 MB/s (10000000 ops)
fillrandom   :      10.267 micros/op;   10.8 MB/s        
overwrite    :      14.339 micros/op;    7.7 MB/s  

결론: Leveldb 는 좋 은 kv 라 이브 러 리 로 무 작위 IO 의 성능 이 좋 지 않 은 문 제 를 중점적으로 해 결 했 고 다 중 스 레 드 업데이트 의 성능 이 매우 좋 습 니 다.
원문http://blog.yufeng.info/archives/1327