在 cassandra 上禁用压缩和 gc 优雅答案

【问题标题】：disable compaction and gc grace on cassandra在 cassandra 上禁用压缩和 gc 优雅
【发布时间】：2015-03-05 16:11:48
【问题描述】：

我总是插入数据 PRIMARY KEY ((site_name,date),time,id)，而 site_name 和 date 可以是相同的时间，这是一个驯服的字段，而 id(uuid) 是不同的。所以我总是添加新数据。使用 TTL 插入数据（当前为 3 天）。所以我不删除或更新我可以禁用压缩吗？考虑到 TTL 就在那里。会不会有什么影响。另外，由于没有删除记录，我可以禁用 gc_grace 时间吗？我想尽可能减少服务器的负载。如果有人可以提供帮助，非常感谢？

【问题讨论】：

标签： cassandra cql cassandra-2.0 cqlsh

【解决方案1】：

您可以将 gc grace 设置为 0，但不能关闭压缩。如果您从不删除或更新，我认为您可以关闭压缩。

编辑：从 2.0 起，C* 中的优化正是针对这种情况： https://issues.apache.org/jira/browse/CASSANDRA-4917

关于 TTL、墓碑和 GC Grace http://mail-archives.apache.org/mod_mbox/cassandra-user/201307.mbox/%3CCALY91SNy=cxvcGJh6Cp171GnyXv+EURe4uadso1Kgb4AyFo09g@mail.gmail.com%3E

【讨论】：

所以将 gc grace 设置为 0 会提高我在当前情况下的阅读能力吗？这就是我希望实现的目标。
您可以关闭自动压缩，但在这种情况下并没有真正的帮助。 TTL 确实会创建墓碑，因此除非它是单节点集群，否则关闭宽限期并不是一个好主意。
它是一个八节点集群。我只关心每天的网站总数。即使创建了僵尸数据，它也不会影响我的读取，因为我没有读取旧日期的数据。压实也会影响任何东西。因为我没有更新任何东西。总是插入。
这将改善阅读，因为您将有更少的墓碑躺在周围需要更少的 SSTable 搜索。了解如何从“nodetool cfhistograms”读取结果。检查“每次读取的 SSTables”统计信息，它描述了一次读取必须经过多少个 sstables。
虽然压缩，到目前为止还不是一个非常聪明的任务，特别是在我的情况下，因为我的硬盘驱动器已经在流淌着数据，它是没用的。我希望在未来的版本中优化压缩

【解决方案2】：

TTL 创建墓碑。因此，需要压实。如果您的数据是时间序列数据，您可以考虑使用新的日期分层压缩：http://www.datastax.com/dev/blog/datetieredcompactionstrategy。

如果您使用 TTL 并将宽限设置为 0，除非您的集群是单节点集群，否则您就是在自找麻烦。恩典是收集墓碑之前等待的时间。如果为 0，则不会等待。这听起来不错，但实际上，这意味着“删除”可能不会在整个集群中传播，并且被删除的数据可能会重新出现（因为其他节点可能有它，最后一个现值将“获胜”） .这种类型的数据称为僵尸数据。僵尸很糟糕。不要喂僵尸。

您可以禁用自动压缩：http://www.datastax.com/documentation/cassandra/2.1/cassandra/tools/toolsDisableAutoCompaction.html。但同样，我怀疑你会从中受益匪浅。再次查看日期分层压缩。

最后，我没有对这个问题投反对票。这是一个真实的问题，其他人可能也有类似的问题。

【讨论】：

我一定会研究 datetiercompaction 策略。如果我将 Grace 设置为 0，那么只会创建僵尸数据。就我而言，我不介意数据是否旧且仍然存在。我只关心日常站点（这就是为什么复合主键中的日期）。我只阅读数据（该日期的网站数量）。因此，在我的情况下，设置宽限期是否有益（我可以每周运行一次节点修复工具）。我也想试验一下密钥缓存。更改其大小等。检查性能是否提高或降低的最佳方法是什么。非常感谢。
僵尸不会被删除。重生的数据最终可能会作为带有修复的新数据传播。压缩不仅仅是删除。对于许多存储文件，您的读取可能需要访问其中的许多文件。压实减少了这种影响。所以没有它，读取可能会变慢。
增加密钥缓存会有所帮助，增加布隆过滤器也可能会有所帮助。您可以使用压力工具并比较数字。我相信最新的压力工具允许您指定自己的架构等。
ashic：如果集群中所有行的 TTL 相同，并且插入后数据没有被触及，那么所有节点都会同时达到 TTL，因此不需要宽限期。请记住 - afaik grace 0 实际上确实创建了墓碑，只是它们总是在第一次压缩时被删除。 SSTables 总是不可变的。
是的……事实上，如果 TTL > gc grace，那么根本不会创建墓碑。 issues.apache.org/jira/browse/CASSANDRA-4917 但是，压缩仍然是回收磁盘空间所必需的，因为正如您所说，SSTables 是不可变的。

【解决方案3】：

您可以分别永久禁用表（列族）上的自动压缩，像这样 (cql)

alter table <tablename> with compaction = { 'class':'CompactionStrategy', 'enabled':'false'}

enabled:false 永久禁用该表上的自动压缩，但您可以随时使用“nodetool compact”命令进行手动压缩

【讨论】：