Question

我在Cassandra

中有以下表格定义

CREATE TABLE mytable
(
 colA text,
 colB text,
 startdate timestamp,
 colC text,
 colD text,
 colE text,
 PRIMARY KEY ((colA, colB, startdate), colC)
 ) WITH
 bloom_filter_fp_chance=0.100000 AND
 caching='KEYS_ONLY' AND
 dclocal_read_repair_chance=0.000000 AND
 gc_grace_seconds=864000 AND
 index_interval=128 AND
 read_repair_chance=0.100000 AND
 replicate_on_write='true' AND
 populate_io_cache_on_flush='false' AND
 default_time_to_live=0 AND
 speculative_retry='99.0PERCENTILE' AND
 memtable_flush_period_in_ms=0 AND
 compaction={'class': 'LeveledCompactionStrategy'} AND
 compression={'chunk_length_kb': '64', 'sstable_compression':      'DeflateCompressor'};

 CREATE INDEX colDIdx ON mytable (colD);
 CREATE INDEX colEIdx ON mytable (colE);

这张表几乎没有400条记录。当我从cqlsh提示符运行以下查询时：

SELECT * FROM mytable WHERE colA = 'colAValue' AND colB = 'colBValue' AND startdate = 1418947200000 and colD = 'XYZ' and colE = 'ABC' ALLOW FILTERING;

然后我收到以下错误消息，查询没有返回结果。

"Request did not complete within rpc_timeout"

但是，当我删除最后2个过滤条件colD和colE时，查询会成功运行。

我不知道在过滤条件中使用二级索引列有什么问题。

Answer 1

如果我开始声明不建议使用Cassandra的二级索引，那么我可能听起来不是很原始。

二级索引的工作方式是，一般来说，它们只是作为表实现，但它们不是围绕环分布的。您可以阅读有关二级索引here的更多信息。这意味着通过辅助索引添加搜索会自动将调用添加到环中的所有节点，然后组合结果，然后仅基于主键进行过滤。

因此，这就是为什么主键的查询速度快，而不是使用二级索引过滤的查询。

为什么只有400条记录超时 - 这是另一个问题。我假设超时值没有从默认的10000毫秒更改。好吧，我的猜测是JVM堆大小可能太小，并且由于所有索引数据都需要加载到内存中进行处理，因此gc暂停可能会导致查询失败。您可能想要检查垃圾收集会发生什么。

HTH

Answer 2

跟踪并检查登录system.log文件。基本上，当有太多的墓碑时会出现这个错误。在你的cassandra集群上运行nodetool compact并再次检查它。

带有二级索引的CQL - 请求未在rpc_timeout内完成

2 个答案: