问题标签 [data-compaction]

我正在寻找具有以下特征的数据的压缩策略

1. 我们不需要 60-90 天后的数据。在极端情况下可能需要 180 天。
2. 理想情况下，插入发生而更新永远不会发生，但期望导致更新的重复事件是现实的。
3. 如果您考虑一下，它是间接的时间序列数据，首先发生的事件将首先被存储，一旦事件被存储，它几乎永远不会被修改，除非发布重复的事件。

哪种策略最适合这种情况？

我有一个非常大的数据库，其中包含一些 GB 的数据。当我尝试压缩时，我需要花费超过 12 个小时。有没有其他方法可以删除旧版本？_revs_limit 对此有帮助吗？我可以看到所有数据库的 revs 限制都设置为 1000。这是否意味着即使在压缩之后，couchdb 上仍会保留 1000 个修订？

我已经做了配置：habse.offpeak.end.hour:22 ,hbase.offpeak.start.hour: 18.hbase.hregion.majorcompaction: 86400000. 但是hbase仍然在随机时间做major compaction ,like:9:00 , 13:55 以此类推。你能告诉我如何配置 hbase 在非高峰时间进行主要压缩。

我正在运行cqlsh 版本 5.0.1，有一个 6 节点集群，最近我在使用sizeTieredCompaction策略以释放一些磁盘空间的表中进行了主要数据清理，但没有发生，我的问题面临的是创建了很多墓碑，我的 sstables 大小不均匀，因此它们没有被压缩我也尝试使用nodetool compact --user-defined选项手动压缩 sstables，但我的nodetool 版本是 3.0.15，它没有支持它，是否有其他方法来压缩 sstables，因为我不想在整个表上运行压缩，因为这可能非常不可预测，下面我附上了我的 sstables 和 cfstats。

稳定：

cfstats：

请建议一些使用它可以释放一些磁盘空间的东西，因为数据每天都在增长并且不可能增加磁盘。