我想了解max的建议。人们反复建议每个节点 1TB 负载,尤其是 Datastax。
除了更快的节点更换或备份等相当主观的评论之外,我还没有在任何地方看到这样的限制如何转化为任何指标。这些类型的注释非常模糊(对您来说快速的可能不适用于不同的生产环境)或者甚至可能是无关紧要的。 (看这个)
此外,目前 1TB 的限制似乎太低了,因为您只需 130 美元就可以买到 8TB 的SATA 磁盘。
- 1TB 限制是否符合 Cassandra 设计中的实际固有限制?
- 该限制是否已被量化,例如通过显示(例如图表)某些指标如何明显恶化超过该限制?
- 此限制是否比“<50% 容量”更相关?假设负载为3TB,但容量为50%,是否还需要增加节点数量?
这一限制使得固定容量阈值可能总是比固定负载阈值更容易、更便宜。这对我来说是不合理的,而且,如果确实如此,我会严重质疑 Cassandra 对于中小型企业的充分性。
我会尽力为您提供您想要的答案。
简短的回答是:1. 否,2. 是,3. 这取决于™
更详细...
Cassandra 5.0+ 将轻松允许每个节点高于 4TB 的密度。建议的节点密度基于硬件、数据模型和操作因素。 5.0 的更新准确建议正在制定中。
对于旧版本的 Apache Cassandra 及其所有变体,建议每个节点 1-4TB 数据。这意味着 2-8TB 磁盘。 (磁盘需要能够持续处理至少 10k IOPS,并且不执行 JBOD。)
50% 规则是使用 STCS (SizeTieredCompactionStrategy) 的表的基准规则。压缩过程最多会在磁盘上复制正在压缩的内容(以及同时)。更多的表意味着单个压缩不会达到 50%(请记住存在并发压缩器)。其他压缩策略改变了这种行为。 LCS(LeveledCompactionStrategy)具有级别,并且适用于较小的压缩,因此通常可以承受高达 70% 的磁盘使用率。 TWCS (TimeWindowedCompactionStrategy) 仅压缩当前时间窗口,因此 50% 变为 50% x 最大时间窗口大小。
还有其他一些事情会占用磁盘空间,例如备份和快照、流操作等,因此 50% 规则是一个安全的建议,可以放弃该规则,而无需详细说明。实际上,通常为 60-70%。但正如您已经指出的那样,这些大小的磁盘很便宜。
每个节点数据的限制在于操作的简便性。当节点数据密度高于 1TB 时,某些操作开始变得更加耗时且笨拙。尤其是所有与流相关的活动:引导、退役、修复等。尽管操作员承担了一些繁重的任务,但许多集群在 4TB 下运行得很好。如果使用 LCS,那么压缩可能会产生大量 IO,这可能会影响读取延迟。如果使用 STCS,则压缩最大层可能需要很长时间,从而使较低层处于待处理状态,这也可能会损害读取延迟。 TWCS 不会遇到这些问题,我们已经看到人们每个节点使用高达 16TB,但这使得这些流操作变得痛苦。再次强调,扔掉 1TB 的安全建议。
Apache Cassandra 5.0 和 DataStax 6.8 具有 UCS(统一压缩策略)。这种压缩策略可以在写入或读取放大的权衡之间进行调整/调谐,即在像STCS或像LCS(穷人类比)的行为之间进行滑动。通过这种压缩策略以及许多其他重大改进(例如基于尝试的 sstable 索引),节点密度可以更高。流媒体操作也得到了改进,变得更快、更“轻”。
Cassandra 是一种横向扩展技术,从第一天开始进行容量规划时就应该抱有这种心态。这不仅仅是利用商用硬件,而是 Cassandra 的关键设计特征,即耐用性、可用性和线性可扩展性。
您关于 Cassandra 不将计算与存储可扩展性分开的观点是有效的。请继续关注这方面的更多行动,从分层存储、后台阶段的单独进程/服务 (SEDA) 到 TCM (CEP-21),将会有大量改进。作为 The Last Pickle 和 DataStax 的顾问,我曾与数百个(也许数千个)生产集群合作过,而且正如您所关注的那样,其中大多数集群都是中小型的,我还没有看到这个问题成为您认为的阻碍因素就这样吧。 Cassandra 成为最受欢迎的无领导分布式数据库是有原因的。但是,是的,您的硬件选择更具选择性(记住横向扩展,而不是向上扩展,以及本地连接的 SSD,而不是 SAN),但除此之外,我们实际上在这里更多地讨论性能/成本优化,这是我们都喜欢的,但不是阻碍者。
我建议您去看看 AstraDB,它已经具有所有这些优点以及更多优点。