Cassandra - 在一列中使用大量数据进行大量读取和适度更新 - 性能问题答案

【问题标题】：Cassandra - Heavy reads and moderate updates with large data in one column - Performance issueCassandra - 在一列中使用大量数据进行大量读取和适度更新 - 性能问题
【发布时间】：2019-04-14 08:56:11
【问题描述】：

我有初始数据，当加载到 Cassandra 中时，显示的总大小为 3.5GB

之后，我进行重读（例如每秒 10k 次读取）和适度更新（例如每秒 1k 次更新），但在更新中，列大小之一被更新为更大的大小，使得行的总大小从 1k 增加到几乎 5k

存储的问题是节点的大小不断增加，甚至达到 300GB 并且只会上升

Compaction 正在运行，读取性能不断下降。 Cassandra 在将行从 2k 更新到 5k 时遇到问题吗？

这是一台 AWS 30GB RAM 机器，具有 16 个处理器和 1TB SSD，已激活 32k IOPS。压缩吞吐量设置为 256，压缩器设置为 8，读取的偏差仍在继续，SS 表的大小仍在增加

在 1 天的时间里，每秒读取次数从每秒 22k 下降到每秒 5k

请告诉我配置有什么问题

【问题讨论】：

在更新时你是否重复更新同一行？您是更新整行还是仅更新一列？您能在这里提供您的架构和查询吗？
首先预填充了 3000 万行，然后从初始大小 2k 到 5k 依次逐一更新。所有值都是随机的，尤其是与行中所有列相比大小最大的那一列
能否包含现有架构（包括压缩设置）和 tablestats 输出？
您使用哪种压缩策略？您能否将“nodetool compactionstats”的输出以及 ssh 发布到节点并检查数据目录中存在多少 SSTable 文件？另外，您使用的是哪个版本的 Cassandra？
分级压缩挂起任务：582 - t.cc: 299 - t.ss: 283

标签： cassandra datastax

【解决方案1】：

基本上观察挂起的压缩，如果它们增加，首先开始使用 nodetool 增加压缩吞吐量。

如果您看到挂起的压缩已开始减少，则从该配置中将其增加一点作为缓冲区。

如果你使用 CPU 在操作 + 压缩期间没有过载，你也可以少量增加并发压缩器

【讨论】：