Question

在Cassandra中，我想更新一行，以便在处理完行后删除一些敏感数据。一行有以下过程。

插入记录
处理记录（更新）
将行设置为已处理并从行的一列中删除敏感数据

我知道更新实际上并没有通过Cassandra的设计更新磁盘上的数据。但是，我想确保在不太长的时间后，数据实际上已从磁盘中删除。没有显式地从该表中删除行（使用CQL语句）只插入和更新语句。

根据我的理解，我必须使用相对较短的gc_grace_period，例如10分钟。

你能告诉我这个配置是否有用吗？这种策略有什么影响？

我正在使用Cassandra 3.11.1，该表的TTL为一天。表中每天插入大约100k到1M的记录。

Answer 1

让我回答这两部分问题： -

gc_grace_seconds是Cassandra在清理具有墓碑数据的SSTable（由TTL / Deletes引起）之前必须等待的时间。所以在这种情况下，表格的TTL为1天，默认情况下gc_grace_seconds为864000（秒）= 10天。这意味着在清理之前，一天到期的数据会等待另外10天（默认情况下）。

默认gc_grace_seconds为高的原因是为了确保在显式删除期间，如果群集中的任何节点关闭，删除（逻辑删除）会在节点重新启动时传播。换句话说，以避免僵尸数据。

在你的情况下，由于没有任何明确的删除和只有墓碑，因此gc_grace_seconds值较小的安全性为90000（25小时）。

另一个风险更高的选择是，如果保证应用程序永远不会执行显式删除并仅依赖于TTL，则将gc_grace_seconds设置为零。将其设置为零具有系统中没有墓碑的优点。一旦TTL

，数据就会被清除

问题的第二部分：

为了在处理后10分钟内使列过期，我们可以如下设置列级TTL。下面我建议使用更短的gc_grace_seconds和TWCS，这将有助于在10 + 1分钟内逐出这一行并且不会导致墓碑压力。

更新CQL以设置列级别TTL

UPDATE test USING TTL 600 
  SET status = 'PROCESSED' 
  WHERE primary_key = ? ;

此外，关于表压缩策略： -

我假设正在按顺序处理行（或者换句话说，此表被视为队列）。处理这种情况的更简洁方法是使用“时间窗口压缩策略”。通常建议将TimeWindow切片的数量保持在50片以下。

命令是

CREATE TABLE test (
........
) WITH 
    AND gc_grace_seconds = 60
    AND default_time_to_live = 86400
    AND compaction = {'compaction_window_size': '30', 
                      'compaction_window_unit': 'MINUTES', 
                      'class': 'org.apache.cassandra.db.compaction.TimeWindowCompactionStrategy'}

此设置将为我们提供以下保证：

超过30分钟的数据停止压缩，降低I / O消耗。如果压缩是最新的，那么在30分钟时间范围内定位行的查询将主要达到有限数量的SSTable
使用TTL插入，通过删除文件来清除墓碑（在这种情况下，在原始写入后1天和1分钟后不久）
通过提示或修复从原始时间窗口发出的数据仅使用当前窗口的SSTable进行压缩，防止写入放大
磁盘上的最大压缩开销是最后创建的存储桶的50％
磁盘空间使用量增长很容易预测

关于TWCS的精彩读物。

确保在10分钟后删除以前版本的单元格

1 个答案: