我已经通过了Cassandra节点configuration的推荐体系结构！ 据此推荐节点的硬件基础设施应该具有
内存： 16-32 GB，
存储： 500GB – 1TB和
具有8个内核的64位CPU
datastax文档说
“Cassandra 1.2及更高版本推荐的最大容量是每节点3到5TB”。
我有大量的写系统，比如说每秒10K条logging，初始数据存储要求是72TB，如果我每个节点有1TB，我将不得不有80个节点（记住开销）。目标是降低节点通过向每个节点添加更多数据存储容量来实现。
我的问题是
1.根据文档，16-32 GB的RAM将会与500-1TB的数据负载一起正常工作。 所以当我不得不增加更多的磁盘空间时，每个节点3-5TB，我还需要增强RAM和CPU吗？
2.存储大小和RAM + CPU之间是否有任何关联
我认为这将取决于你的数据集和你的负载。 存储大小和RAM + CPU之间没有直接的关系，但是，如果您希望从1TB到3TB的读写次数增加3倍，那么您可以预料到需要更多的RAM和CPU来满足这个需求好吧，但是你很可能不需要增加你的CPU和RAM 1：1与你的存储（即如果你从1到3TB的磁盘，你将不需要3x RAM容纳）。 一般来说，你会发现I / O是瓶颈，所以拥有快速磁盘（SSD！）是最重要的。
我已经用3TB的数据运行节点，它的工作没有太多的问题。 有很多需要完成的调整，所以除非你有一个有很多调整Cassandra经验的团队，否则我不会推荐它，除非这是一个很难的要求。 在那里你必须要小心的是内存和多less堆你将分配给Cassandra jvm过程。 Cassandra推荐的堆最大为8GB，因为垃圾收集在更大的堆中变得更具破坏性（除非你和Azul Zing一起使用），不太频繁的完整GC可能导致碎片，影响性能。 一般来说，如果可以避免的话，运行大于8GB的Java应用程序并不是一个好主意。
在较新版本的Cassandra中，可以从堆中移出很多内存。 从1.2开始，布隆filter和压缩元数据已经被移出并堆积到本地内存中。 在2.1中，您现在可以从堆中分配memtables ，这可以帮助您处理更大的数据集。 所以现在你可以从更多的内存中获得更多的好处，同时保持合理的（8GB）堆。
这是我的build议，总是倾向于更小的节点。 这些build议是有原因的，我认为这主要是因为Cassandra更能certificate以这种方式被使用。 Cassandra在云供应商和商品硬件方面performance出色，你甚至会发现拥有更小的节点比更小的节点更便宜。 在运营成本高昂的地方，如果你使用像木偶或厨师这样的好的configurationpipe理工具，它的成本就会降低。 专用硬件设置也变得更难。
我build议不要采取任何人的话，并findEC2或其他云提供商的不同configurationtesting，看看什么是最适合您的应用程序。 您的负载configuration文件和数据集真的会成为决定这个function是否起作用的因素。 我不能强调，用不同的configuration做很多testing！ 一旦你决定了某件事情，就会变成一种努力（但不是不可能）。 作为一个经历了3个不同的群集configuration1个应用程序，我不能强调这足够:)。 为了帮助testing，Cassandra 2.1中包含的新的压力工具使得生成一个代表您的应用程序将执行的加载场景变得非常简单。 Cassandra是非常可调的，并有很多衡量性能的好指标，所以使用压力工具也给了你尝试不同选项的机会，并学习更多关于pipe理Cassandra实例（调整memtable，压缩和其他设置以获得感觉）。 一个或两个星期的testing将为您节省数月的苦难！