【发布时间】：2015-01-10 21:37:08
【问题描述】：
我们正在研究迁移到 Cassandra (2.0.10)，并且正在测试写入和读取性能。
在阅读时，我们看到读取吞吐量似乎很低，平均为 14MB/s。
我们目前的测试环境只有一个节点，Xeon E5-1620 @ 3.7GHZ，32GB RAM，windows 7。 Cassandra 堆设置为 8GB，默认并发读取和写入，密钥缓存大小设置为 400mb，数据位于本地 RAID10 阵列上，该阵列使用 64KB 和更高的块大小进行持续平均 300MB/s 的顺序读取性能。
我们正在使用当前模型存储每小时的传感器数据：
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。
数据由多个线程插入（因此插入不按事件时间排序，如果重要的话）
读取一天的数据大约需要 2m，吞吐量为 14MB/s。 使用带有准备好的语句的 java-cassandara-connector 完成读取：
Select event_time, load from sensor_data_by_day where sensor_id = ? and date in ('2014-02-02') and event_time >= ? and event_time < ?
我们创建一个连接并将任务（作为传感器数量的 100K 查询）提交到具有 100 个线程池的执行器服务。 数据在缓存中时读取大约需要 7s。
这可能不是客户端问题，我们在数据位于 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
263210 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=而不是date IN，您可能会做得更好。 -
看看
TRACING为您查询以及（datastax.com/documentation/cql/3.1/cql/cql_reference/…）