Cassandra 是一款出色的 NoSQL 产品。它为设计的查询提供近乎实时的性能，并通过使用最终一致的范例实现线性规模增长的高可用性。
在这篇文章中，我们将重点介绍这款出色产品的一些最佳实践。
您需要多少个节点？
节点数量应该是奇数，以便在停机/网络中断期间支持投票。
最小数量应为 5，因为较小的数量（例如 3）会导致节点故障期间机器承受较高压力（本例中复制因子为 2，每个节点将必须读取 50% 的数据并写入50% 的数据）。当复制因子选择为3时，每个节点将需要读取15%的数据并写入15%的数据。因此，恢复速度会快得多，而且性能和可用性也更有可能不受影响。
您的 C* 实例应该有多大？
与任何其他数据存储一样，C* 喜欢快速磁盘 (SSD) — 尽管它的 SSTable 和 INSERT 仅架构与数据一样多的内存。特别是，每个节点的 RAM 应为 32GB 至 512GB（生产中不少于 8GB，开发中不少于 4GB）。这是一个常见问题，因为 C* 是用 Java 编写的。
2023 年容器将会发生什么
DZone 的 2023 年容器趋势报告将探讨容器的当前状态、全球容器化战略的主要趋势和进展，以及用于实现软件架构现代化的建设性内容。
C*也是CPU密集型，建议16核（开发时不少于2核）。
维修和更换策略
nodetool 可能是 C* 集群上最常见的任务之一。
您可以在单个节点或整个集群上运行它。
gc_grace_seconds 修复应在达到删除墓碑的时间（默认 10 天）之前运行。
如果您坚持使用gc_grace_seconds.
您可以减少这个数字，但这会影响您的备份和恢复策略（请参阅有关 使用提示从故障中恢复的详细信息）。
您可以使用以下标志来优化修复过程：
-seq：一个接一个地修复令牌：更慢、更安全。
-local：仅在本地数据中心运行，以避免在任何情况下都发生停机。
-parallel：最快模式 — 在所有数据中心上并行运行。
-j：节点上并行作业的数量（1-4）；使用更多线程会给节点带来压力，但有助于更快地结束任务。
我们建议根据峰的高度和数据的敏感性来选择策略。如果您的系统 24/7 具有相同的流量水平，请考虑缓慢且按顺序执行操作。高峰越高，非高峰时段对系统施加的压力就越大。
备份策略
您可以采用多种备份策略：
利用您的存储/云存储快照功能。
使用 C*nodetool 快照命令。这与您的存储功能非常相似，但只能备份数据而不是整个机器。
使用可实现时间点恢复的 C* 增量备份。这个过程不是日常过程，而是需要一直复制和管理小文件
混合使用 C* 快照和增量备份可最大限度地缩短恢复时间，同时保留时间点恢复选项。
快照和提交日志：复杂的恢复过程，支持时间点恢复，因为您需要回复提交日志。
如果您的数据不重要，如果您想最大限度地降低运营成本，或者如果在必须进行时间点恢复时混合使用 C* 快照和增量备份，我们建议您使用每日快照。
监控
有几种方法可供选择。
商业软件
DataStax OpsCenter 解决方案：与几乎所有其他 OSS 一样，DataStax 提供 C* 的商业版本以及付费管理和监控解决方案
商业服务包括：
NewRelic：提供 C* 插件作为其平台的一部分
DataDog ：对应该监视的内容有一个很好的提示 。
使用具有共同集成的开源：
Graphite、 Grafana或 Prometheus：这 3 种工具可以一起工作，也可以单独工作，并与时间序列和相关指标集成。
提供社区插件的旧式Nagios和Zabbix
如果您选择 DIY 解决方案，您可以在商业产品和服务以及以下资源中找到一些提示：
基本监控阈值。
Nagios 开箱即用的插件，可以从中提取阈值。
例如：
堆使用率：85%（警告），95%（错误）。
GC ConcurrentMarkSwee p：9（警告），15 错误。
我们的建议是（如果可能的话）从现有的服务/产品开始，获得与您的环境相关的指标的经验，并且如果需要，根据它们实施您自己的设置。
轻量级交易
轻量级事务旨在支持在最终一致的环境中需要序列（或某种类型的事务）的案例研究。
但请注意，这是一个最小的解决方案，旨在序列化单个表中的任务。我们相信这是一个很好的解决方案，但是如果您的数据需要一致的解决方案，您应该避免最终一致的解决方案，并寻找 SQL 解决方案（使用本机事务）或 NoSQL 解决方案（例如 MongoDB）。
C* 内部结构