關於 Azure Cosmos DB for Apache Cassandra 的常見問題集

以下是 API for Cassandra 服務和 Apache Cassandra 之間的一些主要差異：

• Apache Cassandra 建議的資料分割索引鍵有 100-MB 的大小限制。 適用於 Azure Cosmos DB 的 API for Cassandra 允許每個分割區最多 20 GB。
• Apache Cassandra 可讓您停用持久性認可。 您可以略過寫入認可記錄檔，並直接移至記憶體內部資料結構。 若記憶體內部資料結構排清至磁碟上的 SSTables 之前，節點停止運作的話，則可能導致資料遺失。 Azure Cosmos DB 一律會執行持久性認可，協助防止資料遺失。
• 若工作負載牽涉到許多取代或刪除動作，則 Apache Cassandra 會看到效能降低的情況。 原因在於讀取工作負載需要跳過標記才能擷取最新的資料。 當工作負載有許多取代或刪除動作時，API for Cassandra 不會看到讀取效能下降。
• 在高取代工作負載情節中，需要執行壓縮以合併磁碟上的 SSTables。 (Apache Cassandra 只會以附加方式寫入，因此需要合併。多個更新會以個別的 SStable 項目儲存，這些項目需要定期合併)。 這種情況也可能導致壓縮期間的讀取效能降低。 由於 API for Cassandra 不會實作壓縮，因此，該 API 中不會發生這種效能影響。
• 使用 Apache Cassandra 可以設定 1 的複寫因數。 然而，若有資料的唯一節點停止運作，則會導致低可用性。 這個問題和適用於 Azure Cosmos DB 的 API for Cassandra 無關，因為永遠都有一個複寫因數為 4 (仲裁為 3)。
• 在 Apache Cassandra 中新增或移除節點，需要手動介入及新節點上的高 CPU 用量，而現有節點則會將其某些權杖範圍移至新節點。 當您將現有節點解除委任時，也會發生這種情況。 不過，當 API for Cassandra 擴增時，並未在服務或應用程式中觀察到任何問題。
• 不需要像在 Apache Cassandra 中一樣將 num_tokens 設定在叢集中的每個節點上。 Azure Cosmos DB 完全管理節點和權杖範圍。
• API for Cassandra 是完全受控的。 不需要像在 Apache Cassandra 中一樣使用命令，例如修復和解除委任。

適用於 Azure Cosmos DB 的 API for Cassandra 支援 Cassandra 查詢語言 (CQL) m 3.x 版。 其 CQL 相容性是以公用 Apache Cassandra GitHub 存放庫為基礎。 如果您有關於支援其他通訊協定的意見反應，請傳送電子郵件至 askcosmosdbcassandra@microsoft.com。

Azure Cosmos DB 會根據您是透過 Azure 入口網站還是 CQL 建立資料表，為您的容器設定預設輸送量。

Azure Cosmos DB 能提供效能和延遲上的保證，限定作業時的上限。 當引擎能針對租用戶的作業強制執行治理時，這些保證是可能的。 設定輸送量能確保您享有保證的輸送量和延遲，因為平台會保留產能，保證作業成功。 您可以彈性變更輸送量，從應用程式的季節性因素中獲益並節省成本。

輸送量概念的說明請參閱 Azure Cosmos DB 中的要求單位一文。 資料表的輸送量會平均散發到基礎實體分割區。

Azure Cosmos DB 使用每秒要求單位數 (RU/秒) 做為提供輸送量的貨幣。 透過 CQL 所建立的資料表預設有 400 RU。 您可以從 Azure 入口網站變更 RU。

CQL

CREATE TABLE keyspaceName.tablename (user_id int PRIMARY KEY, lastname text) WITH cosmosdb_provisioned_throughput=1200

.NET

int provisionedThroughput = 400;
var simpleStatement = new SimpleStatement($"CREATE TABLE {keyspaceName}.{tableName} (user_id int PRIMARY KEY, lastname text)");
var outgoingPayload = new Dictionary<string, byte[]>();
outgoingPayload["cosmosdb_provisioned_throughput"] = Encoding.UTF8.GetBytes(provisionedThroughput.ToString());
simpleStatement.SetOutgoingPayload(outgoingPayload);

