Cassandra 基礎

Cassandra 是一種 NoSQL 分散式資料庫。NoSQL 資料庫在設計上輕量、開源、非關聯式且高度分散。它們的優點包括橫向擴充性、分散式架構和靈活的架構定義方法。

NoSQL 資料庫可快速且臨時組織和分析極大量的不同資料類型。隨著大數據的出現以及在雲端快速擴充資料庫的需求，這在近年來變得更加重要。Cassandra 是已解決先前資料管理技術（例如 SQL 資料庫）限制的 NoSQL 資料庫之一。

Cassandra 的一個重要屬性是其資料庫是分散的。這帶來技術和商業上的優勢。當應用程式處於高壓狀態時，Cassandra 資料庫可以輕鬆擴充，而分散也可以防止任何給定資料中心的硬體故障造成資料遺失。分散式架構也帶來技術能力；例如，開發人員可以獨立調整讀取查詢或寫入查詢的吞吐量。

「分散」表示 Cassandra 可以同時在多部機器上執行，但對使用者來說看起來是一個統一的整體。將 Cassandra 作為單一節點執行幾乎沒有意義，儘管這樣做對於幫助您快速了解其運作方式很有幫助。但要從 Cassandra 中獲得最大效益，您需要在多部機器上執行它。

由於它是一個分散式資料庫，因此 Cassandra 可以（而且通常會）有多個節點。節點代表 Cassandra 的單一執行個體。這些節點透過稱為「八卦」的通訊協定彼此通訊，這是一種電腦對等通訊程序。Cassandra 也具有無主架構，資料庫中的任何節點都可以提供與其他任何節點完全相同的功能，有助於 Cassandra 的強健性和復原力。多個節點可以在邏輯上組織成一個叢集或「環」。您也可以有多個資料中心。

Cassandra 受歡迎的原因之一是它使開發人員能夠使用現成的硬體動態擴充其資料庫，而且沒有停機時間。您可以在需要時擴充，也可以在應用程式需求建議這樣做時縮減。

您可能習慣使用 Oracle 或 MySQL 資料庫。如果是這樣，您知道擴充它們以支援更多使用者或儲存容量需要您增加更多 CPU 能力、RAM 或更快的磁碟。這些都花費大量的金錢。然而：最終您仍然會遇到一些上限和限制。

相較之下，Cassandra 能夠輕鬆增加其可管理的資料量。由於 Cassandra 是基於節點，因此它採用橫向擴充（又稱擴充），使用較低階的商品硬體。若要將容量加倍或將傳輸量加倍，只需將節點數加倍即可。就這麼簡單。需要更多效能嗎？新增更多節點即可，無論是新增 8 個或 8,000 個，都不會有停機時間。您也可以視需要縮小規模。

這種線性擴充基本上可以無限期地套用。此功能已成為 Cassandra 的主要優勢之一。

在 Cassandra 中，資料本身會自動分佈，並帶來（正面的）效能影響。它使用分區來達成此目的。每個節點都擁有特定的一組代幣，而 Cassandra 會根據這些代幣在叢集中的範圍來分佈資料。分區金鑰負責在節點之間分佈資料，而且對於決定資料區域性非常重要。當資料插入叢集時，第一步是對分區金鑰套用雜湊函數。輸出結果用於決定哪個節點（根據代幣範圍）將取得資料。

當資料進來時，資料庫的協調器會承擔將資料指派給特定分區的任務，我們稱之為分區 59。請記住，叢集中的任何節點都可以擔任協調器的角色。正如我們先前提到的，節點會彼此八卦；在此過程中，它們會溝通哪個節點負責哪些範圍。因此，在我們的範例中，協調器會執行查詢：哪個節點擁有代幣 59？當它找到正確的節點時，它會將資料轉發給該節點。擁有該範圍資料的節點稱為複本節點。一筆資料可以複製到多個（複本）節點，以確保可靠性和容錯性。到目前為止，我們的資料只複製到一個複本。這表示複製因子為一，或 RF = 1。

協調器節點並非單一位置；如果它是單一位置，系統就會很脆弱。它只是在特定時刻取得要求的節點。任何節點都可以擔任協調器。

一筆資料可以複製到多個（複本）節點，以確保可靠性和容錯性。Cassandra 支援複製因子 (RF) 的概念，它描述資料庫中應存在多少份資料副本。到目前為止，我們的資料只複製到一個複本 (RF = 1)。如果我們將其提升到複製因子二 (RF = 2)，資料也需要儲存在第二個複本上，因此除了主範圍之外，每個節點也負責次要範圍的代幣。複製因子三可確保有三個節點（複本）涵蓋該特定代幣範圍，而且資料儲存在另一個節點上。

Cassandra 分散式特性讓它更具復原力和效能。當我們有相同資料的複本時，這項特性便發揮作用。這麼做有助於系統在發生問題時自我修復，例如節點當機、硬碟故障或 AWS 重置執行個體。複製可確保資料不會遺失。如果資料有請求進來，即使我們的其中一個複本已當機，其他兩個複本仍可滿足請求。協調器也會為該資料儲存「提示」，當已當機的複本重新啟動時，它會找出自己錯過的資料，並趕上其他兩個複本的進度。不需要手動操作，這項工作會完全自動完成。

使用多個複本也有效能優勢。因為我們不限於單一執行個體，我們有三個節點（複本）可存取，以提供資料給我們的作業，我們可以在其中進行負載平衡，以達成最佳效能。

Cassandra 會自動在不同的資料中心複製該資料。您的應用程式可以將資料寫入美國西岸的 Cassandra 節點，而該資料會自動在亞洲和歐洲節點的資料中心中提供。這有正面的效能優勢，特別是如果您支援全球使用者群組。在依賴雲端運算和快速資料存取的世界中，沒有使用者會因為距離而遭受延遲

我們已經討論了很多關於分散式系統和可用性。如果您熟悉 CAP 定理，Cassandra 預設為 AP（可用分區容錯）資料庫，因此它「永遠都在」。但您確實可以在每個查詢的基礎上設定相容性。在此脈絡中，相容性層級代表在協調器將作業視為成功之前，必須確認讀取或寫入作業的 Cassandra 節點的最小數量。一般來說，您會根據您的複製因子選擇相容性層級 (CL)。 對於以下範例，我們的資料複製到三個節點。我們的 CL=QUORUM（法定人數是指多數，在本例中為 2 個複本或 RF/2 +1），因此協調器需要從兩個複本取得確認，才能將查詢視為成功。

與其他運算任務一樣，學習調整此功能以獲得理想效能、可用性和資料完整性可能需要一些技巧，但由於您可以使用如此精細的粒度控制它，表示您可以非常詳細地控制部署。

最終，Cassandra 與部署無關。它不在乎您將它放在哪裡，在公司內部、雲端供應商、多個雲端供應商。您可以將這些組合用於單一資料庫。這為軟體開發人員提供了最大的靈活性。