Cassandra：维护

我对Cassandra缺乏经验，但是我对基于SQL的关系数据库有一些经验。

部署后，我一直无法找到有关如何维护Cassandra的最佳实践信息。是否需要VACUUM数据库？我应该认为读/写负载会导致存储碎片化。

或更笼统地说：维护Cassandra生产部署的最佳实践是什么？必须定期执行哪些操作才能维护系统的运行状况？操作手册实际上没有讨论这方面。

谢谢。

通常，精心设计的集群可以在YEARS居住，而不会受到影响。我有运行了数年的集群。但是，这里有一些准则：

监视非常重要：

1）监视延迟。使用opscenter或您喜欢的指标工具来跟踪延迟。延迟上升可能是出现问题的迹象，包括GC暂停（读取工作负载比写入工作负载更常见），稳定问题等。

2）监视稳定计数。如果超出压缩范围，SSTable计数将增加（每个sstable恰好写入一次-通过压缩将旧的sstables合并为新的sstables来处理删除）。

3）监视节点状态变化（向上/向下等）。如果您看到节点震荡，请进行调查，因为这不正常。

4）跟踪磁盘使用情况-传统上，您需要保持在50％以下（尤其是在使用STCS压缩时）。

您应该定期做一些不应该做的基本事情：

1）不要显式运行nodetool compact。您提到您已经做到了这一点，虽然它不是致命的，但它确实会创建非常大的sstable，因此不太可能参与进一步的压缩。您不一定需要继续运行它，但是有时它可能有助于摆脱已删除/覆盖的数据。

2）nodetool repair通常建议gc_grace_seconds（默认为10天）。在某些工作负载中，这并不那么重要-您需要修复的最大原因是确保删除标记（tombstones）在过期之前被传输（它们的存在gc_grace_seconds，如果删除发生时节点处于关闭状态，则数据可能会恢复生命无需维修！）。如果您不发布删除，并且以足够的一致性级别进行查询（例如，在QUORUM上进行读取和写入），则实际上可以过着无需修复的生活。

3）如果要维修，请考虑使用增量维修，并一次维修小范围。

4）压缩策略很重要-很多。STCS非常适合写入，LCS非常适合读取。DTCS有一些怪癖。

5）数据模型很重要-就像RDBMS / SQL环境遇到麻烦一样，因为未索引的查询会击中大型表，Cassandra的行/分区非常大可能会出现问题。

6）快照很便宜。非常便宜。几乎是即时的，只是硬链接，它们几乎立即不占用磁盘空间。在升级版本（尤其是主要版本）之前，请使用快照。

7）小心删除。如＃2所示，delete在磁盘上创建更多数据，并且不会将其释放给AT LEAST gc_grace_seconds。

当所有其他方法都失败时：

我看过一些文章，建议产品中的Cassandra需要专门的负责人来管理任何大小的集群-我不知道这一定是真的，但是如果您担心的话，您可能想聘请第三方顾问（TheLastPickle，Pythian ）或签订支持合同（Datastax），让您高枕无忧。

根据Cassandra维修文档，nodetool repair应在以下情况下运行：

• 作为最佳实践，您应该每周安排维修一次。注意：如果从未发生删除，则仍应安排定期维修。请注意，将列设置为null表示删除。
• 在节点恢复期间。例如，在发生故障后将节点带回群集中时。
• 在包含不经常读取的数据的节点上。
• 在已关闭的节点上更新数据。

我应该认为读/写负载会导致存储碎片化。

Cassandra中的数据不会像您所想的那样“碎片化”。但是，删除操作确实会触发墓碑的放置，并且正常的压缩过程会消除墓碑。

我现在了解到压缩非常重要并且可以自动运行

正确。DataStax代表告诉我，一旦compact手动运行，就始终必须手动运行。原因是压缩是通过将键空间中的所有现有SSTABLES“压缩”到单个SSTABLE文件中而起作用的。您在该SSTABLE文件中可能有一些列族，这些列族很小，并且要花很长时间才能超出压缩阈值，因此再次运行自动压缩的可能性非常低。

从本质上讲，请确保安排一个regularized nodetool repair，never run nodetool compact和永不执行备份策略（快照，增量备份或二者兼有）。