历史上检查 cassandra 中的表大小答案

【问题标题】：Check table size in cassandra historically历史上检查 cassandra 中的表大小
【发布时间】：2017-11-03 02:17:04
【问题描述】：

我有一个包含 TB 数据的 Cassandra 表（Cassandra 版本是 2.0），这是架构的样子

"my_table" (
  key ascii,
  timestamp bigint,
  value blob,
  PRIMARY KEY ((key), timestamp)
)

我想删除一些数据，但在想估计它会回收多少磁盘空间之前。

不幸的是，来自 JMX 指标的统计信息仅在过去两周内可用，所以这不是很有用。

有没有办法检查某些数据集使用了多少空间（例如时间戳

我还想知道是否有办法检查查询结果集的大小，以便我可以执行select * from my_table where timestamp < 1000 之类的操作并查看结果占用了多少字节。

【问题讨论】：

标签： cassandra cassandra-2.0

【解决方案1】：

没有从数据中查看磁盘大小的机制，它可能与请求的协调器相距甚远，并且存在影响它的级别，例如压缩和多个 sstable，这会使其变得困难。

还要注意，发出删除操作不会立即减少磁盘空间。 C* 不会删除数据，sstables 是不可变的，无法更改。相反，它会写入一个墓碑条目，在 gc_grace_seconds 之后将消失。当 sstables 被合并时，墓碑 + 数据将合并为墓碑。在超过 gc_grace_seconds 之后，tombstone 将不再在压缩期间被复制。

gc_grace 是为了防止在分布式系统中丢失删除，因为在修复之前（应该每周安排一次），并不能绝对保证所有副本都看到了删除。如果副本没有看到删除并且您删除了墓碑，则数据可以恢复。

【讨论】：

【解决方案2】：

不，不是。

使用sstablemetadata，您可以在mc-####-big-data.db 文件中找到墓碑删除时间、最小时间戳和最大时间戳。

此外，如果您的硬盘空间不足，请考虑nodetool cleanup、nodetool clearsnapshot，最后考虑nodetool repair。

【讨论】：

请注意，nodetool clearsnapshot 可能会删除您的“备份”。这些是在您截断和删除表时创建的，以便您可以恢复。因此，如果您正在寻找硬盘空间，可以安全删除它们。