我已经看过 Cassandra 节点配置的推荐架构！根据该架构，建议节点的硬件基础设施应具有
内存：16-32 GB，
贮存：500GB - 1TB 和
64 位中央处理器8 核
datastax 文档说
“Cassandra 1.2 及更高版本的最大建议容量为每节点 3 至 5TB。”
我有一个重型写入系统，比如每秒 10K 条记录，初始数据存储要求为 72TB，如果我以每个节点 1TB 的速度使用，我将必须拥有近 80 个节点（记住开销）.. 目的是通过为每个节点添加更多数据存储容量来降低节点数量。
我的问题是
1. 根据文档，16-32 GB 的 RAM 可以很好地处理 500-1TB 的数据负载。那么当我必须添加更多磁盘空间（每个节点 3-5TB）时，我是否也必须增强 RAM 和 CPU？
2. 存储大小和 RAM + CPU 之间是否存在任何关联
答案1
我认为这种方法的效果取决于您的数据集和负载。存储大小与 RAM + CPU 之间没有直接关系，但是，如果您预计从 1TB 到 3TB 的读写次数会增加 3 倍，那么您可以预期您也需要使用更多的 RAM 和 CPU 来适应这种情况，但您很可能不需要将 CPU 和 RAM 与存储 1:1 地增加（即，如果您的磁盘从 1TB 增加到 3TB，则不需要 3 倍 RAM 来适应）。通常，您会发现 I/O 是瓶颈，因此拥有快速磁盘（SSD！）是最重要的。
我运行过包含 3TB 数据的节点，它运行起来没有太多问题。需要进行大量调整，因此除非团队中有一位在调整 Cassandra 方面经验丰富，否则除非这是硬性要求，否则我不会推荐它。需要注意的是 RAM 以及要分配给 Cassandra jvm 进程的堆大小。Cassandra 的最大推荐堆大小为 8GB，因为堆越大，垃圾收集就越具破坏性（除非使用 Azul Zing），而频率较低的完整 GC 会导致碎片化，从而影响性能。一般来说，如果可以避免，最好不要运行堆大小超过 8GB 的 Java 应用程序。
在较新版本的 Cassandra 中，你可以将大量数据从堆移到本机内存中。自 1.2 版以来，Bloom 过滤器和压缩元数据已从堆移到本机内存中。在 2.1 版中，你现在可以在堆外分配内存表，这可能有助于您处理更大的数据集。因此，现在您可以从拥有更多 RAM 中获益更多，同时保持合理的 (8GB) 堆。
我的建议是始终倾向于使用较小的节点。这些建议的存在是有原因的，我认为主要是因为 Cassandra 以这种方式使用效果更佳。Cassandra 在云提供商和商用硬件上运行良好，您甚至可能会发现拥有更多较小的节点比拥有较少的大节点更便宜。成本可能增加的地方在于运营，但如果您使用 puppet 或 chef 等良好的配置管理工具，成本就会降低。使用专用硬件设置也更难做到这一点。
不过，我建议不要轻信任何人的话，而是在 EC2 或其他云提供商中测试不同的配置，看看哪种配置最适合您的应用程序。您的负载配置文件和数据集才是决定这是否有效的决定因素。我再怎么强调也不为过，用不同的配置做大量测试！一旦你决定了某件事，关掉它就变成了一项努力（但并非不可能）。作为一个为一个应用程序尝试过 3 种不同集群配置的人，我再怎么强调也不为过 :)。为了帮助测试这一点，新的压力工具Cassandra 2.1 附带的负载场景可以非常轻松地生成代表应用程序将执行的操作的负载场景。Cassandra 非常易于调整，并且具有许多用于衡量性能的良好指标，因此使用压力工具还可以让您有机会尝试不同的选项并了解有关管理 Cassandra 实例的更多信息（调整内存表、压缩和其他设置以获得感觉）。一到两周的测试将为您节省数月的辛苦！