Cassandra cql 选择查询总是抛出读取超时异常答案

【问题标题】：Cassandra cql select query throws read time out exception alwaysCassandra cql 选择查询总是抛出读取超时异常
【发布时间】：2016-07-03 16:47:41
【问题描述】：

当我尝试执行以下查询时，我总是收到 QueryTimeOutException，

Exception is,
    com.datastax.driver.core.exceptions.ReadTimeoutException: Cassandra timeout during read query at consistency QUORUM (2 responses were required but only 0 replica responded)

Query is,
    SELECT * FROM my_test.my_table WHERE key_1 = 101 ORDER BY key_2 ASC LIMIT 25;

我正在使用具有 3 个节点的 cassandra 版本 2.1.0，具有 3 个复制的单个 DC，cassandra.yaml 具有所有默认值，并且我具有以下键空间和表作为架构，

CREATE KEYSPACE my_test
  WITH REPLICATION = { 
    'class' : 'SimpleStrategy', 
    'replication_factor' : 3
};

CREATE TABLE my_test.my_table (
    key_1 bigint,
    key_2 bigint,
    key_3 text,
    key_4 text,
    key_5 text,
    key_6 text,
    key_7 text,
    key_8 text,
    key_9 text,
    key_10 text,
    key_11 timestamp,
    PRIMARY KEY (key_1, key_2)
);

目前该表有大约 39000 条记录，但最初它有 50000 条记录，11000 条记录已因某些业务逻辑而被删除。

解决方案之一to avoid such exception is to increase query read time out，但是我的架构和查询是more direct why should I increase my read time out？由于在我的查询中我已经给出了分区键（key_1）所以它应该准确地到达目的地，之后我指定了分区键的起始范围，所以它应该以 2 秒的最大时间检索，但事实并非如此。但下面的查询工作正常，不到 1 秒就检索到了结果 (Difference is, ASC is not working and DESC is working)

SELECT * FROM my_test.my_table WHERE key_1 = 101 ORDER BY key_2 DESC LIMIT 25;

再次根据架构，集群键默认顺序是 ASC，因此根据 cassandra 文档，在 ASC 中检索数据应该比 DESC 顺序更快。但在我的情况下是相反的。

再次提供一些线索，以下是通过 CQLSH 尝试过的查询。

以下查询正在运行，不到 1 秒就检索到了结果

SELECT * FROM my_test.my_table WHERE key_1 = 101 AND key_2 > 1 AND key_2 < 132645 LIMIT 1;

但是，以下查询不起作用并引发超时异常，

SELECT * FROM my_test.my_table WHERE key_1 = 101 AND key_2 > 1 AND key_2 < 132646 LIMIT 1;

但是，以下查询正在运行，检索结果不到 1 秒

SELECT * FROM my_test.my_table WHERE key_1 = 101 AND key_2 = 132644;
SELECT * FROM my_test.my_table WHERE key_1 = 101 AND key_2 = 132645;
SELECT * FROM my_test.my_table WHERE key_1 = 101 AND key_2 = 132646;
SELECT * FROM my_test.my_table WHERE key_1 = 101 AND key_2 = 132647;

如有任何帮助，我们将不胜感激。

【问题讨论】：

尝试打开 CQLSH 跟踪，看看它告诉你什么：docs.datastax.com/en/cql/3.3/cql/cql_reference/tracing_r.html
cqlsh> SELECT * FROM my_test.my_table WHERE key_1 = 101 ORDER BY key_2 ASC LIMIT 500; code=1200 [协调节点等待副本节点响应超时] message="操作超时 - 仅收到 0 个响应。" info={'received_responses': 0, 'data_retrieved': False, 'required_responses': 1, 'consistency': 1} 语句跟踪未在 10 秒内完成
@bechbd 我猜如果查询成功，查询跟踪将给出结果。
可能不相关，但请避免使用新刻度线模型之前的 .0 版本。 2.1.0 是 2.1 中最不稳定的版本，升级到 2.1.13 将是一个巨大的改进（大量错误修复）。
顺便说一句- +1 并收藏。从学术的角度来看，这个问题是纯金的。我不记得有其他人做过这样的事情，这是一个很棒的示例，可以在未来进行链接。尽管这是一个不该做的例子，但拥有这些同样重要（如果不是更重要的话）。

标签： cassandra cql datastax-java-driver cqlsh

【解决方案1】：

对于每个 key_1，大约有 1000000 个 key_2。

当您将每个分区限制为 20 亿个单元并尝试使用所有这些时，就会发生这种情况。我知道我之前在这里回答过很多帖子，承认每个分区有 20 亿个单元的硬性限制，你的（非常）宽行会变得笨拙，并且可能在此之前超时 long .这就是我相信你所看到的。

这里的解决方案是一种称为“分桶”的技术。基本上，您必须找到一个额外的密钥来分区您的数据。太多的 CQL 行被写入同一个数据分区，分桶有助于将分区与集群键的比率恢复到正常水平。

进行分桶的合乎逻辑的方法是使用时间元素。我看到您的最后一个键是时间戳。我不知道每个key_1 一天有多少行，但假设你每个月只有几千行。在这种情况下，我会创建一个额外的分区键month_bucket：

CREATE TABLE my_test.my_table (
    key_1 bigint,
    key_2 bigint,
    ...
    key_11 timestamp,
    month_bucket text,
    PRIMARY KEY ((key_1,month_bucket) key_2)
);

这将允许您支持这样的查询：

SELECT * FROM my_test.my_table 
WHERE key_1 = 101 AND month_bucket = '201603'
  AND key_2 > 1 AND key_2 < 132646 LIMIT 1;

同样，按月分桶只是一个示例。但基本上，您需要找到一个额外的列来对您的数据进行分区。

【讨论】：

是的，我当然知道，但是当这个问题发生时，该表只有大约 39000 条记录，但最初它有 50000 条记录，11000 条记录已因某些业务逻辑而被删除。这是我在我的问题中提到的。所以它有 50000 条记录和一些墓碑行。所以它应该像我的期望一样工作。
同样，默认集群顺序是 ASC，所以在我的情况下，ASC 应该比 DESC 工作得非常快（原因：非常大的宽行......）但在我的情况下它是相反的。这也是我在问题中提到的。
@JayaAnanthram “所以它应该符合我的期望。”然而，事实并非如此。看，我知道没有人喜欢被告知他们需要完全吹散并重新加载他们的数据以进行模型更改在他们投入生产之后。但是你的行太宽了，真的没有一个快速的解决方法。继续用 cassandra-stress 测试这两个模型，它不仅应该可以工作，而且我敢打赌，使用“桶”比使用非常宽的行时，您的 op/s 会高得多。
是的，我同意你的看法。我知道行太宽对性能的影响。当我设计架构时，我提出了一个关于一年前链接过宽的行性能下降的问题（请参阅最后一条评论），你回答了它，你的回答是“cassandra upgrade will fix it”。
虽然选择宽行模式的原因是，我的业务需求是具有分页视图（逐页、最后一页、第一页）、计数、搜索的纯数据页面概念。对于那些，我不能像你在你的例子中展示的那样设计。因此，我们以一种宽排的方式进行。如果数据涉及的范围太广，那么我们可以解决办法将其放入单独的分区中。

【解决方案2】：

问题已解决after restarting all the 3 cassandra servers。我不知道到底是什么惹了麻烦。因为它在生产服务器中，所以无法获得确切的根本原因。

【讨论】：