Azure Managed Instance for Apache Cassandra 是純開放原始碼 Apache Cassandra 叢集的完全受控服務。 服務也允許根據每個工作負載的特定需求來覆寫設定。 此功能可在需要時提供最大的彈性和控制。 本文提供如何最佳化效能的秘訣。
最佳設定和組態
復寫因數、磁碟數目、節點數目和產品層
Azure 在大多數地區支援三個可用性區域。 適用於 Apache Cassandra 的 Azure 受控實例會將可用性區域對應到機架。 建議您選擇高基數的分割區索引鍵以避免常用資料分割。 為了達到最佳可靠性與容錯層級，強烈建議您設定複寫因數 3。 我們也建議您將復寫因數的倍數指定為節點數目。 例如，使用 3、6、9 等。
Azure 會針對您布建的磁碟數目使用RAID 0。 為了獲得最佳的每秒輸入/輸出作業數 (IOPS)，請檢查您選擇的產品層上的最大 IOPS 以及 P30 磁碟的 IOPS。 例如，Standard_DS14_v2 產品級別支援 51,200 個未快取 IOPS。 單一 P30 磁碟的基底效能為 5,000 IOPS。 四個磁碟達到 20,000 個 IOPS，遠低於機器的性能上限。
我們強烈建議針對產品層級和磁碟數目，對工作負載進行廣泛的基準檢驗。 基準檢驗對於只有八個核心的產品層來說特別重要。 我們的研究表明，八核心 CPU 僅適用於最不要求最少的工作負載。 大部分的工作負載至少需要 16 個核心才能正確執行。
分析與交易式工作負載
交易式工作負載通常需要針對低延遲優化的數據中心。 分析工作負載通常會使用更複雜的查詢，這需要較長的時間才能執行。 在大部分情況下，您想要使用獨立的數據中心：
- 一個針對低延遲進行優化。
- 其中一個已針對分析工作負載進行優化。
針對分析工作負載進行最佳化
建議您針對分析工作負載套用下列 cassandra.yaml 設定。 如需如何套用這些設定的詳細資訊，請參閱 更新 Cassandra 組態。
逾時
| 價值觀 | Cassandra MI 預設值 | 分析工作負載建議 |
|---|---|---|
read_request_timeout_in_ms |
5,000 | 1萬 |
range_request_timeout_in_ms |
1萬 | 20,000 |
counter_write_request_timeout_in_ms |
5,000 | 1萬 |
cas_contention_timeout_in_ms |
1,000 | 二千 |
truncate_request_timeout_in_ms |
60,000 | 120,000 |
slow_query_log_timeout_in_ms |
500 | 1,000 |
roles_validity_in_ms |
二千 | 120,000 |
permissions_validity_in_ms |
二千 | 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 計量，請從 Azure 入口網站的 [ 監視] 區段底下，開啟 [ 計量] 索引卷標 。
針對實際的 CPU 檢視，請新增篩選，並使用 Usage kind=usage_idle 來分割屬性。 如果此值低於 20%，請套用分割以取得所有使用類型使用量。
如果大多數節點的 CPU 使用率長期高於 80%，則資料庫將超載，進而造成多個用戶端逾時。 在此案例中，建議您採取下列動作：
- 垂直擴展到擁有更多 CPU 核心的產品層級，特別是在核心數只有 8 個或更少的情況下。
- 藉由新增更多節點來水平擴展。 如先前所述，節點數目應該是複寫因數的倍數。
如果只有少數節點的CPU偏高，但對其他節點而言則為低，表示熱分區。 此案例需要進一步調查。
使用 Azure 入口網站、Azure CLI 和 Azure Resource Manager 範本 （ARM 範本） 部署來支援變更產品層。 您可以部署或編輯 ARM 樣本，並以下列其中一個值取代產品層：
Standard_E8s_v4Standard_E16s_v4Standard_E20s_v4Standard_E32s_v4Standard_DS13_v2Standard_DS14_v2Standard_D8s_v4Standard_D16s_v4Standard_D32s_v4Standard_L8s_v3Standard_L16s_v3Standard_L32s_v3Standard_L8as_v3Standard_L16as_v3Standard_L32as_v3
目前，我們不支援跨產品系列轉換。 例如，如果您目前擁有 Standard_DS13_v2 且想要升級至較大的產品，例如 Standard_DS14_v2，則無法使用此選項。 開啟支援票證以要求升級至較高的產品。
磁碟效能
服務會在允許 高載 IOPS 的 Azure P30 受控磁碟上執行。 涉及磁碟相關的效能瓶頸時，需要仔細監視。 在此情況下，請務必檢閱 IOPS 計量。
如果指標顯示下列其中一個或所有特性，您可能需要進行擴展：
- 您的指標始終高於或等於 IOPS 基準值。 請記得將每個節點的磁碟數目乘以 5,000 IOPS，以取得數位。
- 您的計量始終高於或等於產品層所允許的最大寫入 IOPS。
- 您的產品層支援快取的儲存空間 (直接寫入式快取)，且此數字小於受控磁碟所提供的 IOPS。 此值是讀取 IOPS 的上限。
如果您發現只有少數節點的 IOPS 升高，則您可能有經常性分割區，且需要檢閱資料是否有潛在的偏差。
如果您的 IOPS 低於您的產品層所支援，但高於或等於磁碟 IOPS，請採取下列動作：
- 新增更多節點以擴展數據中心。
如果您的 IOPS 達到產品層支援的上限，您可以：
- 升級至支援更多 IOPS 的不同產品等級。
- 新增更多節點以擴展數據中心。
如需詳細資訊，請參閱 虛擬機和磁碟效能。
網路效能
一般而言，網路效能就已足夠。 如果您經常串流數據，例如頻繁的水平擴展/縮減，或有大量進入/退出數據流動，這種效能可能成為問題。 您可能需要評估產品層的網路效能。 例如， Standard_DS14_v2 產品層支援 12,000 Mb/秒。 將計量中的位元組輸入和輸出與此值進行比較。
如果您發現只有少數節點的網路流量升高，則您可能有經常性分割區。 檢查您的數據分佈和存取模式，是否存在潛在的偏斜。
- 透過支援更多的網路 I/O 來垂直擴大到不同的產品層。
- 透過新增更多節點來水平擴大叢集。
太多已連線的用戶端
規劃並進行部署，以支援達到應用程式所需延遲的最大平行請求數量。 對於特定部署，將更多負載引入到高於最低閾值的系統會增加整體延遲。 監視連線的用戶端數目，以確保這種情況不會超過可容忍的限制。
磁碟空間
在大部分情況下，有足夠的磁碟空間。 默認部署已針對 IOPS 優化，這會導致磁碟使用率低。 不過，我們建議您偶爾檢閱磁碟空間計量。 Cassandra 會累積許多磁碟，然後在觸發壓縮時減少磁碟。 務必檢查長期磁碟使用情況，以建立趨勢，例如在壓縮過程中無法回收空間的情況下。
附註
為了確保壓縮的可用空間，請將磁碟使用率保持在大約 50%。
如果您僅在少數節點上看到此行為，可能是因為存在熱分區。 檢查您的數據分佈和存取模式，是否存在潛在的偏斜。
- 新增更多磁碟，但請注意您的產品層所強加的 IOPS 限制。
- 水平擴展叢集。
JVM 記憶體
我們的預設公式會將虛擬機記憶體的一半指派給 Java 虛擬機器 （JVM），上限為 31 GB。 在大部分情況下，這種方法在效能和記憶體之間是很好的平衡。 某些工作負載，特別是具有頻繁跨分割讀取或範圍掃描的工作負載，可能會受到記憶體挑戰。
在大部分情況下，Java 垃圾回收器會有效地回收記憶體。 如果 CPU 使用率經常高於 80%，則表示記憶體回收行程沒有足夠的 CPU 週期。 檢查任何記憶體問題之前，請先解決 CPU 效能問題。
如果 CPU 暫留在 70% 以下，而垃圾收集無法回收記憶體，您可能需要更多 JVM 記憶體。 如果您在具有有限記憶體的產品層上，可能需要更多 JVM 記憶體。 在大部分情況下，您需要檢閱您的查詢和用戶端設定，並減少 Cassandra Query Language (CQL) 查詢中的 fetch_size 以及 limit 中選擇的內容。
如果您需要更多記憶體，您可以：
- 垂直調整至具有更多可用記憶體的產品層。
標記
我們每隔七天使用 Reaper 執行修復，以移除存活時間（TTL）過期的數據列。 這些行稱為 墓碑。 某些工作負載會更頻繁地刪除，並在 Cassandra 記錄中顯示警告 Read 96 live rows and 5035 tombstone cells for query SELECT ...; token <token> (see tombstone_warn_threshold) 。 某些錯誤表示查詢因過多的墓碑而無法完成。
如果查詢未完成，則短期緩和措施是將 tombstone_failure_threshold 設定中的值從預設 100,000 增加到較高的值。
我們也建議您檢閱 keyspace 上的 TTL，並盡可能每天執行修復以清除更多的墓碑。 如果 TTL 很短 (例如不到兩天)，並且資料快速流入並被刪除，建議您檢閱壓縮策略並偏向採用 Leveled Compaction Strategy。 在某些情況下，這類動作可能表示需要檢閱數據模型。
批次警告
您可能會在 CassandraLogs 中遇到下列警告，並可能發生相關的失敗：
Batch for [<table>] is of size 6.740KiB, exceeding specified threshold of 5.000KiB by 1.740KiB.
檢閱您的查詢以保持低於建議的批次大小。 在罕見的情況下，作為短期緩解措施，將 batch_size_fail_threshold_in_kb 組態中的預設值從 50 增加到 更高的值。
大型分割區警告
您可能會在 CassandraLogs 中遇到下列警告：
Writing large partition <table> (105.426MiB) to sstable <file>
此訊息指出數據模型中的問題。 如需詳細資訊，請參閱此 Stack Overflow 文章。 此問題可能會導致嚴重的效能問題，而且必須加以解決。
專業最佳化
壓縮
Cassandra 允許在建立數據表時選取適當的壓縮演算法。 默認值為 LZ4，非常適合輸送量和 CPU，但會耗用更多磁碟空間。 使用 Zstandard （Cassandra 4.0 和 up） 可節省大約 12 個% 空間，而 CPU 額外負荷最小。
優化記憶體表堆積空間
預設情況下，會將 JVM 堆積區的四分之一用於 檔案中的 cassandra.yaml。 對於寫入導向的應用程式或在具有少量記憶體的產品層上，此問題可能會導致頻繁的排清和碎片化的 sstables，進而需要更多壓縮。 增加至至少 4,048 可能是個好主意。 這種方法需要仔細的基準檢驗，以確保其他作業（例如讀取）不會受到影響。