Question

使用的数据库：Datastax cassandra community 3.0.9
群集：3 x（8核15GB AWS c4.2xlarge），300GB io1和3000iops。
写入一致性：仲裁，读取一致性：ONE Replication 因素：3

问题：我为我们的服务器加载了50,000个用户，每个用户最初有1000条记录，过了一段时间后，每个用户又添加了20条记录。我想获取稍后添加的20条额外记录（查询：select * from table where userID='xyz' and timestamp > 123）此处user_id和timestamp是主键的一部分。当我只有50,000个用户时它工作正常。但是一旦我添加了另外20GB的虚拟数据，相同查询的性能，即为50,000个用户获取20个额外记录的性能显着下降。随着数据的增加，读取性能会下降。据我所知，这不应该发生，因为密钥被缓存，其他数据无关紧要。

可能的原因是什么？ CPU和RAM利用率可以忽略不计，我无法找出导致查询时间增加的原因。我已经尝试将压缩策略更改为“LeveledCompaction”，但这也不起作用。

编辑1

编辑2 堆大小为8GB。添加20GB数据的方式类似于添加初始4GB数据的方式（50k用户ID），这样做是为了模拟真实场景。 20GB数据的“userID”和“timestamp”是不同的，并且是随机生成的。场景是我有50k个用户ID和1020行，其中首先添加了1000行，然后在一些时间戳后添加了另外20行，我正在获取这20条消息。如果只有50k的userID存在但是一旦我有更多的userID（额外的20GB）并且我尝试获取相同的20条消息（对于最初的50k用户ID），它工作正常，性能降低。

编辑3 cassandra.yaml

Answer 1

随着数据的增加，读取性能会下降。

只有在同一分区中添加大量记录时才会发生这种情况。

根据我的理解，您的表格可能如下：

CREATE TABLE tbl (
    userID text,
    timestamp timestamp,
    ....
    PRIMARY KEY (userID, timestamp)
);

当单个分区中的数据量被“绑定”时，此模型就足够了。（例如，您在一个分区中最多有10k行）。原因是coordinator在处理＆＃34;未绑定＆＃34;时会遇到很大的压力。查询（这就是为什么非常大的分区是一个很大的禁忌）。

那＆＃34;规则＆＃34;很容易被忽视，最终的结果是整体放缓，这可以简单地解释为：C *需要读取越来越多的数据（并且它将只从一个节点读取）以满足您的查询，保持忙碌协调器，并减慢整个群集。数据增长通常意味着查询响应缓慢，并且在某个阈值之后出现臭名昭着的读取超时错误。

有人说，看看你的DISK使用是否正常＆＃34;会很有趣。或者出了什么问题。点击dstat -lrvn来监控您的服务器。

最后一个提示：取决于您使用SELECT *查询的字段数量以及检索到的数据量，由SSD提供服务可能不是什么大问题因为您未能利用IOPS您的SSD。在这种情况下，更喜欢普通的硬盘驱动器可以降低解决方案的成本，而且你不会受到任何惩罚。

当我们增加节点上的数据时，Cassandra读取性能会下降

1 个答案: