Question

对于我的测试服务器，我没有复制Cassandra 2.1.6设置：

CREATE KEYSPACE v2 WITH replication =
{'class': 'SimpleStrategy', 'replication_factor': '1'} AND durable_writes = false;

CREATE TABLE v2.tiles (
    zoom int,
    idx int,
    tile blob,
    PRIMARY KEY (zoom, idx)
)

对于每个缩放值，可能有数千万个小项目。对于zoom = 11，第一个idx大约在100352.当我需要遍历所有项目时，我总是看到特定存储情况的超时错误：

cqlsh:v2> select zoom,idx from tiles where zoom=11 limit 10;
ReadTimeout: code=1200 [Coordinator node timed out waiting for replica nodes' responses] message="Operation timed out - received only 0 responses." info={'received_responses': 0, 'required_responses': 1, 'consistency': 'ONE'}

我得到了相同的错误＆＃34; zoom = 11和idx＆gt; 1000＆＃34 ;. 对于更接近现有项目的idx值，它会给出正确的结果：

cqlsh:v2> select zoom,idx from tiles where zoom=11 and idx > 100000 limit 10;
 zoom | idx
------+--------
   11 | 100352
...

当idx与极高值比较时，它还显示正确的空结果：

cqlsh:v2> select zoom,idx from tiles where zoom=11 and idx > 1000000 limit 10;                                       
 zoom | idx | tile
------+-----+------
(0 rows)

Answer 1

对于每个缩放值，可能有数千万个小项目。对于zoom = 11，第一个idx在100352左右。当我需要迭代所有项目时，我总是看到特定存储情况的超时错误。

这听起来像是一排广泛的问题。如果单个分区有多个项目（放大你的情况），它可能会为cassandra中的读取带来问题。一般来说，将分区保持在＆lt;是一个很好的经验法则。 100MB大小，你认为你的分区可能很大吗？平均有多少字节是'tile'列？例如，idx是一个4字节的int，并假设blob大小为96字节，每行给出100个字节并忽略任何开销~1,048,576行将等于100MB

虽然你的页面大小很小，但cassandra最终还是会在磁盘上读取数据及其索引。似乎发生的事情是您的C *节点无法读取read_request_timeout_in_ms内的数据（默认值为10秒）。如果您的查询有效，他们会花多长时间？

可能值得启用跟踪（在cqlsh会话中'跟踪'）以帮助了解查询成功时所花费的时间。您还可以考虑在调试时将read_request_timeout_in_ms增加到某个任意大的值。可以找到关于跟踪的好文章here。

如果您发现行太宽，可以考虑进一步分区数据，例如白天：

CREATE TABLE v2.tiles (
    zoom int,
    day timestamp,
    idx int,
    tile blob,
    PRIMARY KEY ((zoom, day), idx)
)

虽然不太了解您的数据模型，但时间可能不是一种好的分区方式。

Answer 2

就我而言，此错误已解决，增加了“cassandra.yaml”文件中参数“range_request_timeout_in_ms”的时间。默认情况下，此参数的值为10000毫秒。

查询现有数据时的Cassandra ReadTimeout

2 个答案: