【问题标题】:Cassandra coordinator read timeout count operation vs select allCassandra 协调器读取超时计数操作 vs 全选
【发布时间】:2018-06-22 08:11:40
【问题描述】:

我有 4 个节点 dse 5.1.2 Cassandra 集群,平均每个节点有 3 GB 数据。我正在尝试查询该数据。我知道我不应该执行以下查询,因为它对 cassandra 有不良影响。但我观察到的是

select * 有效,但 select count(*) 失败

在同一个表上,协调器超时。当两者在读取时在后台执行相同的操作时,为什么会有所不同。 我的集群已 100% 修复,并且在该表中未找到任何墓碑。我还在 cqlsh 命令中增加了读取请求超时。

我收到以下查询错误

select count(*) from xxx.xxxx;

ReadTimeout: Error from server: 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'}

【问题讨论】:

  • 打算以编程方式或一次性获取计数?
  • 我有 spark 代码来获取计数。但仍然不明白为什么会在 cqlsh 中发生这种情况。
  • Cassandra 或任何分布式系统都不是为运行需要每个分区中的每一行都响应的查询而设计的。所以 count(*) 工作可能会受到打击。如果您需要计数的近似值,cassandra 使用“nodetool cfstats”命令或通过 JMX 计数器 EstimatedColumnCountHistogram 公开它

标签: cassandra datastax-enterprise datastax-java-driver cassandra-3.0 cqlsh


【解决方案1】:

如果您通过cqlsh 运行这些命令,那么它们并不完全相同。

cqlsh 的默认限制为 10000 行,因此除非您更改了该限制,否则您将使用 select * 获得所有限制。

select count(*) 将对所有节点进行全表扫描以获取计数,因此超时。

【讨论】:

  • 但是以前当我在 cqlsh 中增加超时时,我在不同的集群中获得了更多数据大小的计数没有任何问题,这些集群具有不同的 aws 实例类型。这可能是一个原因吗?
猜你喜欢
  • 2017-01-08
  • 2016-11-08
  • 2015-05-26
  • 2014-08-06
  • 2017-08-21
  • 2015-08-25
  • 2015-12-03
  • 2019-02-01
相关资源
最近更新 更多