硬體選擇

Cassandra 是高度並行的，它使用在盡可能多的 CPU 核心上執行的多個執行緒，處理許多同時的請求（讀取和寫入）。Cassandra 寫入路徑傾向於高度最佳化（寫入提交記錄，然後將資料插入記憶表），因此，寫入特別容易受到 CPU 限制。因此，新增額外的 CPU 核心通常會增加讀取和寫入的處理量。

Cassandra 在 Java VM 中執行，它會預先配置一個固定大小的堆積（Java 的 Xmx 系統參數）。除了堆積之外，Cassandra 還會使用大量的非堆積 RAM，用於壓縮元資料、布隆過濾器、列、金鑰和計數器快取，以及處理中頁面快取。最後，Cassandra 會利用作業系統的頁面快取，將最近存取的部分檔案儲存在 RAM 中，以快速重複使用。

為了獲得最佳效能，操作員應根據其個別工作負載對其叢集進行基準測試和調整。然而，基本準則建議

Cassandra 將資料持續寫入磁碟，有兩個截然不同的目的。第一個是當新的寫入產生時，寫入提交記錄檔，以便在系統崩潰或關閉後可以重新播放。第二個是當閾值超過，且記憶表會以 SSTable 的形式清除到磁碟時，寫入資料目錄。

提交記錄檔會收到傳送到 Cassandra 節點的每個寫入，並有可能會阻擋用戶端作業，但這些作業只會在節點啟動時讀取。另一方面，SSTable（資料檔案）寫入會非同步發生，但會讀取以滿足用戶端查詢。SSTable 也會定期合併並改寫，這個程序稱為壓縮。提交記錄檔目錄中所保存的資料，是尚未永久儲存到 SSTable 資料目錄的資料，一旦清除到 SSTable 資料檔案後，就會定期清除。

Cassandra 在旋轉式硬碟和固態磁碟上都能表現得很好。在兩種情況下，Cassandra 的已排序不可變 SSTable 都能進行線性讀取、少數搜尋和少數覆寫，最大化 HDD 的吞吐量，並透過避免寫入放大化來延長 SSD 的使用壽命。然而，在使用旋轉式磁碟時，重要的是提交記錄檔（commitlog_directory）必須在一個實體磁碟上（不只是分割區，而是一個實體磁碟），而資料檔案（data_file_directories）必須設定到一個獨立的實體磁碟上。透過將提交記錄檔從資料目錄中分開，寫入可以受益於提交記錄檔的順序追加，而無需在磁碟上從各種 SSTable 中讀取資料時，在磁盤上搜尋。

在大多數情況下，Cassandra 被設計為透過多個獨立且便宜的伺服器提供備援。因此，將 NFS 或 SAN 用於資料目錄是一種反模式，通常應該避免。類似地，具有多個磁碟的伺服器通常更適合使用 RAID0 或 JBOD，而不是 RAID1 或 RAID5，Cassandra 提供的複製使磁碟層的複製變得過時，因此通常建議作業員利用 RAID0 的額外吞吐量，而不是使用 RAID1 或 RAID5 來防範故障。

許多 Cassandra 的大型使用者會在各種雲端中執行，包括 AWS、Azure 和 GCE，Cassandra 會很樂意在這些環境中執行。使用者應該選擇與實體空間中需要的類似的硬體。在 EC2 中，熱門的選項包括

一般來說，磁碟和網路效能會隨著執行個體大小和世代而提升，因此每個系列中較新的執行個體世代和較大的執行個體類型通常會比較小或較舊的替代方案效能更好。