试图找出cassandra读取这么长时间的原因,我使用了跟踪并限制了行数。奇怪的是,当我查询600行时,我得到的结果是~50毫秒。但610行需要近1秒!
cqlsh> select containerdefinitionid from containerdefinition limit 600;
... lots of output ...
Tracing session: 6b506cd0-83bc-11e3-96e8-e182571757d7
activity | timestamp | source | source_elapsed
-------------------------------------------------------------------------------------------------+--------------+---------------+----------------
execute_cql3_query | 15:25:02,878 | 130.4.147.116 | 0
Parsing statement | 15:25:02,878 | 130.4.147.116 | 39
Peparing statement | 15:25:02,878 | 130.4.147.116 | 101
Determining replicas to query | 15:25:02,878 | 130.4.147.116 | 152
Executing seq scan across 1 sstables for [min(-9223372036854775808), min(-9223372036854775808)] | 15:25:02,879 | 130.4.147.116 | 1021
Scanned 755 rows and matched 755 | 15:25:02,933 | 130.4.147.116 | 55169
Request complete | 15:25:02,934 | 130.4.147.116 | 56300
cqlsh> select containerdefinitionid from containerdefinition limit 610;
... just about the same output and trace info, except...
Scanned 766 rows and matched 766 | 15:25:58,908 | 130.4.147.116 | 739141
这些特定行中的数据似乎没有什么异常: - 值类似于之前和之后的值。 - 使用COPY命令我可以导出整个表并导入到不同的集群上,性能很好。 - 这些行是第一个示例,但似乎还有其他地方查询时间也会跳转。整个表只有~3000行,但需要大约15秒来列出所有主键。
数据STORAGE似乎有些不寻常: - 将快照复制到另一个群集并导入的相同结果具有相同的限制 - 将COPY数据复制到CSV然后再转移到另一个群集中,性能很好
尝试过压缩,修复,重新索引,清理和刷新。没效果。
我意识到我可以通过复制数据来“修复”,但是我想弄清楚这里发生了什么,以避免它在生产中发生在一个太大而无法修复COPY的表格上。
表有17列,3个索引,TEXT主键,两个LIST列和两个TIMESTAMP列;其余的是TEXT。可以重现SimpleStrategy和DC感知复制的问题。可以在4台服务器上复制4份数据,在2台服务器上复制2份,在2台服务器上复制1份(如果在本地执行查询或涉及多台服务器,则无关紧要)。 Cassandra-1.2 with cqlsh。
有什么想法吗?建议?
答案 0 :(得分:0)
是否有可能为特定分区启用行缓存? 行缓存包含最近在内存中访问的所有行,因此可能提供更好的性能。
包含分区密钥缓存及其在磁盘上的偏移量的密钥缓存也可以提供更好的性能。
您能告诉我您目前使用哪种设置进行行缓存,密钥缓存