Azure Cosmos DB 能提供效能和延遲上的保證，限定作業時的上限。 當引擎能針對租用戶的作業強制執行治理時，這些保證是可能的。 設定輸送量能確保您享有保證的輸送量和延遲，因為平台會保留產能，保證作業成功。

當您超過此容量時，會收到下列錯誤訊息，表示您的容量已超過：

0x1001 多載：無法處理要求，因為「要求速率太大」

請務必查看是哪些作業 (和其磁碟區) 導致此問題。 您可以透過 Azure 入口網站上的計量，瞭解已取用容量超過所佈建容量的情形。 然後，您必須確保您會在所有基礎分割區以近乎平均的方式取用容量。 若您看到某個分割區取用極大部分的輸送量，則表示您的工作負載有所傾斜。

我們提供的計量可讓您知道所有分割區在幾小時、幾天以及每七天的輸送量使用情形，或其彙總。 如需詳細資訊，請參閱使用 Azure Cosmos DB 中的計量監控及偵錯。

診斷記錄的說明請見 Azure Cosmos DB 診斷記錄一文。

是，資料分割索引鍵可用來將實體放在正確的位置。 在 Azure Cosmos DB 中，我們會用它來尋找實體資料分割上所儲存的正確邏輯資料分割。 資料分割概念的詳細說明請見在 Azure Cosmos DB 中進行資料分割和調整一文。 這裡的重點是，邏輯資料分割不應超過 20 GB 的限制。

Azure Cosmos DB 是以服務等級協定 (SLA) 為基礎的系統。 該系統提供無限制的縮放，及延遲、輸送量、可用性、和一致性保證。 此無限制的儲存體是根據資料的水平縮放，並使用資料分割做為重要概念。 資料分割概念的詳細說明請見在 Azure Cosmos DB 中進行資料分割和調整一文。

您應該遵守實體數目或每個邏輯資料分割之項目數的 20 GB 限制。 為了確保您的應用程式能夠進行適當的調整，建議您「避免」建立常用資料分割 (將所有資訊儲存在一個資料分割，然後進行查詢)。 當您的資料分佈有所傾斜：也就是說，如果您在一個資料分割索引鍵放了大量資料 (超過 20 GB) 時才會發生這個錯誤。 您可以使用儲存體入口網站找到資料的分佈。 修正此錯誤的方法是重新建立資料表，然後選擇細微的主要資料 (分割索引鍵)，讓資料分佈情形更加適當。

Azure Cosmos DB 可以透過相應放大儲存體以儲存無限量的資料。 這個儲存體與輸送量無關。 是，您一律可以使用 API for Cassandra，只透過指定正確的主要/分割區索引鍵來儲存及擷取索引鍵和值。 這些個別的索引鍵會有自己的邏輯資料分割區，並且是以實體資料分割為基礎，因此不會有問題。

是，您可以使用 API for Cassandra 來建立多個資料表。 系統會將這些資料表各視為輸送量和儲存體的單位。

Azure Cosmos DB 是資源所管理的系統，適用於資料和控制平面活動。 集合和資料表等容器是針對特定的輸送量容量所佈建的執行階段實體。 快速並連續建立這些容器並非預料中的活動，因此可能會受到節流。 若您要進行會立即卸除或建立資料表的測試，請嘗試將這些資料表分開。

可以建立的資料表數量並無實際限制。 若您有大量的資料表需要建立 (其中穩定大小總計超過 10 TB 的資料)，而不是一般的數十或數百個，則請傳送電子郵件至 askcosmosdbcassandra@microsoft.com。

Keyspace 數量沒有實體限制，因為 keyspace 是中繼資料容器。 如果您有大量的 keyspace，請傳送電子郵件至 askcosmosdbcassandra@microsoft.com。

是。 基於分散式分割區的假設，儲存體容量是由系統自動管理，並且會隨著您放入更多的資料而增加。 因此，您可以放心地匯入您所需的資料量，不必管理和佈建節點等。 但是，若您預期立即會有大量資料增加，則直接佈建預期的輸送量，會比從較低開始並立即增加來得合理。

