來自 Apache Cassandra 的您如何適應 Azure Cosmos DB for Apache Cassandra

發行項
08/15/2024

適用於： Cassandra

Azure Cosmos DB for Apache Cassandra 提供與現有 Cassandra SDK 和工具的有線通訊協定相容性。您可以使用最少變更的 API for Cassandra，執行設計用來連線至 Apache Cassandra 的應用程式。

當您使用 API for Cassandra 時，請務必留意 Apache Cassandra 與 Azure Cosmos DB 之間的差異。如果您熟悉原生 Apache Cassandra，本文可協助您開始使用 Azure Cosmos DB for Apache Cassandra。

功能支援

API for Cassandra 支援大多項的 Apache Cassandra 功能。但不支援某些功能，或有限制。在移轉之前，請確定支援所需的 Azure Cosmos DB for Apache Cassandra 功能。

複寫

當您規劃複寫時，請務必查看移轉和一致性。

雖然您可以透過 Cassandra 查詢語言 (CQL) 二進位通訊協定第 4 版有線通訊協定與 API for Cassandra 進行通訊，但是 Azure Cosmos DB 會實作自己的內部複寫通訊協定。您無法使用 Cassandra Gossip 通訊協定進行即時移轉或複寫。如需詳細資訊，請參閱使用雙重寫入即時從 Apache Cassandra 移轉至 API for Cassandra。

如需離線移轉的相關資訊，請參閱使用 Azure Databricks，將資料從 Cassandra 移轉至 Azure Cosmos DB for Apache Cassandra 帳戶。

雖然 Apache Cassandra 與 Azure Cosmos DB 中的複寫一致性方式類似，但請務必了解其間的差異。對應文件會將 Apache Cassandra 和 Azure Cosmos DB 方式與複寫一致性進行比較。不過，強烈建議您特別檢閱 Azure Cosmos DB 一致性設定，或觀看簡短的影片指南以了解 Azure Cosmos DB 平台中的一致性設定。

建議的客戶端設定

當您使用 API for Cassandra 時，不需要對執行 Apache Cassandra 的現有應用程式進行大量程式碼變更。建議在 Azure Cosmos DB 中使用 API for Cassandra 的某些方式和組態設定。請檢閱適用於 Java 的 API for Cassandra 建議部落格文章。

程式碼範例

API for Cassandra 設計成與現有應用程式碼搭配使用。如果您遇到連線的相關錯誤，則請使用快速入門範例作為起點，以探索您可能需要在現有程式碼中進行的次要設定變更。

我們也有更深入的 Java v3 和 Java v4 驅動程式範例。這些程式碼範例會實作自訂延伸模組，進而實作建議的用戶端設定。

您也可以使用 Java Spring Boot (v3 驅動程式) 和 Java Spring Boot (v4 驅動程式) 範例。

儲存體

API for Cassandra 是由 Azure Cosmos DB 所支援，而後者是一種文件導向 NoSQL 資料庫引擎。 Azure Cosmos DB 會維護中繼資料，而這可能會導致特定工作負載所需的實體儲存體數量變更。

在小型資料列大小中，原生 Apache Cassandra 與 Azure Cosmos DB 之間的儲存體需求差異最為明顯。在某些情況下，差異可能是位移，因為 Azure Cosmos DB 不會實作壓縮或標記。此因素主要取決於工作負載。如果您不確定儲存體需求，則建議您先建立概念證明。

多區域部署

原生 Apache Cassandra 預設為多主要區域系統。 Apache Cassandra 沒有僅供具有多區域複寫的單一主要區域進行讀取的選項。在 Apache Cassandra 中，不需要從應用程式層級容錯移轉至另一個區域以進行寫入的概念。所有節點都是獨立的，而且沒有單一失敗點。不過，Azure Cosmos DB 提供可讓您設定單一主要或多主要區域以進行寫入的現成功能。

具有單一主要區域進行寫入的優點是避免跨區域衝突案例。它可讓您選擇維護跨多個區域的強式一致性，同時維護高可用性層級。

注意

原生 Apache Cassandra 不可能使用跨區域的強式一致性和零復原點目標 (RPO)，因為所有節點都能提供寫入功能。您可以在「單一寫入區域」設定中設定 Azure Cosmos DB 的跨區域強式一致性。不過，與原生 Apache Cassandra 相同，您無法設定 Azure Cosmos DB 帳戶，而此帳戶已設定具有多個寫入區域來獲得強式一致性。分散式系統無法提供零 RPO「和」零復原時間目標 (RTO)。

