Cassandra：做更多的儲存大小，需要更多的 CPU 和 RAM
推薦的Cassandra節點配置架構我已經看完了！根據哪個推薦的節點硬體基礎設施是
RAM： 16-32 GB，
儲存： 500GB - 1TB 和8 核
64 位CPU
datastax 文件說
“Cassandra 1.2 及更高版本的最大推薦容量為每個節點 3 到 5TB。”
我有繁重的寫入系統，比如每秒 10K 條記錄，初始數據儲存要求是 72TB，如果我每個節點使用 1TB，我將不得不有近 80 個節點（記住成本）.. 目標是降低節點通過向每個節點增加更多的數據儲存容量來增加數量。
我的問題是
- 根據文件，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 TB 增加到 3TB，則不需要 3x RAM 來容納）。通常，您會發現 I/O 是瓶頸，因此擁有快速磁碟（SSD！）是最重要的。
我已經執行了具有 3TB 數據的節點，並且執行起來沒有太多問題。有很多調整需要完成，所以除非你的團隊中有一個有很多調整 Cassandra 經驗的人，否則我不會推薦它，除非這是一個硬性要求。您需要注意的地方是 RAM 以及您將分配給 Cassandra jvm 程序的堆大小。Cassandra 推薦的最大堆為 8GB，因為垃圾收集會隨著堆的增大而變得更具破壞性（除非您使用 Azul Zing），並且不太頻繁的完整 GC 會導致碎片，從而影響性能。一般來說，如果可以避免的話，執行堆大於 8GB 的 Java 應用程序並不是一個好主意。
在較新版本的 Cassandra 中，您可以將很多內容從堆中移到本機記憶體中。從 1.2 開始，布隆過濾器和壓縮元數據已從堆中移出並移到本機記憶體中。在 2.1 中，您現在可以在堆外分配記憶體表，這可以幫助您處理更大的數據集。因此，現在您可以從擁有更多 RAM 中獲益更多，同時保持合理的 (8GB) 堆。
我的建議是始終更傾向於擁有更小的節點。這些建議的存在是有原因的，我認為這主要是因為 Cassandra 被更多地證明以這種方式使用。Cassandra 在雲提供商和商品硬體上執行良好，您甚至可能會發現擁有更多更小的節點比擁有更小的節點更便宜。它可能變得昂貴的地方在於運營，但如果您使用像 puppet 或 chef 這樣的良好配置管理工具，它的成本就會降低。對於專用硬體設置，這也變得更加困難。
不過，我建議不要相信任何人的話，並在 EC2 或其他雲提供商中使用不同的配置進行測試，看看哪種方式最適合您的應用程序。您的負載配置文件和數據集確實將成為這是否可行的決定因素。我怎麼強調都不為過，用不同的配置做很多測試！一旦你決定了某件事，關閉它就變成了一種努力（但並非不可能）。作為一個為 1 個應用程序經歷了 3 種不同集群配置的人，我對此再怎麼強調都不為過 :)。為了幫助測試這一點，新的壓力工具包含在 Cassandra 2.1 中可以非常容易地生成一個負載場景，該場景代表您的應用程序將執行的操作。Cassandra 非常可調，並且有很多衡量性能的良好指標，因此使用壓力工具還可以讓您有機會嘗試不同的選項並了解有關管理 Cassandra 實例的更多資訊（調整 memtable、壓縮和其他設置以感受一下）。一到兩週的測試將為您節省數月的困難！