在where子句导致OperationTimedOut误差在卡桑德拉

特定值I运行卡桑德拉簇与cqlsh 5个节点的查询。它给我OperationTimedOut错误。如果我在where子句参数中稍做修改，它会给我空的结果。这是预期的。即使我更改参数的单个字符，但完全相同的参数值给我超时也没关系。为什么这样？在where子句导致OperationTimedOut误差在卡桑德拉

查询：

select * from table where pid = '5f334fef-2629-484c-a081-c4a6f554c6ab'

这里是表模式

CREATE TABLE dmp.interest_data (
    pid text, 
    attribute text, 
    country text, 
    day_count int, 
    first_seen timestamp, 
    flag int, 
    keys set<text>, 
    last_seen timestamp, 
    score int, 
    usage_count int, 
    PRIMARY KEY (pid, attribute) 
) WITH CLUSTERING ORDER BY (attribute ASC) 
    AND bloom_filter_fp_chance = 0.01 
    AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}' 
    AND comment = '' 
    AND compaction = {'min_threshold': '4', 'class': 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy', 'max_threshold': '32'} 
    AND compression = {'chunk_length_kb': '256', 'sstable_compression': 'org.apache.cassandra.io.compress.LZ4Compressor'} 
    AND dclocal_read_repair_chance = 0.1 
    AND default_time_to_live = 0 
    AND gc_grace_seconds = 172800 
    AND max_index_interval = 2048 
    AND memtable_flush_period_in_ms = 0 
    AND min_index_interval = 128 
    AND read_repair_chance = 0.1 
    AND speculative_retry = '99.0PERCENTILE'; 
CREATE INDEX interest_data_attribute_idx ON dmp.interest_data (attribute); 
CREATE INDEX interest_data_country_idx ON dmp.interest_data (country); 
CREATE INDEX interest_data_day_count_idx ON dmp.interest_data (day_count); 
CREATE INDEX interest_data_first_seen_idx ON dmp.interest_data (first_seen); 
CREATE INDEX interest_data_usage_count_idx ON dmp.interest_data (usage_count);

更新：价值PID中所提到的where子句应该是有表，因为它是一个查询插入其中没有给出任何错误。但是当查询它时会发生这种超时。现在发生了奇怪的事。我试图删除它，它被删除了！因为删除后我尝试选择相同的，我得到空的结果。所以确实是在那里，它是在某种形式的损坏，导致超时。现在我需要知道这样的事情怎么可能发生

来源

2016-03-03 Shades88

5个二级索引？重要的是要注意，二级索引是卡桑德拉的一个反模式 – Aaron

好的。这个？这可真帮我 – Shades88

亚伦是正确的，警告你次要指标，但我不认为这是这里的问题。你说改变where子句参数时，你是什么意思？你CH愤怒'5f334fef-2629-484c-a081-c4a6f554c6ab'的价值？你期望用这个值有一些结果吗？你用这个pid插入了多少个属性？ – DineMartine

检查节点的状态，改变您查询更改拥有该值的节点的值，那么很可能是你的一个节点是具有问题和值超时属于该节点。当你改变这个值时，新的属性被不同的节点所拥有，所以它不会超时。

来源

2016-03-05 04:59:11 Zanson

Re：关于删除成功和腐败问题的更新。

这可以当您查询，并与一致性1级插入（在评论中提及）肯定会发生。假设密钥空间中的复制因子高于1（通常为3）。在插入过程中，可能是某个节点或两个关键点处于故障状态，有时（集群处于加载状态，维护问题等） - 复制不会执行作业，数据也不会复制到复制节点。

发生这种情况时，仅修复操作（或什么都没有），可以帮助解决问题。

结果是有1-2个服务器应该保持该行，但实际上并没有它，这可能会导致各种奇怪的故障情况。

我没有为超时一个很好的解释，除非该行有很多很多列，它只是没有“及时”

完成。如果再次出现这种情况，请尝试使用限制条款（从1开始，如果可行，它可能是一个非常长的查询，并自然超时。

来源

2016-03-07 13:23:00

是，一致性级别是1，但复制因子也是1 – Shades88

您是否尝试使用LIMIT？ –

是的，我没有工作 – Shades88

在where子句导致OperationTimedOut误差在卡桑德拉

回答

相关问题