Cassandra cql select查询始终引发读取超时异常

当我试图执行下面的查询时，我总是得到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;

我使用的cassandra 2.1.0版本有3个节点，单个DC有3个复制，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条记录已被删除，用于某些业务逻辑

避免此类异常的解决方案之一是增加查询读取超时，但是我的模式和查询更直接，为什么我要增加读取超时？ 因为在我的查询中，我已经给出了分区键（key_1），所以它应该准确地到达目的地，在我指定了分区键的开始范围之后， 因此，它应该以最长2秒的时间进行检索，但事实并非如此。但下面的查询工作正常，检索结果的时间不到1秒（

不同之处在于，ASC不工作，DESC工作

）

同样，根据模式，集群键的默认顺序是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 = 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;

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

每个密钥1将有大约1000000个密钥2

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

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

进行扣带的逻辑方法是使用时间元素。我看到你的最后一把钥匙是一个时间戳。我不知道一天中每个

key_1

可以得到多少行，但假设你每个月只能得到几千行。在这种情况下，我将创建一个额外的分区键

month\u 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;

从my_test.my_表中选择*
其中键_1=101，月_桶='201603'
键_2>1，键_2<132646限值1；

---

再说一次，月结扣只是一个例子。但基本上，您需要找到一个附加列来对数据进行分区。

在重新启动所有3台cassandra服务器后，问题得到了解决。我不知道到底是什么惹麻烦。。由于它在生产中，服务器无法获得确切的根本原因。

尝试打开CQLSH跟踪，看看它告诉您什么：CQLSH>从my_test.my_表中选择*，其中键1=101按键2排序ASC限制500；code=1200[协调器节点在等待副本节点的响应时超时]message=“操作超时-仅接收到0个响应。”info={'received_responses'：0，'data_retrieved'：False，'required_responses'：1，'consistency'：1}语句跟踪未在10秒内完成seconds@bechbd我想如果查询成功，查询跟踪将给出结果。可能是无关的，但避免使用新的滴答模型之前的.0版本。2.1.0是2.1中最不稳定的，升级到2.1.13将是一个巨大的改进（大量的错误修复）。顺便说一句-+1是受欢迎的。从学术角度来看，这个问题是纯金的。我不记得还有其他人做过类似的事情，这是一个很好的例子，可以在将来链接。虽然这是一个不做什么的例子，但这些同样重要（如果不是更重要的话）。是的，我当然知道，但当这个问题发生时，表只有大约39000条记录，但最初它有50000条记录，11000条记录因某些业务逻辑而被删除。这是我在问题中提到的。因此，它有50000条记录和一些墓碑排。所以它应该像我期望的那样工作。同样，默认的集群顺序是ASC，所以在我的例子中，ASC应该比DESC工作得更快（原因：非常大的宽行…），但在我的例子中，它是相反的。我在问题中也提到了这一点。@JayaAnanthram“所以它应该像我期望的那样工作。”但事实并非如此。听着，我知道没有人喜欢别人告诉他们，在他们投入生产后，他们需要完全释放并重新加载数据以进行模型更改。但是您的行太宽了，而且确实没有快速解决方法。继续用cassandra stress测试这两个模型，它不仅会起作用，而且我敢打赌，使用“桶”比使用非常宽的行时，你的op/s会高得多。是的，我同意你的看法。我知道行太宽会对性能产生影响。当我设计模式时，我提出了一个关于宽行性能在一年前下降的问题（请参阅最后一条评论），您回答了这个问题，您的回答是“cassandra升级将修复它”。尽管选择宽行模式的原因是，我的业务需求是纯数据页面概念，它具有分页视图（逐页、最后一页、第一页）、计数、搜索。对于这些，我无法按照您在示例中所示进行设计。所以我们在某种程度上进行了广泛的讨论。如果数据接触的范围太广，那么我们需要在单独的分区中进行处理。

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;