在 cassandra 中获取 partitionID 的所有记录会导致 RPC 超时答案

【问题标题】：Fetching all the records for a partitionID in cassandra gives RPC timeout在 cassandra 中获取 partitionID 的所有记录会导致 RPC 超时
【发布时间】：2013-03-07 17:49:10
【问题描述】：

我正在使用 Cassandra 1.2.1、复合键并尝试获取特定 partitionID 的所有记录。以下是我正在使用的架构：

时间戳
设备 ID
数据传输
位置 ID
设备所有者

主键是一个复合键：(TimeStamp, Device ID)。因此时间戳是分区键。每条记录为 70-80 字节。

有 1000 个不同的时间戳，每个时间戳都有 500K 设备 ID。所以有 5 亿条记录，我想获取特定时间戳的所有记录。类似于：

从 TimeStamp = '..' 的架构中选择 *

我的理解是这个查询应该能够快速获取所有记录，因为相关行都存储在连续的磁盘位置，这意味着很少有磁盘搜索会给我们结果。过滤器在 TimeStamp 上，这意味着查询只会命中一个节点。此外，数据总量为 500K * 80 字节 ~ 40 MB，也不算多。但是，当我使用 CQL (3) 或 Astyanax 运行它时，我会遇到 RPC 超时。

我对 partitionID 的所有记录都在连续磁盘位置的理解是错误的吗？批量获取此类数据的正确方法应该是什么？

【问题讨论】：

标签： cassandra

【解决方案1】：

最终这些列在磁盘上会彼此靠近，因为它们在同一行中。但是在压缩完成之前（即假设你不运行 nodetool compact），它们不会。但它们应该被分成几个 SSTable。

但是，较慢的可能是 CPU 反序列化、比较其他副本的结果并序列化回客户端。我怀疑你可以在 rpc_timeout（默认为 10 秒）内对 500k 个对象执行此操作。

为此，您应该对结果进行分页。

对于您的第一个查询，请执行

SELECT * from schema where TimeStamp = '..' limit 1000

然后取最后一个设备ID，最后调用它：

SELECT 'last'..'' from schema where TimeStamp = '..' limit 1000

直到响应中的列数少于 1000。

【讨论】：

Richard，我没有复制，所以比较其他副本的结果应该不会减慢速度。对吧？您能否详细说明反序列化的含义？您是指通过处理数据库的输出并在网络上发送记录（发送到客户端）而引入的延迟？我已经运行了 compact 命令，如果有帮助会更新。您是否知道我可以从以下事实中受益的任何其他方式：特定 partitionID 的数据将按顺序存储在 DB 中，以便我可以以最少的磁盘查找来获取它？谢谢。
如果您没有复制，这将使其更快。通过反序列化，我的意思是 Cassandra 必须从磁盘读取数据并从中构造 Java 对象。在这种情况下，这可能是您的瓶颈 - 您可以在运行查询时通过监视服务器来确认。是否受 CPU 限制（使用顶部）？它做了多少 I/O（使用 iostat）？
你所说的可能意味着无论我做什么（紧凑等），我都会因为Java反序列化而遇到瓶颈？如果我错了，请纠正我。有什么方法可以改进吗？我的另一个输入是使用查询 Select count() from schema where TimeStamp = '..' 也会导致 RPC 超时。现在如果反序列化是罪魁祸首，那不应该发生，对吧？你有什么想法为什么 count() 会这么慢，如果压缩会有帮助？另一个输入是我的数据库中只有插入，从未删除过条目。
可能，是的。不过，您应该通过一些监控来确认。 Cassandra 的查询协议专为小型查询而设计——返回 500k 结果对于 Cassandra 来说很多。 'SELECT count' 与 'SELECT *' 花费的时间几乎相同 - 在 Cassandra 内部，它执行 'SELECT *' 查询并只计算结果。解决这些问题的标准方法是在我的回答中使用分页。
谢谢理查德。我会试一试，并更新结果。任何有关如何使用 Astyanax 进行分页的指示都会有所帮助。