카산드라 (2.0.10) 로의 이동을 연구하는 중이고 쓰기 및 읽기 성능을 테스트 중입니다.카산드라 (timeseries 데이터)로 낮은 읽기 처리량
우리는 평균 읽기 속도가 14MB/s 인 것을보고 있습니다.
현재 테스트 환경은 32GB RAM, Windows 7이있는 Xeon E5-1620 @ 3.7GHZ 노드입니다. Cassandra 힙은 기본 동시 읽기 및 쓰기로 8GB로 설정되었으며 키 캐시 크기는 400MB로 설정되어 있습니다. 데이터는 64KB 이상의 블록 크기를 사용하여 300MB/s 순차 읽기 성능을 지속적으로 유지하는 로컬 RAID10 어레이에 위치합니다.
우리는 현재 모델로 시간당 센서 데이터를 저장됩니다
CREATE TABLE IF NOT EXISTS sensor_data_by_day (
sensor_id int,
date text,
event_time timestamp,
load float,
PRIMARY KEY ((sensor_id,date),event_time))
읽기는 센서, 날짜 및 이벤트 시간의 범위에서 수행된다.
현재 데이터 세트는 100K 센서의 경우 2 년 분량의 데이터, 디스크의 경우 약 30GB입니다.
데이터 다시 데이터의 일의 가치를 읽기
다수의 스레드에 의해 삽입되는 (그래서 중요한 경우 삽입이 이벤트 시간으로 분류되지 않음) 14메가바이트/s의 처리량을 약 2m 걸립니다. 읽기는 준비된 문을 사용하여 자바-cassandara 커넥터를 사용하여 수행됩니다 :
Select event_time, load from sensor_data_by_day where sensor_id = ? and date in ('2014-02-02') and event_time >= ? and event_time < ?
우리는 100 개 스레드 풀 집행자 서비스에 대한 하나 개의 연결 및 제출 작업 (센서의 수가 10 만 쿼리)를 만들 수 있습니다. 데이터가 캐시에있을 때 읽기에는 약 7 초가 걸립니다.
데이터가 SSD에 있고 총 시간이 2m에서 10s (~ 170MB/s)로 떨어졌을 때 테스트 한 결과 클라이언트 문제는 아닙니다. 이는 SSD이기 때문에 더 낫습니다.
읽기 성능이 블록 읽기 크기 문제인 것처럼 보이므로 Cassandra가 4KB 블록을 읽는 중 낮은 읽기가 발생할 수 있습니다. 나는 디폴트가 256이라고 읽었지 만 어디서나 또는 아마 임의의 I/O 문제를 확인하기위한 설정을 찾지 못했습니까?
기계식 디스크를 사용할 때 Cassandra에서 기대하는 읽기 성능입니까? 아마도 모델링 문제일까요? cfhistograms의
출력 :
SSTables per Read
1 sstables: 844726
2 sstables: 90
Write Latency (microseconds)
No Data
Read Latency (microseconds)
5 us: 418
6 us: 15252
7 us: 12884
8 us: 15447
10 us: 34211
12 us: 48972
14 us: 48421
17 us: 56641
20 us: 12484
24 us: 8325
29 us: 6602
35 us: 4953
42 us: 5427
50 us: 3610
60 us: 1784
72 us: 2414
86 us: 11208
103 us: 38395
124 us: 82050
149 us: 64840
179 us: 40161
215 us: 30891
258 us: 17691
310 us: 8787
372 us: 4171
446 us: 2305
535 us: 1588
642 us: 1187
770 us: 913
924 us: 811
1109 us: 716
1331 us: 602
1597 us: 513
1916 us: 513
2299 us: 516
2759 us: 595
3311 us: 776
3973 us: 1086
4768 us: 1502
5722 us: 2212
6866 us: 3264
8239 us: 4852
9887 us: 7586
11864 us: 11429
14237 us: 17236
17084 us: 22285
20501 us: 26163
24601 us: 26799
29521 us: 24311
35425 us: 22101
42510 us: 19420
51012 us: 16497
61214 us: 13830
73457 us: 11356
88148 us: 8749
105778 us: 6243
126934 us: 4406
152321 us: 2751
182785 us: 1754
219342 us: 977
us: 497
315852 us: 233
379022 us: 109
454826 us: 60
545791 us: 21
654949 us: 10
785939 us: 2
943127 us: 0
1131752 us: 1
Partition Size (bytes)
179 bytes: 151874
215 bytes: 0
258 bytes: 0
310 bytes: 0
372 bytes: 5071
446 bytes: 0
535 bytes: 4170
642 bytes: 3724
770 bytes: 3454
924 bytes: 3416
1109 bytes: 3489
1331 bytes: 9179
1597 bytes: 11616
1916 bytes: 12435
2299 bytes: 19038
2759 bytes: 20653
3311 bytes: 10245454
3973 bytes: 25121333
Cell Count per Partition
4 cells: 151874
5 cells: 0
6 cells: 0
7 cells: 0
8 cells: 5071
10 cells: 0
12 cells: 4170
14 cells: 0
17 cells: 3724
20 cells: 3454
24 cells: 3416
29 cells: 3489
35 cells: 3870
42 cells: 9982
50 cells: 13521
60 cells: 20108
72 cells: 16678
86 cells: 51646
103 cells: 35323903
이것은 중요한 문제는 아니지만 'IN'연산자는 실제로 성능에 최적화되어 있지 않습니다. 'date IN' 대신에'date ='를 사용하면 더 잘 수행 할 수 있습니다. – Aaron
당신을 위해서''TRACING''을보십시오 (http://www.datastax.com/documentation/cql/3.1/cql/cql_reference/tracing_r.html) –