如需詳細資訊，請參閱適用於 Java 的 API for Cassandra 建議部落格中的負載平衡原則。此外，請參閱官方 Cassandra JAVA v4 驅動程式的程式碼範例中的容錯移轉案例。

要求單位

執行原生 Apache Cassandra 叢集與佈建 Azure Cosmos DB 帳戶之間的其中一個主要差異是資料庫容量的佈建方式。在傳統資料庫中，容量是以 CPU 核心、RAM 和 IOPS 來表示。 Azure Cosmos DB 是多租用戶平台即服務資料庫。容量是使用單一標準化計量 (稱為要求單位) 來表示。傳送至資料庫的每個要求都會有要求單位成本 (RU 成本)。您可以剖析每個要求，以判斷其成本。

使用要求單位作為計量的好處是可以決定性地佈建資料庫容量，以提供高度可預測的效能和效率。分析每個要求的成本之後，您可以使用要求單位，直接將傳送至資料庫的要求數目與您需要佈建的容量建立關聯。使用這種佈建容量方式的挑戰是，您需要充分了解工作負載的輸送量特性。

強烈建議您剖析您的要求。使用該資訊有助於您預估佈建所需的要求單位數目。以下一些文章可協助您進行預估：

容量佈建模型

在傳統資料庫佈建中，會預先佈建固定容量來處理預期的輸送量。 Azure Cosmos DB 提供容量型模型，稱為佈建的輸送量。作為多租用戶服務，Azure Cosmos DB 也會以自動調整模式和無伺服器模式提供「使用量型」模型。工作負載可從上述任一使用量型佈建模型受益的範圍，取決於工作負載的輸送量可預測性。

一般情況下，對於具有可預測輸送量的穩定狀態工作負載，已佈建的輸送量所產生的效益最大。對於具有長期休眠期間的工作負載，無伺服器模式所產生的效益最大。對於具有持續最低輸送量層級但具有無法預測尖峰的工作負載，自動調整模式所產生的效益最大。建議您檢閱下列文章，以清楚了解最適合您輸送量需求的容量模型：

資料分割

Azure Cosmos DB 中的資料分割與 Apache Cassandra 中的資料分割類似。其中一個主要差異是 Azure Cosmos DB 最適用於「水平調整」。在 Azure Cosmos DB 中，會限制任何實體分割區中可用的「垂直輸送量」容量數量。現有資料模型具有明顯的輸送量扭曲時，此最佳化的效果最為明顯。

採取步驟，確保您的分割區索引鍵設計會產生相對一致的要求散發。如需邏輯和實體資料分割運作方式以及每個分割區之輸送量容量限制的詳細資訊，請參閱 Azure Cosmos DB for Apache Cassandra 中的資料分割。

調整大小

在原生 Apache Cassandra 中，容量和規模的增加包含將新的節點新增至叢集，以及確保已將節點正確地新增至 Cassandra 通道。在 Azure Cosmos DB 中，新增節點是透明而且是自動的。調整大小是針對 keyspace 或資料表佈建多少要求單位的功能。實體儲存體或所需的輸送量達到邏輯或實體分割區允許的限制時，就會在實體機器中進行調整大小。如需詳細資訊，請參閱 Azure Cosmos DB for Apache Cassandra 中的資料分割。

速率限制

佈建要求單位的挑戰是速率限制 (特別是在您正在使用佈建的輸送量時)。如果用戶端所耗用的資源超過您所佈建的數量，則 Azure Cosmos DB 會傳回速率受到限制錯誤。 Azure Cosmos DB 中的 API for Cassandra 會將這些例外狀況轉譯成 Cassandra 原生通訊協定上的多載錯誤。如需如何避免應用程式中速率限制的相關資訊，請參閱防止 Azure Cosmos DB for Apache Cassandra 作業的速率限制錯誤。

Apache Spark 連接器

許多 Apache Cassandra 使用者都會依據分析和資料移動需求而使用 Apache Spark Cassandra 連接器來查詢其資料。您可使用相同的方式和相同的連接器來連線至 API for Cassandra。連線至 API for Cassandra 之前，請檢閱從 Spark 連線至 Azure Cosmos DB for Apache Cassandra。請特別參閱最佳化 Spark 連接器輸送量設定小節。

常見問題疑難排解

如需常見問題的解決方案，請參閱針對 Azure Cosmos DB for Apache Cassandra 中常見的問題進行疑難排解。

共用方式為