Cassandra 磁盘空间开销

Posted 2023-04-18

【中文标题】Cassandra 磁盘空间开销

【英文标题】：Cassandra disk space overhead

【发布时间】：2015-04-07 06:54:39

【问题描述】：

我们在 AWS 上跨 3 个可用区的单个数据中心运行 RF=3 的 6 节点 Cassandra 2.0.11 集群

我们的平均数据大小约为 110GB，每个节点有 2 个 80GB 磁盘，raid0 以创建单个 160GB 磁盘。

每当发生修复或后续压缩时，我们开始看到磁盘被填满，并且不再能够重新平衡环。

是时候水平扩展并从 6 个节点移动到 9 个节点了吗？

160GB 中的 50GB 似乎是“正常” cassandra 操作所需的大量开销。

【问题讨论】：

我想补充一点，我们已经在使用 LCS 并且检查过我们没有任何快照。我们发现有帮助的一件事是将 compaction_throughput_mb_per_sec 从 16 MB/s 提高到 32 MB/s。现在环很安静，因为压实已经完成，我们还没有进行任何修复操作。我们决定尝试从 6 个节点扩展到 9 个节点。

【参考方案1】：

如果可以，请获取更多磁盘空间。 否则考虑使用分级压缩，以防磁盘空间不足并且只有小到中等的写入负载。与大小累压缩相比，LCS 可以在压缩期间节省大量磁盘空间。 还要检查是否可以删除一些旧快照。

【参考方案2】：

首先，找出导致磁盘填满的根本原因。

从您写的内容来看，在我看来，集群上的负载太高导致压缩落后。这反过来又会导致磁盘被填满。

检查 nodetool tpstats 以查看是否有压缩积压，并检查 Columnfamilies 中有多少 sstable。如果是这种情况，要么水平扩展以处理负载，要么调整当前集群，使其能够处理正在推送的负载。

原因也可能源于数据驱动器的巨大压缩。我假设您使用大小分层压缩策略。这样做的开销始终是当前数据的 50%。由于大压缩可以暂时添加那么多数据。

一个选项可能是切换到分级压缩策略，因为这只需要 10% 的开销。但请注意，LCS 在磁盘上的难度要大得多。