use*_*568 3 performance cassandra secondary-indexes
我们有一个大约40k行的表,查询二级索引很慢(生产时间为30秒).我们的cassandra是1.2.8.表模式如下:
CREATE TABLE usertask (
tid uuid PRIMARY KEY,
content text,
ts int
) WITH
bloom_filter_fp_chance=0.010000 AND
caching='KEYS_ONLY' AND
comment='' AND
dclocal_read_repair_chance=0.000000 AND
gc_grace_seconds=864000 AND
read_repair_chance=0.100000 AND
replicate_on_write='true' AND
populate_io_cache_on_flush='false' AND
compaction={'class': 'SizeTieredCompactionStrategy'} AND
compression={'sstable_compression': 'SnappyCompressor'};
CREATE INDEX usertask_ts_idx ON usertask (ts);
Run Code Online (Sandbox Code Playgroud)
当我打开跟踪时,我注意到有很多行如下:
Executing single-partition query on usertask.usertask_ts_idx
Run Code Online (Sandbox Code Playgroud)
只有40k行,看起来有一些关于usertask_ts_idx的查询.可能是什么问题呢?谢谢
我在我们的测试服务器上尝试相同的查询,速度更快(测试服务器上30秒,测试服务器上1-2秒).在比较跟踪日志之后,差异是在数据文件中寻求分区索引部分所花费的时间.在我们的生产中,每次搜索需要1000-3000微秒,在开发服务器上需要100微秒.我想我们的生产服务器没有足够的内存来缓存数据文件,因此在数据文件中查找速度很慢.
我假设ts是时间戳,在这种情况下,这不是二级索引的良好候选者.原因是它是一个高基数值(即所有值基本上都是唯一的).这意味着您最终会在索引中为每行输入几乎一行 - usertask有效地导致连接操作.联接在分布式数据库上非常慢.由于您没有显示您的查询,我不确定您正在做什么,但如果您想根据时间进行查询,则需要重新考虑您的模型.
| 归档时间: |
|
| 查看次数: |
2351 次 |
| 最近记录: |