共用方式為

實現最佳效能的最佳做法

  • 發行項

Azure Managed Instance for Apache Cassandra 是純開放原始碼 Apache Cassandra 叢集的完全受控服務。 此服務也允許根據每個工作負載的特定需求來覆寫組態，允許視需要提供最大彈性和控制。 本文提供如何最佳化效能的秘訣。

最佳設定和組態

複寫因數、磁碟數目、節點數目和 SKU

因為 Azure 在大多數區域中支援三個可用性區域，且 Cassandra 受控執行個體將可用性區域對應至機架，因此建議您選擇具有高基數的分割索引碼，以避免出現經常性分割區。 為達到最佳等級的可靠性和容錯能力，強烈建議您將複寫因數設定為 3。 我們也建議您指定複寫因數的倍數作為節點數目，例如 3、6、9 等等。

我們會根據您佈建的磁碟數目使用 RAID 0。 因此，若要取得最佳 IOPS，您需要檢查所選 SKU 上的最大 IOPS 以及 P30 磁碟的 IOPS。 例如，Standard_DS14_v2 SKU 支援 51,200 個未快取 IOPS，而單一 P30 磁碟的基本效能為 5,000 IOPS。 因此，四個磁碟會導致 20,000 個 IOPS，這遠低於機器的限制。

強烈建議您根據 SKU 和磁碟數目，對工作負載進行廣泛的基準測試。 在只有八個核心的 SKU 的情況下，基準測試尤其重要。 我們的研究顯示，八個核心 CPU 僅適用於要求最低的工作負載，而大多數工作負載至少需要 16 個核心才能發揮效能。

比較分析工作負載與交易式工作負載

交易式工作負載通常需要針對低延遲進行資料中心最佳化，而分析工作負載通常會使用更複雜的查詢，這需要更長的執行時間。 在大部分情況下，您需要個別的資料中心：

  • 一個針對低延遲進行最佳化
  • 一個針對分析工作負載進行最佳化

針對分析工作負載進行最佳化

建議客戶對分析工作負載套用以下 cassandra.yaml 設定 (請參閱此處以了解如何套用)。

逾時

值 Cassandra MI 預設值 分析工作負載建議
read_request_timeout_in_ms    5,000   10,000
range_request_timeout_in_ms 10,000 20,000
counter_write_request_timeout_in_ms  5,000 10,000
cas_contention_timeout_in_ms 1,000 2,000
truncate_request_timeout_in_ms 60,000 120,000
slow_query_log_timeout_in_ms 500 1,000
roles_validity_in_ms 2,000 120,000
permissions_validity_in_ms 2,000 120,000

快取

值 Cassandra MI 預設值 分析工作負載建議
file_cache_size_in_mb 2,048 6,144

其他建議

值 Cassandra MI 預設值 分析工作負載建議
commitlog_total_space_in_mb 8,192 16,384
column_index_size_in_kb 64 16
compaction_throughput_mb_per_sec 128 256

用戶端設定

建議您根據伺服器上套用的逾時，來提升 Cassandra 用戶端驅動程式逾時。

針對低延遲進行最佳化

我們的預設設定已適用於低延遲工作負載。 若要確保結尾延遲的最佳效能，強烈建議您使用支援推測執行的用戶端驅動程式，並據以設定用戶端。 對於 JAVA V4 驅動程式，您可以在此處找到說明其運作方式以及如何啟用原則的示範。

監視效能瓶頸

CPU 效能

跟每個資料庫系統一樣，如果 CPU 使用率約為 50%，且永遠不會超過 80%，則 Cassandra 的運作效果最佳。 您可以在入口網站的「監視」內的「計量」索引標籤中檢視 CPU 計量：

Screenshot of CPU metrics.

如果大多數節點的 CPU 持續超過 80%，則資料庫會變成超載，顯示為多個用戶端逾時。 在此案例中，建議您採取下列動作：

  • 垂直擴大至具有更多 CPU 核心的 SKU (特別是只有 8 個核心或更少時)。
  • 透過增加更多節點來水平擴大 (如前所述，節點數目應該是複寫因數的倍數)。

