卡桑德拉：維護
我對 Cassandra 沒有經驗，但我對基於 SQL 的關係數據庫有一些經驗。
我一直無法找到有關如何在部署後維護 Cassandra 的最佳實踐資訊。有必要對數據庫進行 VACUUM 嗎？我應該認為讀/寫負載會導致儲存碎片。
或更籠統地說：維護 Cassandra 生產部署的最佳實踐是什麼？為了保持系統的健康，必須定期做些什麼？操作手冊確實沒有討論這個方面。
謝謝。
一般來說，一個設計良好的集群可以在不被觸及的情況下存活數年。我已經有多年不干涉的集群。但是，這裡有一些指導方針：
監控非常重要：
監控延遲。使用 opscenter 或您最喜歡的指標工具來跟踪延遲。延遲上升可能是問題出現的跡象，包括 GC 暫停（在讀取工作負載中比在寫入工作負載中更常見）、sstable 問題等。
監控穩定計數。如果超過壓縮，SSTable 計數將增加（每個 sstable 只寫入一次 - 通過壓縮將舊 sstable 合併到新 sstable 來處理刪除）。
3）監控節點狀態變化（上/下等）。如果您看到節點抖動，請進行調查，因為這是不正常的。
- 跟踪您的磁碟使用情況 - 傳統上，您需要保持在 50% 以下（特別是如果您使用 STCS 壓縮）。
您應該和不應該經常做一些基本的事情：
1）不要顯式執行
nodetool compact. 你提到你已經做到了，這不是致命的，但它確實創建了非常大的 sstables，這樣就不太可能參與向前推進的壓縮。您不一定需要繼續執行它，但有時它可能有助於擺脫已刪除/覆蓋的數據。2)
nodetool repair通常建議每一次gc_grace_seconds（預設為 10 天）。有些工作負載不那麼重要-您需要修復的最大原因是確保刪除標記tombstones（gc_grace_seconds無需維修！）。如果您不發出刪除操作，並且以足夠的一致性級別進行查詢（例如，在 QUORUM 上進行讀取和寫入），那麼您實際上可以過上無需修復的生活。3）如果要修復，考慮使用增量修復，一次修復小範圍。
4）壓實策略很重要。STCS 非常適合寫入，LCS 非常適合讀取。DTCS 有一些怪癖。
數據模型很重要——就像 RDBMS/SQL 環境在未索引的查詢遇到大表時遇到麻煩一樣，Cassandra 可能會在處理非常大的行/分區時出現問題。
快照很便宜。非常便宜。幾乎是即時的，只是硬連結，它們幾乎不需要立即佔用磁碟空間。在升級版本之前使用快照，尤其是主要版本。
7）小心刪除。正如 #2 中所暗示的， delete 在磁碟上創建更多數據，並且不會為 AT LEAST 釋放它
gc_grace_seconds。當一切都失敗時：
我看過一些文章建議 Cassandra 在 prod 中需要一個專門的負責人來管理任何大小的集群 - 我不知道這是否一定是真的，但如果你擔心，你可能想聘請第三方顧問（TheLastPickle，Pythian ) 或簽訂支持契約 (Datastax)，讓您高枕無憂。