適用於 Azure Cosmos DB 的 API for Cassandra 會提供通訊協定層級的相容性來執行作業。 它會讓管理、監視和設定作業變得不再複雜。 身為開發人員/使用者，您不必擔心可用性、標記、金鑰快取、資料列快取、bloom 篩選和諸多其他設定。 API for Cassandra 著重在為您提供所需的讀取和寫入效能，且免除設定和管理的額外負荷。

API for Cassandra 可針對容量規劃及回應輸送量和儲存體的彈性要求進行簡化。 藉由 Azure Cosmos DB，您可以佈建所需的輸送量。 然後，您可以在一天之中不限次數地將此輸送量相應增加和減少，不必擔心如何新增、刪除或管理節點。 您不需要使用工具來管理節點和叢集。

基於可用性和低延遲的考量，Azure Cosmos DB 提供全域發佈。 您不需要設定複本或其他項目。 針對您寫入的區域，系統一律會將寫入永久仲裁認可，並提供效能保證。

Azure Cosmos DB 提供讀取、寫入和輸送量的效能保證。 因此您不需擔心觸及任何組態設定而不小心進行不當操作。 這些設定包括 bloom 篩選、快取、讀取修復機會、gc_grace，及壓縮 memtable_flush_period。

是，有支援 TTL。

Azure Cosmos DB 是一種平台服務，可協助您提高產能，而不必擔心如何管理及監視基礎結構。 舉例來說，您不需透過各種工具及早監視節點狀態、複本狀態、gc 和 OS 參數。 您只需要處理輸送量，可在入口網站的計量中找到此資訊，若您遇到節流情形，可將該輸送量予以增加或減少。 您可以：

• 監視 SLA
• 使用計量
• 使用診斷記錄

使用 CQLv3 的 Apache Cassandra SDK 用戶端驅動程式會用於用戶端程式。 如果您使用其他驅動程式，或如果您遇到問題，請傳送電子郵件到 askcosmosdbcassandra@microsoft.com。

是，您可以使用一般語法來建立複合資料分割索引鍵。

否，不支援 sstableloader。

現在，Azure Cosmos DB 具有最佳化的雲端環境體驗，且不會產生作業負荷。 如果您需要配對，請傳送電子郵件到 askcosmosdbcassandra@microsoft.com，並說明您的案例。 我們正努力開發一個供應項目，以協助將內部部署或雲端 Cassandra 叢集與適用於 Azure Cosmos DB 的 API for Cassandra 進行配對。

Azure Cosmos DB 提供兩個免費的完整備份，並針對所有 API 以四個小時為間隔進行擷取。 因此您不需設定備份排程。

您可以自行管理備份保留期和頻率。

如果您想要從備份還原，請傳送電子郵件給 askcosmosdbcassandra@microsoft.com 或提出支援案例。 使用 Azure Cosmos DB 進行自動線上備份及還原一文會提供備份功能的相關資訊。

API for Cassandra 會借用 Azure Cosmos DB 的全域散發平台。 為了確保您的應用程式可以容許資料中心停機，請在 Azure 入口網站中針對該帳戶至少啟用一個以上的區域。 如需詳細資訊，請參照使用 Azure Cosmos DB 的高可用性。

您可以針對帳戶加入任意數目的區域，並藉由提供容錯移轉優先順序來控制容錯移轉的目標位置。 若要使用的資料庫，您還需要在目標位置提供應用程式。 如果您這樣做，您的客戶就不會經歷停機時間。

否。 API for Cassandra 支援次要索引，其與 Apache Cassandra 具有類似的行為。 根據預設，API 不會編製每個屬性的索引。

是，支援這種情況。 您可以在使用 Azure Cosmos DB Emulator 進行本機開發和測試一文中找到如何啟用此功能的詳細資料。

您可以在將資料移轉至 Azure Cosmos DB 中的 API for Cassandra 帳戶的教學課程中，閱讀有關移轉選項的細節。

相關內容

• 開始使用彈性調整 Azure Cosmos DB for Apache Cassandra 帳戶

後續步驟