如果僅少數節點的 CPU 偏高，而其他節點為低，則表示有經常性分割區，且需要進一步調查。

注意

透過 Azure 入口網站、Azure CLI 和 ARM 範本部署支援變更 SKU。 您可以部署/編輯 ARM 範本，並將 SKU 取代為下列其中一項。

  • Standard_E8s_v4
  • Standard_E16s_v4
  • Standard_E20s_v4
  • Standard_E32s_v4
  • 標準 DS13_v2
  • 標準 DS14_v2
  • Standard_D8s_v4
  • Standard_D16s_v4
  • Standard_D32s_v4
  • Standard_L8s_v3
  • Standard_L16s_v3
  • Standard_L32s_v3
  • Standard_L8as_v3
  • Standard_L16as_v3
  • Standard_L32as_v3

請注意，目前我們不支援跨 SKU 系列轉換。 例如，如果您目前擁有 Standard_DS13_v2 並且有興趣升級至更大的 SKU (例如 Standard_DS14_v2)，則此選項不適用。 不過，您可以開啟支援票證以要求升級至較高的 SKU。

磁碟效能

該服務會在允許「高載 IOPS」的 Azure P30 受控磁碟上執行。 涉及磁碟相關的效能瓶頸時，需要仔細監視。 在此情況下，請務必檢閱 IOPS 計量：

Screenshot of disk I/O metrics.

如果計量顯示下列其中一項或全部特性，表示您需要擴大規模。

  • 一致高於或等於基本 IOPS (請記得將每個節點的磁碟數目乘以 5,000 個 IOPS，以取得該數字)。
  • 一致高於或等於 SKU 允許寫入的最大 IOPS。
  • 您的 SKU 支援快取儲存體 (寫入快取)，且該數字小於受控磁碟的 IOPS (這會是讀取 IOPS 的上限)。

如果僅在少數節點上看到 IOPS 提高，則可能有經常性分割區，且需要檢閱資料是否有潛在的偏差。

如果您的 IOPS 低於所選 SKU 支援的值，但高於或等於磁碟 IOPS，您可以採取下列動作：

  • 新增更多磁碟以提升效能。 增加磁碟需要提出支援案例。
  • 透過新增更多節點來擴大資料中心。

如果您的 IOPS 超出 SKU 支援上限，您可以：

  • 擴大至支援更多 IOPS 的不同 SKU。
  • 透過新增更多節點來擴大資料中心。

如需詳細資訊，請參閱虛擬機器和磁碟效能。

網路效能

在大部分情況下，網路效能就已足夠。 不過，如果您經常串流資料 (例如頻繁的水平擴大/縮小)，或存在大量的輸入/輸出資料移動，這可能會成為一個問題。 您可能需要評估 SKU 的網路效能。 例如，Standard_DS14_v2 SKU 支援 12,000 Mb/s，將此與計量中的位元組輸入/輸出進行比較：

Screenshot of network metrics.

如果僅在少數節點上看到網路提升，則可能有經常性分割區，且需要檢閱資料散發和/或存取模式是否有潛在的偏差。

  • 垂直擴大至支援更多網路 I/O 的不同 SKU。
  • 透過新增更多節點來水平擴大叢集。

太多已連線的用戶端

應規劃並佈建部署，以支援應用程式所需延遲需要的最大平行要求數目。 對於指定的部署，向系統引入超過最低閾值的更多負載會增加整體延遲。 監視已連線的用戶端數目，以確保不超過可容忍的限制。

Screenshot of connected client metrics.

磁碟空間

在大部分情況下，由於預設部署已針對 IOPS 進行最佳化，因此有足夠的磁碟空間，這會導致磁碟使用率較低。 不過，我們還是建議偶爾檢閱磁碟空間計量。 Cassandra 會累積大量磁碟，然後在觸發壓縮時減少磁碟。 因此，請務必檢閱較長期間內的磁碟使用量，以建立趨勢，例如壓縮無法復原空間。

注意

為確保進行壓縮的可用空間，磁碟使用率應維持在 50% 左右。

如果僅在少數節點上看到此行為，則可能有經常性分割區，且需要檢閱資料散發和/或存取模式是否有潛在的偏差。

  • 新增更多磁碟，但請注意 SKU 所強加的 IOPS 限制
  • 水平擴大叢集

JVM 記憶體

我們的預設公式會將 VM 記憶體的一半指派給 JVM，上限為 31 GB，在大部分情況下，這在效能與記憶體之間取得良好的平衡。 某些工作負載，特別是頻繁進行跨分割區讀取或範圍掃描的工作負載，可能會面臨記憶體挑戰。

在大部分情況下，JAVA 記憶體回收行程會有效地回收記憶體，但特別是如果 CPU 通常超過 80%，則沒有足夠的 CPU 週期供記憶體回收行程使用。 因此，任何 CPU 效能問題都應該在記憶體問題之前予以解決。

如果 CPU 暫留在 70% 以下，且記憶體回收無法回收記憶體，則您可能需要更多 JVM 記憶體。 如果您使用記憶體有限的 SKU，更是如此。 在大部分情況下，您需要檢閱查詢和用戶端設定，並減少 CQL 查詢中的 fetch_size 以及 limit 中選擇的內容。

如果您確實需要更多記憶體，您可以：

  • 提出請求，讓我們為您增加 JVM 記憶體設定
  • 垂直擴大至具有更多可用記憶體的 SKU

標記

我們使用 reaper 每七天執行一次修復，它會移除 TTL 已過期的資料列 (稱為「標記」)。 某些工作負載進行較頻繁的刪除，並且會在 Cassandra 日誌中看到類似 Read 96 live rows and 5035 tombstone cells for query SELECT ...; token <token> (see tombstone_warn_threshold) 的警告，甚至會出現指出由於過多標記而無法完成查詢的錯誤。

如果查詢未完成，則短期風險降低是將 Cassandra 組態中的 tombstone_failure_threshold 從預設值 100,000 增加到更高的值。

除此之外，建議您檢閱 keyspac 上的 TTL，並且可能每天執行修復，以清除更多標記。 如果 TTL 很短 (例如不到兩天)，並且資料快速流入並被刪除，建議您檢閱壓縮策略並偏向採用Leveled Compaction Strategy。 在某些情況下，這類動作可能表示需要檢閱資料模型。

批次警告

您可能會在 CassandraLogs 中遇到此警告，並可能發生相關的失敗：

Batch for [<table>] is of size 6.740KiB, exceeding specified threshold of 5.000KiB by 1.740KiB.

在此情況下，您應該檢閱查詢，以保持低於建議的批次大小。 在極少數情況下，作為短期風險降低，您可以將 Cassandra 組態中的 batch_size_fail_threshold_in_kb 從預設值 50 增加到更高的值。  

大型分割區警告

您可能會在 CassandraLogs 中遇到此警告：

Writing large partition <table> (105.426MiB) to sstable <file>

這表示資料模型中存在問題。 以下是一篇堆疊溢位文章，其中包含更多的詳細資料。 這可能會導致嚴重的效能問題，而且必須予以解決。

專業最佳化

壓縮

Cassandra 允許在建立資料表時選取適當的壓縮演算法 (請參閱壓縮)。預設值為 LZ4，非常適合輸送量和 CPU，但會消耗較多磁碟空間。 使用 Zstd (Cassandra 4.0 和更高版本) 可節省約 12% 的空間，同時 CPU 額外負荷最小。

最佳化 Memtable 堆積空間

我們的預設值是使用 1/4 的 JVM 堆積作為 cassandra.yaml 中的 memtable_heap_space。 對於寫入導向的應用程式和/或記憶體較小的 SKU，這可能會導致頻繁排清和片段化 Sstable，因此需要更多壓縮。 在這種情況下，增加到至少 4048 可能會有所幫助，但需要仔細進行基準測試，以確保其他作業 (例如，讀取) 不受影響。

下一步

在本文中，我們列出一些實現最佳效能的最佳做法。 您現在可以開始使用叢集：

使用 Azure 入口網站建立叢集