Share via

Azure 上任務關鍵性工作負載的資料平臺考慮

  • 發行項

選取有效的應用程式資料平臺是進一步重要的決策領域，對於其他設計領域具有遠遠的影響。 Azure 最終提供許多關聯式、非關聯式和分析資料平臺，這在功能上有很大的差異。 因此，重要非功能需求必須與其他決策因素一起完整考慮，例如一致性、操作性、成本和複雜度。 例如，在多區域寫入設定中運作的能力，對於全球可用平臺的適用性而言，會有重大影響。

此設計區域會擴充 應用程式設計，並提供重要考慮和建議，以通知選取最佳的資料平臺。

重要

本文是 Azure Well-Architected 任務關鍵性工作負載 系列的一部分。 如果您不熟悉此系列，建議您從 什麼是任務關鍵性工作負載開始？

四個巨量資料與巨量資料

「四個巨量資料」提供架構，以進一步瞭解高可用性資料平臺的必要特性，以及如何使用資料來最大化商業價值。 因此，本節將探討如何在概念層級套用磁片區、速度、多樣性和 Veracity 特性，以協助使用適當的資料技術設計資料平臺。

  • Volume：要通知儲存體容量和階層處理需求的資料量，也就是資料集的大小。
  • V位置：處理資料的速度，可以是批次或連續資料流程，也就是流程的速率。
  • Vriety：資料的組織與格式、擷取結構化、半結構化和非結構化格式 ，也就是跨多個存放區或類型的資料。
  • Veracity：包含治理和資料品質保證的已考慮資料集的證明和監管，也就是資料的精確度。

設計考量

磁碟區

  • 現有的 (，如果任何) 和預期的未來資料量，根據預測的資料成長率符合商務目標和計畫。

    • 資料磁片區應包含資料本身和索引、記錄、遙測和其他適用的資料集。
    • 大型業務關鍵性與任務關鍵性應用程式通常會每天產生並儲存大量 (GB 和 TB) 。
    • 與資料擴充相關的成本可能會造成重大影響。

  • 資料量可能會因為變更商務情況或維護程式而變動。

  • 資料量可能會對資料平臺查詢效能造成重大影響。

  • 與達到資料平臺磁片區限制相關的影響可能很深。

    • 這會導致停機嗎？若是如此，則為多久？
    • 什麼是風險降低程式？和 風險降低是否需要應用程式變更？
    • 資料遺失是否有風險？

  • 使用記錄建立或修改，例如存留時間 (TTL) 等功能，可用來在經過的時間之後自動刪除記錄來管理資料成長。

    • 例如，Azure Cosmos DB 提供內建 的 TTL 功能。

速度

  • 從各種應用程式元件發出資料的速度，以及需要認可和擷取資料速度的輸送量需求，對於判斷關鍵工作負載案例的最佳資料技術至關重要。

    • 輸送量需求的本質會因工作負載案例而有所不同，例如大量讀取或大量寫入的需求。
      • 例如，分析工作負載通常需要滿足大量的讀取輸送量。
    • 所需的輸送量為何？ 輸送量預期如何成長？
    • 參考負載層級下 P50/P99 的資料延遲需求為何？

  • 支援無鎖定設計、索引微調和一致性原則等功能對於達到高輸送量至關重要。

    • 優化高輸送量的組態會產生取捨，這應該完全瞭解。
    • 負載層級持續性和傳訊模式，例如 CQRS 和事件來源，可用來進一步優化輸送量。

  • 負載層級會針對許多應用程式案例自然變動，而自然尖峰需要足夠的彈性來處理可變需求，同時維持輸送量和延遲。

    • 敏捷式延展性是有效支援可變輸送量和負載層級的關鍵，不需要過度布建容量層級。
      • 讀取和寫入輸送量都必須根據應用程式需求和負載進行調整。
      • 垂直和水準縮放作業都可以套用，以回應變更的負載層級。

  • 輸送量下降的影響可能會根據工作負載案例而有所不同。

    • 是否有連線中斷？
    • 當控制平面繼續運作時，個別作業是否會傳回失敗碼？
    • 資料平臺是否會啟用節流，如果是多久？

  • 使用主動-主動地理分佈的基本應用程式設計建議，會針對資料一致性帶來挑戰。

    • 對於完整的 ACID 交易式語意和傳統鎖定行為，一致性和效能之間會有取捨。
      • 將寫入延遲降到最低，成本為數據一致性。

  • 在多重區域寫入設定中，所有複本之間都必須同步處理和合併變更，並在必要時解決衝突，這可能會影響效能層級和延展性。

  • 唯讀複本 (區域內和區域間) ，可用來將往返延遲降到最低，以及散發流量以提升效能、輸送量、可用性和延展性。

  • 快取層可用來增加讀取輸送量，以改善使用者體驗和端對端用戶端回應時間。

    • 您必須考慮快取到期時間和原則，以優化資料最近性。

多樣化

  • 資料模型、資料類型、資料關聯性和預定的查詢模型將大幅影響資料平臺決策。

    • 應用程式是否需要關聯式資料模型，也可以支援變數架構或非關聯式資料模型？
    • 應用程式如何查詢資料？ 查詢是否相依于資料庫層概念，例如關聯式聯結？ 或者，應用程式是否提供這類語意？

  • 應用程式所考慮的資料集本質可能會有所不同，例如影像和影片等非結構化內容，或更多結構化檔案，例如 CSV 和 Parquet。

    • 複合應用程式工作負載通常會有不同的資料集和相關聯的需求。

  • 除了關聯式或非關聯式資料平臺之外，圖形或索引鍵值資料平臺也可能適用于特定資料工作負載。

    • 某些技術符合變數架構資料模型，其中資料項目在語意上類似和/或一起儲存和查詢，但結構上不同。

  • 在微服務架構中，個別的應用程式服務可以使用不同的案例優化資料存放區來建置，而不是視單一整合型資料存放區而定。

    • SAGA之類的設計模式可以套用，以管理不同資料存放區之間的一致性和相依性。
      • 資料庫間直接查詢可能會強制共置條件約束。
    • 使用多個資料技術會增加管理額外負荷的程度，以維護內含的技術。

  • 每個 Azure 服務的功能集會因語言、SDK 和 API 而有所不同，這可大幅影響可套用的組態調整層級。

  • 優化與資料模型和內含資料類型的對齊功能，將大幅影響資料平臺決策。

    • 查詢層，例如預存程式和物件關聯式對應器。
    • 語言中性查詢功能，例如安全的 REST API 層。
    • 商務持續性功能，例如備份和還原。

  • 分析資料存放區通常支援各種資料類型的 Polyglot 儲存體。

    • Apache Spark 等分析執行時間環境可能會有分析 Polyglot 資料結構的整合限制。

  • 在企業內容中，使用現有的流程和工具，以及技能的持續性，可能會對資料平臺設計和選取資料技術產生重大影響。

準確性

  • 必須考慮幾個因素來驗證應用程式內資料的正確性，而這些因素的管理可能會對資料平臺的設計產生重大影響。

    • 資料一致性。
    • 平臺安全性功能。
    • 資料控管。
    • 變更管理和架構演進。
    • 資料集之間的相依性。

  • 在任何具有多個資料複本的分散式應用程式中，一致性和延遲之間會有取捨，如 CAP 和 PACELC 定理所表示。

    • 當讀取器和寫入器相異散發時，應用程式必須選擇傳回最快速可用的資料項目版本，即使與剛完成的寫入 (更新) 另一個複本中的資料項目更新，或資料項目的最新版本，這可能會導致額外的延遲來判斷並取得最新狀態。
    • 您可以在平台層級或個別資料要求層級設定一致性和可用性。
    • 如果資料是從最接近使用者之複本提供的資料，其不會反映不同複本的最新狀態，則使用者體驗為何？亦即，應用程式是否可能支援過時的資料？

  • 在多重區域寫入內容中，當兩個不同的寫入複本中變更相同的資料項目之後，才能複寫變更，就會建立必須解決的衝突。

    • 您可以套用標準化的衝突解決原則，例如「上次寫入 Wins」，或套用自訂邏輯的自訂策略。

  • 安全性需求的實作可能會對輸送量或效能造成負面影響。

  • 如有必要，可以使用用戶端加密在應用層實作待用加密和/或使用伺服器端加密的資料層。

  • Azure 支援各種加密模型，包括使用服務管理金鑰的伺服器端加密、金鑰保存庫中的客戶自控金鑰，或客戶控制硬體上的客戶自控金鑰。

    • 使用用戶端加密金鑰，可以在金鑰保存庫或其他安全位置中管理金鑰。

  • MACsec (IEEE 802.1AE MAC) 資料連結加密可用來保護 Microsoft 骨幹網路上 Azure 資料中心之間移動的所有流量。

    • 封包會在傳送之前加密並解密，防止實體「中間人」或探查/線路套用攻擊。

  • 資料平面和控制平面的驗證和授權。

    • 資料平臺如何驗證和授權應用程式存取和操作存取？

  • 透過監視平臺健康情況和資料存取的可觀察性。

    • 如何針對可接受的作業界限以外的條件套用警示？

設計建議

磁碟區

  • 確保與有機成長相關聯的未來資料量不會超過資料平臺功能。

    • 預測符合商務計畫的資料成長率，並使用已建立的速率來通知持續容量需求。
    • 比較匯總和個別資料記錄磁片區與資料平臺限制。
    • 如果在例外狀況下達到限制的風險，請確定作業緩和措施已就緒，以防止停機和資料遺失。

  • 監視資料量，並針對容量模型進行驗證，並考慮調整限制和預期的資料成長率。

    • 確定調整作業符合儲存體、效能和一致性需求。
    • 當新的縮放單位引進時，可能需要複寫基礎資料，這可能需要一段時間，而且可能會在複寫發生時造成效能負面影響。 因此，如果可能的話，請確定這些作業會在關鍵上班時間之外執行。

  • 定義應用程式資料層，根據使用量和重要性來分類資料集，以利移除或卸載較舊的資料。

    • 請考慮將資料集分類為「熱」、「暖」和「冷」 (「封存」) 層。
      • 例如，基礎參考實作會使用 Azure Cosmos DB 來儲存應用程式主動使用的「熱」資料，而 Azure 儲存體用於「冷」作業資料以供分析之用。

  • 設定內部處理常式，以優化資料成長並提升資料效率，例如查詢效能，以及管理資料擴充。

    • 針對不再需要且沒有長期分析值的資料，設定存留時間 (TTL) 到期日。
      • 驗證舊資料可以安全地分層至次要儲存體，或直接刪除，而不會對應用程式造成負面影響。
    • 將非關鍵性資料卸載至次要冷儲存體，但維護其分析價值，並滿足稽核需求。
    • 收集資料平臺遙測和使用統計資料，讓 DevOps 小組能夠持續評估維護需求和「正確大小」的資料存放區。

  • 搭配微服務應用程式設計，請考慮平行使用多個不同的資料技術，並針對特定工作負載案例和磁片區需求提供優化的資料解決方案。

    • 避免建立單一整合型資料存放區，其中資料量從擴充可能難以管理。

速度

  • 資料平臺原本必須設計並設定為支援高輸送量，並將工作負載分成不同的內容，以使用案例優化的資料解決方案將效能最大化。

    • 確保每個資料案例的讀取和寫入輸送量都可以根據預期的負載模式進行調整，並有足夠的容錯度來達到非預期的變異數。
    • 將交易和分析作業等不同資料工作負載分成不同的效能內容。

  • 透過使用非同步非封鎖傳訊的負載層級，例如使用 CQRS 或 事件來源 模式。

    • 寫入要求之間可能會有延遲，以及當新的資料可供讀取時，這可能會對使用者體驗造成影響。
      • 在關鍵商務需求的內容中，必須瞭解並接受此影響。

  • 確定敏捷式延展性以支援可變輸送量和負載層級。

    • 如果負載層級高度變動，請考慮過度布建容量層級，以確保維持輸送量和效能。
    • 當無法維護輸送量時，測試並驗證複合應用程式工作負載的影響。

  • 使用自動化調整作業來設定 Azure 原生資料服務的優先順序，以利快速回應負載層級的變動。

    • 根據服務內部和應用程式設定閾值設定自動調整。
    • 調整應該在與業務需求一致的時間範圍內起始和完成。
    • 對於需要手動互動的案例，請建立可觸發的自動化操作「劇本」，而不是執行手動操作動作。
      • 請考慮是否可以將自動化觸發程式套用為後續工程投資的一部分。

  • 根據 P50/P99 延遲需求監視應用程式資料讀取和寫入輸送量，並符合應用程式容量模型。

  • 資料平臺或應用層應適當地處理過多輸送量，並由健康情況模型擷取以用於作業表示。

  • 實作「經常性」資料案例的快取，以將回應時間降到最低。

    • 針對快取到期和保留套用適當的原則，以避免資料成長失控。
      • 備份資料變更時，快取專案過期。
      • 如果快取到期是嚴格「存留時間」 (TTL) ，則必須瞭解服務過期資料的影響和客戶體驗。

多樣化

  • 與雲端和 Azure 原生設計的原則一致，強烈建議優先使用受控 Azure 服務以減少作業和管理複雜度，並利用 Microsoft 的未來平臺投資。

  • 與鬆散結合微服務架構的應用程式設計原則一致，允許個別服務使用不同的資料存放區和案例優化資料技術。

    • 識別應用程式將針對特定工作負載案例處理的資料結構類型。
    • 避免在單一整合型資料存放區上建立相依性。
      • 請考慮資料存放區間相依性的 SAGA 設計模式。

  • 驗證所選資料技術是否有可用的必要功能。

    • 請確定支援必要的語言和 SDK 功能。 並非所有功能都以相同方式提供給每個語言/SDK。

準確性

  • 透過將資料移至應用程式端點，採用多區域資料平臺設計，並將複本分散到區域，以達到最大可靠性、可用性和效能。

    • 將資料複本分散到區域內可用性區域 (AZ) (，或使用區域備援服務層級) ，將區域內的可用性最大化。

  • 其中一致性需求允許，請使用多區域寫入資料平臺設計，將整體全域可用性和可靠性最大化。

    • 在兩個不同的寫入複本中變更相同的資料項目時，請考慮衝突解決的商務需求，然後才能複寫變更，進而建立衝突。
      • 盡可能使用標準化衝突解決原則，例如「最後一個成功」
        • 如果需要具有自訂邏輯的自訂策略，請確定已套用 CI/CD DevOps 做法來管理自訂邏輯。

  • 透過持續傳遞程式中的混亂測試，測試和驗證備份和還原功能，以及容錯移轉作業。

  • 執行效能基準測試，以確保輸送量和效能需求不會受到包含必要安全性功能的影響，例如加密。

    • 請確定持續傳遞程式會針對已知的效能效能評定考慮負載測試。

  • 套用加密時，強烈建議使用服務管理的加密金鑰來減少管理複雜度。

    • 如果客戶管理的金鑰有特定的安全性需求，請確定會套用適當的金鑰管理程式，以確保所有已考慮金鑰的可用性、備份和輪替。

注意

與更廣泛的組織實作整合時，請務必在應用程式設計中針對資料平臺元件的布建和作業套用以應用程式為中心的方法。

更具體來說，若要將可靠性最大化，個別資料平臺元件必須透過可能包含其他應用程式元件的作業動作，適當地回應應用程式健康情況。 例如，在需要其他資料平臺資源的案例中，可能需要根據容量模型調整資料平臺和其他應用程式元件，可能透過布建額外的縮放單位。 如果集中式作業小組有硬式相依性，以解決與隔離資料平臺相關的問題，則此方法最終會受到限制。

最後，使用集中式資料服務 (，也就是中央 IT DBaaS) 引進了可大幅阻礙透過大量未整合管理體驗而大幅阻礙靈活度的操作瓶頸，而且應該在任務關鍵性或業務關鍵性內容中避免。

其他參考資料

Azure 應用程式架構指南中提供其他資料平臺指引。

全域分散的多區域寫入資料存放區

為了完全容納應用程式設計的全域分散式主動-主動期望，強烈建議考慮分散式多區域寫入資料平臺，其中會同步處理和合併所有複本之間的可寫入複本變更，並在必要時解決衝突。

重要

微服務可能不需要分散式多區域寫入資料存放區，因此應該考慮每個工作負載案例的架構內容和商務需求。

Azure Cosmos DB 提供全域散發且高可用性的 NoSQL 資料存放區，提供多區域寫入和無法立即恢復一致性。 因此，本節中的設計考慮和建議將著重于最佳的 Azure Cosmos DB 使用量。

設計考量

Azure Cosmos DB

  • Azure Cosmos DB 會將資料儲存在容器內，這些容器是以資料列為基礎的交易式存放區，其設計目的是允許以毫秒為單位的回應時間快速交易式讀取和寫入。

  • Azure Cosmos DB 支援具有不同功能集的多個不同 API，例如 SQL、Cassandra 和 MongoDB。

    • 第一方適用于 NoSQL 的 Azure Cosmos DB 提供最豐富的功能集，而且通常是 API，其中新功能會先可供使用。

  • Azure Cosmos DB 支援 閘道和直接連線模式，其中 Direct 可協助透過 TCP 連線到後端 Azure Cosmos DB 複本節點，以提升具有較少網路躍點的效能，而閘道則提供前端閘道節點的 HTTPS 連線能力。

    • 只有在使用適用于 NoSQL 的 Azure Cosmos DB，且目前僅在 .NET 和 JAVA SDK 平臺上支援時，才能使用直接模式。

  • 在已啟用可用性區域的區域內，Azure Cosmos DB 提供 可用性區域 (AZ) 備 援支援，以支援區域內的區域性失敗高可用性和復原能力。

  • Azure Cosmos DB 會在單一區域內維護四個數據複本，而且當啟用 AZ) 備援可用性 (區域時，Azure Cosmos DB 可確保資料複本位於多個 AZ，以防止區域性失敗。

    • Paxos 共識通訊協定會套用，以在區域內的複本之間達成仲裁。

  • Azure Cosmos DB 帳戶可以輕鬆地設定為跨多個區域複寫資料，以降低單一區域無法使用的風險。

    • 您可以使用單一區域寫入或多重區域寫入來設定複寫。
      • 使用單一區域寫入時，主要「中樞」區域可用來提供所有寫入，如果此「中樞」區域變成無法使用，就必須發生容錯移轉作業，才能將另一個區域升階為可寫入。
      • 透過多區域寫入，應用程式可以寫入任何已設定的部署區域，以複寫所有其他區域之間的變更。 如果區域無法使用，則會使用其餘區域來提供寫入流量。

  • 在多區域寫入組態中，可能會發生寫入器同時更新多個區域中相同專案的 更新 (插入、取代、刪除) 衝突 。

  • Azure Cosmos DB 提供兩個衝突解決原則，可套用以自動解決衝突。

    • 上次寫入 Wins (LWW) 會使用系統定義的時間戳記 _ts 屬性作為衝突解決路徑來套用時間同步處理時鐘通訊協定。 如果衝突解決路徑的最高值衝突專案會成為勝出者，而且如果多個專案具有相同的數值，則系統會選取勝出項目，讓所有區域可以交集到相同版本的已認可專案。
      • 刪除衝突時，刪除的版本一律會優先于插入或取代衝突，而不論衝突解決路徑值為何。
      • 「最後寫入為準」是預設的衝突解決原則。
      • 使用適用于 NoSQL 的 Azure Cosmos DB 時，自訂數值屬性，例如自訂時間戳記定義可用來解決衝突。
    • 自訂解決原則可讓應用程式定義的語意使用偵測到衝突時自動叫用的已註冊合併預存程式來協調衝突。
      • 系統只針對合併程序的執行提供一次保證 (為認可通訊協定的一部分)。
      • 自訂衝突解決原則僅適用于適用于 NoSQL 的 Azure Cosmos DB，而且只能在容器建立期間設定。

  • 在多區域寫入設定中，單一 Azure Cosmos DB 'hub' 區域相依于執行所有衝突解決，並套用 Paxos 共識通訊協定，以在中樞區域內的複本之間達成仲裁。

    • 平臺會提供訊息緩衝區，以在中樞區域內寫入衝突以載入層級，並提供暫時性錯誤的備援。
      • 緩衝區能夠儲存幾分鐘的寫入更新，需要共識。

Azure Cosmos DB 平臺的策略性方向是移除這個單一區域相依性，以在多區域寫入設定中解決衝突，利用 2 階段 Paxos 方法來取得全域層級和區域內的仲裁。

  • 主要「中樞」區域是由 Azure Cosmos DB 設定所在的第一個區域所決定。

    • 系統會針對其他衛星部署區域設定優先順序，以進行容錯移轉。

  • 跨邏輯和實體分割的資料模型和資料分割，在達到最佳效能和可用性方面扮演重要角色。

  • 使用單一寫入區域部署時，您可以根據考慮所有讀取區域複本的已定義容錯移轉優先順序，設定 Azure Cosmos DB 來 自動容錯移轉 。

  • Azure Cosmos DB 平臺提供的 RTO 是 ~10-15 分鐘，如果影響中樞區域的嚴重災害，則會擷取經過的時間來執行 Azure Cosmos DB 服務的區域性容錯移轉。

    • 此 RTO 也與多重區域寫入內容相關，因為相依于單一「中樞」區域以進行衝突解決。
      • 如果「中樞」區域變成無法使用，則在訊息緩衝區填滿之後，對其他區域的寫入將會失敗，因為除非服務容錯移轉並建立新的中樞區域，才會發生衝突解決。

Azure Cosmos DB 平臺的策略性方向是允許分割區層級容錯移轉，將 RTO 減少到 ~5 分鐘。

  • 復原點目標 (RPO) 和復原時間目標 (RTO) 可透過一致性層級進行設定，並在資料持久性和輸送量之間取捨。

    • Azure Cosmos DB 針對具有多區域寫入的寬鬆一致性層級，或 0 的 RPO 提供最低 RTO 0，以便與單一寫入區域進行強式一致性。

  • Azure Cosmos DB 提供 99.999% SLA ，以針對以多個 Azure 區域設定為可寫入的資料庫帳戶，提供讀取和寫入可用性。

    • SLA 是以每月執行時間百分比表示，其計算方式為 100% - 平均錯誤率。
    • 平均錯誤率定義為計費月份中每小時的錯誤率總和除以計費月份的時數總計，其中錯誤率是失敗要求總數除以指定一小時間隔期間的總要求數。

  • Azure Cosmos DB 提供 99.99% SLA，以在設定五個一致性層級時，針對範圍設定為單一 Azure 區域的資料庫帳戶提供輸送量、一致性、可用性和延遲。

    • 99.99% SLA 也適用于跨越四個寬鬆一致性層級任一設定之多個 Azure 區域的資料庫帳戶。

  • Azure Cosmos DB 中可以布建兩種類型的輸送量、標準和 自動調整，這些輸送量是使用每秒要求單位來測量 (RU/秒) 。

    • 標準輸送量會配置保證指定 RU/秒值所需的資源。
      • 標準會每小時支付布建輸送量的費用。
    • 自動調整會定義最大輸送量值，而 Azure Cosmos DB 會根據應用程式負載自動相應增加或減少，介於最大輸送量值與最大輸送量值的 10% 之間。
      • 自動調整會每小時計費，以取得耗用的最大輸送量。

  • 具有變數工作負載的靜態布建輸送量可能會導致節流錯誤，這會影響察覺到的應用程式可用性。

    • 自動調整可藉由啟用 Azure Cosmos DB 視需要相應增加，同時藉由在負載減少時相應減少來維持成本保護，以防止節流錯誤。

  • 當 Azure Cosmos DB 複寫到多個區域時，每個區域都會針對每個區域計費布建的要求單位 (RU) 。

  • 多區域寫入和單一區域寫入組態之間有顯著的成本差異，在許多情況下，可能會造成多宿主 Azure Cosmos DB 資料平臺成本禁止。

單一區域讀取/寫入 單一區域寫入 - 雙重區域讀取 雙重區域讀取/寫入
1 RU 2 RU 4 RU

單一區域寫入與多區域寫入之間的差異實際上小於上表所反映的 1：2 比例。 更具體來說，在單一寫入組態中，有與寫入更新相關聯的跨區域資料傳輸費用，與多區域寫入組態一樣不會擷取在 RU 成本內。

  • 已取用的儲存體會以一般費率計費，以指定小時所耗用的儲存體總 (GB) 。

  • Session 是預設且最廣泛使用的 一致性層級 ，因為會以與寫入相同的順序接收資料。

  • Azure Cosmos DB 支援透過Microsoft Entra身分識別或 Azure Cosmos DB 金鑰和資源權杖進行驗證，以提供重迭的功能。

Azure Cosmos DB 存取功能

  • 您可以使用金鑰或資源權杖來停用資源管理作業，只限制資料作業的金鑰和資源權杖，允許使用Microsoft Entra角色型存取控制 (RBAC) 進行更精細的資源存取控制。

    • 透過金鑰或資源權杖限制控制平面存取將會停用使用 Azure Cosmos DB SDK 之用戶端的控制平面作業，因此應該徹底 評估和測試。
    • disableKeyBasedMetadataWriteAccess設定可透過ARM 範本IaC 定義，或透過內建Azure 原則進行設定。

  • Microsoft Entra Azure Cosmos DB 中的 RBAC 支援適用于帳戶和資源控制平面管理作業。

  • Azure Cosmos DB 資源 (帳戶、資料庫和容器) 可以受到保護，以防止使用 資源鎖定進行不正確的修改或刪除。

    • 資源鎖定可以在帳戶、資料庫或容器層級設定。
    • 在 資源上設定的資源鎖定將會由所有子資源繼承。 例如，在 Azure Cosmos DB 帳戶上設定的資源鎖定，將會由帳戶內的所有資料庫和容器繼承。
    • 資源鎖定 僅適用于 控制平面作業， 且不會 防止資料平面作業，例如建立、變更或刪除資料。
    • 如果控制平面存取不受限制 disableKeyBasedMetadataWriteAccess ，則用戶端將能夠使用帳戶金鑰來執行控制平面作業。

  • Azure Cosmos DB 變更摘要提供 Azure Cosmos DB 容器中資料之變更的時間排序摘要。

    • 變更摘要只包含來源 Azure Cosmos DB 容器的插入和更新作業;不包含刪除。

  • 變更摘要可用來維護與應用程式所使用的主要容器不同的資料存放區，並持續更新來源容器的變更摘要所提供的目標資料存放區。

    • 變更摘要可用來填入次要存放區，以取得其他資料平臺備援或後續的分析案例。

  • 如果刪除作業會定期影響來源容器內的資料，則變更摘要所傳送的存放區將會不正確且無法改變已刪除的資料。

    • 虛 刪除 模式可以實作，以便資料記錄包含在變更摘要中。
      • 除了明確刪除資料記錄，而是藉由設定旗標 (來 更新 資料記錄，例如 IsDeleted ，) 表示專案被視為已刪除。
      • 變更摘要所提供的任何目標資料存放區都必須偵測並處理已刪除旗標設定為 True 的專案;必須刪除目標存放區中 現有的 資料記錄版本，而不是儲存虛刪除的資料記錄。
    • 簡短的存留時間 (TTL) 通常會與虛刪除模式搭配使用，讓 Azure Cosmos DB 會自動刪除過期的資料，但只有在變更摘要中將已刪除的旗標設定為 True 之後才會反映。
      • 完成原始刪除意圖，同時透過變更摘要傳播刪除。

  • Azure Cosmos DB 可以設定為 分析存放區，其會套用資料行格式來優化分析查詢，以解決傳統 ETL 管線所發生的複雜度和延遲挑戰。

  • Azure Cosmos DB 會定期自動備份資料，而不會影響效能或可用性，而且不需要耗用 RU/秒。

  • 您可以根據兩個不同的備份模式來設定 Azure Cosmos DB。

    • 定期 是所有帳戶的預設備份模式，其備份會定期進行，且資料會透過向支援小組建立要求來還原。
      • 預設定期備份保留期間為八小時，預設備份間隔為四小時，這表示預設只會儲存最新的兩個備份。
      • 備份間隔和保留期間可在帳戶內設定。
        • 最大保留期間會延長至一個月，且備份間隔下限為一小時。
        • 您必須將角色指派給 Azure「Cosmos DB 帳戶讀者角色」，才能設定備份儲存體備援。
      • 包含兩個備份複本，不需額外費用，但額外的備份會產生額外的成本。
      • 根據預設，定期備份會儲存在無法直接存取的個別 Geo-Redundant 儲存體 (GRS) 。
      • 執行 還原作業需要 支援要求， 因為客戶無法直接執行還原。
        • 開啟支援票證之前，備份保留期間應該在資料遺失事件八小時內至少增加七天。
      • 還原作業會建立復原資料的新 Azure Cosmos DB 帳戶。
        • 現有的 Azure Cosmos DB 帳戶無法用於還原
        • 根據預設，將會使用名為 <Azure_Cosmos_account_original_name>-restored<n> 的新 Azure Cosmos DB 帳戶。
          • 您可以調整此名稱，例如在刪除原始帳戶時重複使用現有的名稱。
      • 如果在資料庫層級布建輸送量，備份和還原將會在資料庫層級發生
        • 您無法選取要還原的容器子集。
    • 連續 備份模式允許還原到過去 30 天內的任何時間點。
      • 您可以執行還原作業，以傳回具有一秒細微性的特定時間點 (PITR) 。
      • 還原作業的可用視窗最多為 30 天。
        • 您也可以還原至資源具現化狀態。
      • 在 Azure Cosmos DB 帳戶所在的每個 Azure 區域中都會進行連續備份。
        • 連續備份會儲存在與每個 Azure Cosmos DB 複本相同的 Azure 區域中，使用 Locally-Redundant 儲存體 (LRS) 或區域備援儲存體， (ZRS) 支援可用性區域的區域。
      • 您可以使用如ARM 範本等Azure 入口網站或 IaC 成品來執行自助式還原。
      • 連續備份有數 個限制 。
        • 多區域寫入組態目前無法使用連續備份模式。
        • 目前只能針對適用于 NoSQL 的 Azure Cosmos DB 和適用于 MongoDB 的 Azure Cosmos DB 進行連續備份設定。
        • 如果容器已設定 TTL，則已超過其 TTL 的還原資料可能會 立即刪除
      • 還原作業會為時間點還原建立新的 Azure Cosmos DB 帳戶。
      • 連續備份和還原作業會有 額外的儲存體成本 。

  • 現有的 Azure Cosmos DB 帳戶可以從定期移轉至連續，但無法從連續移轉至定期;移轉是單向且無法回復的。

  • 每個 Azure Cosmos DB 備份都是由資料本身和設定詳細資料所組成，用於布建輸送量、編制索引原則、部署區域 () ，以及容器 TTL 設定。

  • 針對定期和連續方法不適合的案例，可以實作自訂備份和還原功能。

    • 自訂方法會產生顯著的成本和額外的系統管理額外負荷，因此應該瞭解並仔細評估。
      • 常見的還原案例應該建立模型，例如資料項目上的帳戶、資料庫、容器損毀或刪除。
      • 應實作內部處理常式，以防止備份擴展。
    • 您可以使用 Azure 儲存體或替代資料技術，例如替代的 Azure Cosmos DB 容器。
      • Azure 儲存體和 Azure Cosmos DB 提供與 Azure 服務的原生整合，例如Azure Functions和Azure Data Factory。

  • Azure Cosmos DB 檔代表實作自訂備份的兩個可能選項。

Azure Cosmos DB 用於許多 Azure 服務的設計內，因此 Azure Cosmos DB 的重大區域性中斷會對該區域內的各種 Azure 服務產生串聯效果。 對特定服務的精確影響，將取決於基礎服務設計如何使用 Azure Cosmos DB。

設計建議

Azure Cosmos DB

  • 使用 Azure Cosmos DB 作為需求允許的主要資料平臺。

  • 針對任務關鍵性工作負載案例，請在每個部署區域內設定具有寫入複本的 Azure Cosmos DB，以減少延遲並提供最大備援。

    • 將應用程式設定為 優先使用本機 Azure Cosmos DB 複 本進行寫入和讀取，以將應用程式負載、效能和區域 RU/秒耗用量優化。
    • 多區域寫入設定的成本相當高，而且應該只針對需要最大可靠性的工作負載案例設定優先順序。

  • 對於較不重要的工作負載案例，請在搭配全域分散式讀取複本使用可用性區域) 時，優先使用單一區域寫入組態 (，因為這可提供高階的資料平臺可靠性， (99.999% SLA 的讀取、99.995% SLA，以更吸引人的價格點) 。

    • 將應用程式設定為使用本機 Azure Cosmos DB 讀取複本來優化讀取效能。

  • 選取最佳的「中樞」部署區域，其中衝突解決會在多區域寫入組態中發生，而且所有寫入都會在單一區域寫入組態中執行。

    • 在選取主要區域時，請考慮相對於其他部署區域和相關聯的延遲距離，以及可用性區域支援等必要功能。

  • 使用 AZ 支援的所有部署區域中設定具有可用性區域的 Azure Cosmos DB (AZ) 備 援，以確保復原到區域內的區域性失敗。

  • 使用適用于 NoSQL 的 Azure Cosmos DB，因為它提供最完整的功能集，特別是在效能微調方面。

    • 替代 API 主要應該考慮移轉或相容性案例。
      • 使用替代 API 時，請驗證所選語言和 SDK 是否可使用必要的功能，以確保最佳的組態和效能。

  • 使用直接連線模式透過直接 TCP 連線到後端 Azure Cosmos DB 節點來優化網路效能，減少網路「躍點」數目。

Azure Cosmos DB SLA 的計算方式是平均失敗的要求，這可能不會直接與 99.999% 的可靠性層級錯誤預算一致。 針對 99.999% SLO 進行設計時，因此請務必規劃區域和多區域 Azure Cosmos DB 寫入無法使用功能，以確保後援儲存體技術會在失敗時定位，例如後續重新執行的持續性訊息佇列。

  • 定義邏輯和實體分割區之間的資料分割策略，以根據資料模型優化資料散發。

    • 將跨分割區查詢最小化。
    • 反復 測試並驗證 資料分割策略，以確保最佳效能。

  • 選取最佳分割區索引鍵。

    • 在集合內建立分割區索引鍵之後，就無法變更。
    • 分割區索引鍵應該是不會變更的屬性值。
    • 選取具有高基數的分割區索引鍵，具有各種不同的可能值。
    • 分割區索引鍵應該將 RU 耗用量和資料儲存體平均分散到所有邏輯分割區，以確保所有實體分割區的 RU 耗用量和儲存體分佈。
    • 對分割的資料行執行讀取查詢，以減少 RU 耗用量和延遲。

  • 編制索引 對於效能也很重要，因此請確定索引排除是用來減少 RU/秒和儲存體需求。

    • 只有針對查詢內篩選所需的欄位編制索引;設計最常使用述詞的索引。

  • 利用 Azure Cosmos DB SDK的內建錯誤處理、重試和更廣泛的可靠性功能。

  • 使用服務管理的加密金鑰來降低管理複雜度。

    • 如果客戶管理的金鑰有特定的安全性需求，請確定已套用適當的金鑰管理程式，例如備份和輪替。

  • 套用內建Azure 原則，以停用Azure Cosmos DB 金鑰型中繼資料寫入權限。

  • 讓 Azure 監視器 能夠收集重要計量和診斷記錄，例如布建的輸送量 (RU/秒) 。

    • 將 Azure 監視器作業資料路由傳送至 Azure Cosmos DB 專用的 Log Analytics 工作區，以及應用程式設計內的其他全域資源。
    • 使用 Azure 監視器計量來判斷應用程式流量模式是否適合自動調整。

  • 評估應用程式流量模式，以選取布建 輸送量類型的最佳選項。

    • 請考慮自動調整布建的輸送量，以自動相應放大工作負載需求。

  • 評估 Azure Cosmos DB 的 Microsoft 效能秘訣 ，以優化用戶端和伺服器端組態，以改善延遲和輸送量。

  • 使用 AKS 作為計算平臺時：針對需要大量查詢的工作負載，請選取已啟用加速網路的 AKS 節點 SKU，以減少延遲和 CPU 抖動。

  • 針對單一寫入區域部署，強烈建議您將 Azure Cosmos DB 設定為 自動容錯移轉。

  • 透過使用系統流程內的非同步非封鎖傳訊來載入層級，以將更新寫入 Azure Cosmos DB。

  • 設定 Azure Cosmos DB 帳戶以進行連續備份，以取得過去 30 天內復原點的細微度。

    • 請考慮在包含的資料或 Azure Cosmos DB 帳戶遭到刪除或損毀的情況下，使用 Azure Cosmos DB 備份。
    • 除非絕對必要，否則請避免使用自訂備份方法。

  • 強烈建議您將非生產資源和資料上的復原程式練習為標準商務持續性作業準備的一部分。

  • 定義 IaC 成品，以重新建立 Azure Cosmos DB 備份還原的組態設定和功能。

  • 評估並套用 Azure Cosmos DB 備份和復原的 Azure 安全性基準 控制指導方針。

  • 對於需要多重區域可用性的分析工作負載，請使用 Azure Cosmos DB 分析存放區，其會套用資料行格式以進行優化的分析查詢。

關聯式資料技術

對於高度關聯式資料模型或現有關系型技術的相依性案例，在多區域寫入設定中使用 Azure Cosmos DB 可能不適用。 在這種情況下，使用的關聯式技術必須經過設計和設定，以遵守應用程式設計的多重區域主動-主動期望。

Azure 提供許多受控關聯式資料平臺，包括適用于常見 OSS 關聯式解決方案的 Azure SQL 資料庫和 Azure 資料庫，包括 MySQL、PostgreSQL 和 MariaDB。 因此，本節中的設計考慮和建議將著重于Azure SQL資料庫和 Azure 資料庫 OSS 類別的最佳使用方式，以最大化可靠性和全域可用性。

設計考量

  • 雖然關聯式資料技術可以設定為輕鬆調整讀取作業，但寫入通常會受限於單一主要實例，這會對延展性和效能造成重大限制。

  • 分區化 可以套用至跨多個相同結構化資料庫散發資料和處理，水準分割資料庫以流覽平臺條件約束。

    • 例如，分區化通常會套用在多租使用者 SaaS 平臺中，以將租使用者群組隔離成不同的資料平臺建構。

Azure SQL Database

  • Azure SQL 資料庫提供完全受控的資料庫引擎，一律在最新穩定版本的 SQL Server 資料庫引擎和基礎作業系統上執行。

    • 提供智慧型功能，例如效能微調、威脅監視和弱點評估。

  • Azure SQL資料庫提供內建的區域高可用性和周全異地複寫，可將讀取複本分散到 Azure 區域。

    • 使用異地複寫時，次要資料庫複本會維持唯讀狀態，直到起始容錯移轉為止。
    • 相同或不同區域中最多支援四個次要複本。
    • 次要複本也可用於唯讀查詢存取，以優化讀取效能。
    • 容錯移轉必須手動起始，但可以包裝在自動化作業程式中。

  • Azure SQL資料庫提供自動容錯移轉群組，可將資料庫複寫至次要伺服器，並在失敗時允許透明容錯移轉。

    • 自動容錯移轉群組支援將群組中的所有資料庫都只異地複寫到不同地區的一個次要伺服器或執行個體。
    • 超大規模資料庫服務層級目前不支援自動容錯移轉群組。
    • 次要資料庫可用來卸載讀取流量。

  • 進階或業務關鍵服務層級資料庫複本可以分散到可用性區域，不需額外費用。

    • 控制通道也會跨多個區域重複，因為三個閘道通道 (GW) 。
      • 特定閘道通道的路由是由 Azure 流量管理員所控制。
    • 使用業務關鍵層時，只有在選取 Gen5 計算硬體時，才能使用區域備援設定。

  • Azure SQL資料庫在其所有服務層級上提供基準 99.99% 的可用性 SLA，但針對支援可用性區域的業務關鍵或進階層，提供較高的 99.995% SLA。

    • Azure SQL未針對區域備援部署設定的資料庫業務關鍵或進階層具有 99.99% 的可用性 SLA。

  • 使用異地複寫設定時，Azure SQL資料庫業務關鍵層提供復原時間目標 (RTO) 30 秒，部署時數為 100%。

  • 使用異地複寫設定時，Azure SQL資料庫業務關鍵層具有復原點目標 (RPO) 5 秒，部署時數為 100%。

  • Azure SQL資料庫超大規模資料庫層至少設定兩個複本時，可用性 SLA 為 99.99%。

  • 您可以使用保留折扣來減少與Azure SQL資料庫相關聯的計算成本。

    • 無法為以 DTU 為基礎的資料庫套用保留容量。

  • 時間點還原 可用來將資料庫和自主資料傳回至先前的時間點。

  • 異地還原 可用來從異地備援備份復原資料庫。

適用于 PostgreSQL 的 Azure 資料庫

  • 適用于 PostgreSQL 的 Azure 資料庫提供三種不同的部署選項：

    • 單一伺服器，SLA 99.99%
    • 彈性伺服器，提供可用性區域備援，SLA 99.99%
    • 啟用高可用性模式時，超大規模 (Citus) SLA 99.95%。

  • 超大規模 (Citus) 透過分區化提供動態延展性，而不需變更應用程式。

    • 將資料表資料列分散到多個 PostgreSQL 伺服器是確保超大規模 (Citus) 中可調整查詢的關鍵。
    • 多個節點可以共同保存比傳統資料庫更多的資料，而且在許多情況下，可以使用背景工作 CPU 來將成本優化。

  • 您可以透過 Runbook 自動化設定自動調整，以確保彈性以回應變更的流量模式。

  • 彈性伺服器透過停止/啟動伺服器的能力，以及適合不需要連續計算容量的工作負載，為非生產工作負載提供成本效益。

  • 備份儲存體最多 100% 的總布建伺服器儲存體不需額外費用。

    • 備份儲存體的額外耗用量會根據取用的 GB/月收費。

  • 使用單一伺服器保留折扣或超大規模 (Citus) 保留折扣，即可減少與適用於 PostgreSQL 的 Azure 資料庫相關聯的計算成本。

設計建議

  • 請考慮根據不同的應用程式和資料內容分割關係資料庫分區化，協助巡覽平臺條件約束、最大化延展性和可用性，以及錯誤隔離。

    • 當應用程式設計考慮三個或多個 Azure 區域時，這項建議特別普遍，因為關聯式技術條件約束可能會大幅阻礙全球散發的資料平臺。
    • 分區化不適用於所有應用程式案例，因此需要內容化評估。

  • 優先使用Azure SQL資料庫，其中關聯式需求因 Azure 平臺成熟度和各種可靠性功能而存在。

Azure SQL Database

  • 使用 Business-Critical 服務層級將可靠性和可用性最大化，包括存取重要的復原功能。

  • 使用以虛擬核心為基礎的取用模型，以利獨立選擇計算和儲存體資源，專為工作負載量和輸送量需求量而量身打造。

    • 確定已定義的容量模型已套用，以通知計算和儲存體資源需求。

  • 設定 Zone-Redundant 部署模型，以將業務關鍵資料庫複本分散到相同區域內可用性區域。

  • 使用 主動式異地複 寫在所有部署區域內部署可讀取的複本， (最多四個) 。

  • 使用自動容錯移轉群組為次要區域提供 透明容錯移轉 ，並套用異地複寫，以提供其他部署區域的複寫，以進行讀取優化和資料庫備援。

    • 對於僅限兩個部署區域的應用程式案例，應該優先使用自動容錯移轉群組。

  • 考慮自動化作業觸發程式，根據與應用程式健康情況模型相符的警示，在影響自動容錯移轉群組內主要和次要複寫的失敗時，進行異地複寫實例的容錯移轉。

重要

對於考慮超過四個部署區域的應用程式，應對應用程式定界分割化或重構應用程式進行嚴重考慮，以支援多重區域寫入技術，例如 Azure Cosmos DB。 不過，如果這在應用程式工作負載案例中不可行，建議您將單一地理位置內的區域高度為包含異地複寫實例的主要狀態，以更平均地分散的讀取存取權。

  • 將應用程式設定為查詢複本實例以進行讀取查詢，以優化讀取效能。

  • 在 Azure SQL DB 中使用 Azure 監視器和Azure SQL Analytics進行近乎即時的作業深入解析，以偵測可靠性事件。

  • 使用 Azure 監視器來評估所有資料庫的使用量，以判斷是否已適當地調整其大小。

    • 確定 CD 管線會考慮在代表性負載層級下進行負載測試，以驗證適當的資料平臺行為。

  • 計算資料庫元件的健全狀況計量，以觀察與商務需求和資源使用率相對的健康情況，並視需要監視 和警示 來推動自動化操作動作。

    • 請確定已納入重要的查詢效能計量，以便在發生服務降低時採取快速動作。

  • 使用 查詢效能深入解析 優化查詢、資料表和資料庫，以及 Microsoft 提供的常見 效能建議 。

  • 使用 SDK實作重試邏輯，以減輕影響Azure SQL資料庫連線的暫時性錯誤。

  • 在套用伺服器端透明資料加密 (TDE) 進行待用加密時，優先使用服務管理的金鑰。

    • 如果需要客戶管理的金鑰或用戶端 (AlwaysEncrypted) 加密，請確定金鑰具有備份和自動化輪替設施的適當彈性。

  • 請考慮使用 時間點還原 作為操作劇本，以從嚴重設定錯誤中復原。

適用于 PostgreSQL 的 Azure 資料庫

  • 由於可用性區域支援，建議將彈性伺服器用於業務關鍵工作負載。

  • 針對業務關鍵工作負載使用超大規模 (Citus) 時，啟用高可用性模式以接收 99.95% SLA 保證。

  • 使用 超大規模資料庫 (Citus) 伺服器組態，將多個節點的可用性最大化。

  • 定義應用程式的容量模型，以通知資料平臺內的計算和儲存體資源需求。

經常性存取層資料的快取

記憶體內部快取層可以藉由大幅增加讀取輸送量並改善經常性層資料案例的端對端用戶端回應時間，來增強資料平臺。

Azure 提供數個具有快取金鑰資料結構之適用功能的服務，Azure Cache for Redis定位在抽象和優化資料平臺讀取存取。 因此，本節將著重于需要額外的讀取效能和資料存取持久性的情況下，Azure Cache for Redis的最佳使用方式。

設計考量

  • 快取層提供額外的資料存取持久性，因為即使中斷影響基礎資料技術，應用程式資料快照集仍可透過快取層存取。

  • 在某些情況下，記憶體內部快取可以在應用程式平臺本身內實作。

Azure Cache for Redis

  • Redis 快取是開放原始碼 NoSQL 索引鍵/值記憶體內部儲存體系統。

  • 企業和企業 Flash 層可以透過異地複寫，在區域內可用性區域和不同 Azure 區域的主動-主動設定中部署。

    • 在至少三個 Azure 區域和每個區域中部署三個以上的可用性區域時，針對所有快取實例啟用主動式異地複寫時，Azure Cache for Redis提供 99.999% 的 SLA，以便連線到一個區域快取端點。
    • 在單一 Azure 區域內部署三個可用性區域時，會提供 99.99% 的連線 SLA。

  • 企業快閃層會在 RAM 和快閃非變動性記憶體儲存體的組合上執行，雖然這會產生較小的效能負面影響，但也會啟用非常大型的快取大小，最多可搭配叢集使用 13TB。

  • 使用異地複寫時，除了與快取實例相關聯的直接成本之外，區域之間的資料傳輸費用也會適用。

  • 排程匯報功能不包含套用至基礎 VM 作業系統的 Azure 更新或更新。

  • 在向外延展作業期間，資料移轉至新的實例時，CPU 使用率會增加。

設計建議

  • 請考慮「經常性」資料案例的優化快取層，以提高讀取輸送量並改善回應時間。

  • 針對快取到期和內部處理套用適當的原則，以避免資料成長失失。

    • 當備份資料變更時，請考慮過期快取專案。

Azure Cache for Redis

  • 使用進階或企業 SKU 將可靠性和效能最大化。

    • 對於具有極大型資料磁片區的案例，應考慮企業 Flash 層。
    • 對於只需要被動異地複寫的案例，也可以考慮進階層。

  • 在所有考慮的部署區域中，在作用中設定中使用異地複寫來部署複本實例。

  • 請確定複本實例會部署在每個考慮的 Azure 區域內可用性區域。

  • 使用 Azure 監視器評估Azure Cache for Redis。

    • 計算區域快取元件的健全狀況分數，以觀察相對於商務需求和資源使用率的健康情況。
    • 觀察和警示重要計量，例如高 CPU、高記憶體使用量、高伺服器負載，以及擷取的金鑰，以取得調整快取的時機。

  • 藉由實作重試邏輯、逾時，以及使用 Redis 連線多工器的單一實作來優化 連線復原 能力。

  • 設定 排程更新 ，以指定 Redis 伺服器更新套用至快取的日期和時間。

分析案例

任務關鍵性應用程式將分析案例視為從內含資料流程推動額外價值的方法，越來越常見。 應用程式和作業 (AIOps) 分析案例，因此形成高度可靠資料平臺的重要層面。

分析和交易式工作負載需要不同的資料平臺功能和優化，才能在其各自的內容中接受效能。

Description 分析 交易式
使用案例 分析非常大量的資料 (「巨量資料」) 處理非常大量的個別交易
最佳化對象 讀取許多記錄的查詢和匯總 近乎即時的建立/讀取/更新/刪除 (CRUD) 少數記錄的查詢
主要特性 - 從記錄的資料來源合併
- 以資料行為基礎的儲存體
- 分散式儲存體
- 平行處理
- 反正規化
- 低並行讀取和寫入
- 使用壓縮優化儲存磁片區		 - 應用程式的記錄資料來源
- 以資料列為基礎的儲存體
- 連續儲存體
- 對稱處理
-正常化
- 高並行讀取和寫入、索引更新
- 使用記憶體內部儲存體針對快速資料存取進行優化

Azure Synapse提供企業分析平臺，可將關聯式和非關聯式資料與 Spark 技術結合在一起，使用 Azure Cosmos DB 之類的 Azure 服務內建整合，以利進行巨量資料分析。 因此，本節中的設計考慮和建議將著重于分析案例的最佳Azure Synapse和 Azure Cosmos DB 使用量。

設計考量

  • 傳統上，大規模分析案例可藉由將資料擷取到針對後續分析查詢優化的個別資料平臺來輔助。
    • 擷取、轉換和載入 (ETL) 管線可用來擷取資料將會耗用輸送量並影響交易式工作負載效能。
    • 不常執行 ETL 管線以減少輸送量和效能影響，將會導致分析資料較不最新。
    • 隨著資料轉換變得更複雜，ETL 管線開發和維護額外負荷會增加。
      • 例如，如果經常變更或刪除來源資料，ETL 管線必須透過加法/版本化方法、傾印和重載，或就地變更分析資料，考慮目標資料中的那些變更。 這些方法都會產生衍生影響，例如重新建立或更新索引。

Azure Cosmos DB

  • 在 Azure Cosmos DB 交易資料上執行的分析查詢通常會跨大量資料分割匯總，耗用大量要求單位 (RU) 輸送量，這可能會影響周圍交易式工作負載的效能。

  • Azure Cosmos DB 分析存放區提供架構化、完全隔離的資料行導向資料存放區，可讓您從 Azure Synapse 對 Azure Cosmos DB 資料進行大規模分析，而不會影響 Azure Cosmos DB 交易式工作負載。

    • 當 Azure Cosmos DB 容器啟用為分析存放區時，會從容器中的運算元據內部建立新的資料行存放區。 此資料行存放區會與容器的資料列導向交易存放區分開保存。
    • 作業資料的建立、更新和刪除作業會自動同步處理至分析存放區，因此不需要變更摘要或 ETL 處理。
    • 從作業到分析存放區的資料同步處理不會取用輸送量要求單位， (RU) 布建在容器或資料庫上。 交易式工作負載不會對效能造成影響。 分析存放區不需要在 Azure Cosmos DB 資料庫或容器上配置額外的 RU。
    • 自動同步處理是作業資料變更自動同步至分析存放區的程式。 自動同步延遲通常少於 2 (2) 分鐘。
      • 具有共用輸送量和大量容器的資料庫，自動同步延遲最多可以有 5 (5) 分鐘。
      • 一旦自動同步完成，就可以從Azure Synapse查詢最新的資料。
    • 分析存放區儲存體會使用以使用量為基礎的 定價模型 ，其會針對資料量和讀取和寫入作業數目收費。 分析存放區定價與交易存放區定價不同。

  • 使用 Azure Synapse Link，可以直接從 Azure Synapse 查詢 Azure Cosmos DB 分析存放區。 這會從 Synapse 啟用 no-ETL、Hybrid Transactional-Analytical Processing (HTAP) ，以便近乎即時地從 Synapse 查詢 Azure Cosmos DB 資料與其他分析工作負載。

  • 根據預設，Azure Cosmos DB 分析存放區不會進行分割。

    • 在某些查詢案例中，效能會藉由使用經常用於查詢述詞的索引鍵來 分割分析存放區 資料來改善。
    • 資料分割是由Azure Synapse中使用 Synapse Link 來執行 Spark 筆記本的作業所觸發，此作業會從 Azure Cosmos DB 分析存放區載入資料，並將它寫入 Synapse 分割存放區中 Synapse 工作區的主要儲存體帳戶中。

  • Azure Synapse Analytics SQL 無伺服器集區可以透過自動更新的檢視或 SELECT / OPENROWSET 命令來查詢分析存放區。

  • Azure Synapse Analytics Spark 集區可以透過自動更新的 Spark 資料表或 spark.read 命令來查詢分析存放區。

  • 您也可以使用 Spark 將資料從 Azure Cosmos DB 分析存放區複製到專用的 Synapse SQL 集區，以便使用布建Azure Synapse SQL 集區資源。

  • 您可以使用Azure Synapse Spark來查詢 Azure Cosmos DB 分析存放區資料。

    • Spark 筆記本允許 Spark 資料框架 組合與其他資料集匯總和轉換 Azure Cosmos DB 分析資料，並使用其他進階 Synapse Spark 功能，包括將轉換的資料寫入其他存放區或定型 AIOps Machine Learning 模型。

Azure Cosmos DB 分析資料行存放區

Azure Synapse

  • Azure Synapse整合分析功能，包括 SQL 資料倉儲、Spark 巨量資料，以及記錄和時間序列分析Data Explorer。

    • Azure Synapse使用連結服務來定義與其他服務的連線，例如 Azure 儲存體。
    • 資料可以透過支援的來源複製活動擷取到 Synapse Analytics。 這允許 Synapse 中的資料分析，而不會影響來源資料存放區，但會因為資料傳輸而增加時間、成本和延遲額外負荷。
    • 資料也可以在支援的外部存放區中就地查詢，以避免資料擷取和移動的額外負荷。 使用 Data Lake Gen2 的 Azure 儲存體是 Synapse 的支援存放區， 而且可透過 Synapse Spark 查詢 Log Analytics 匯出的資料。

  • Azure Synapse Studio會整合擷取和查詢工作。

    • 系統會查詢和處理來源資料，包括 Azure Cosmos DB 分析存放區資料和 Log Analytics 匯出資料，以支援商業智慧和其他匯總的分析使用案例。

Azure Synapse Analytics

設計建議

  • 請確定分析工作負載不會影響交易式應用程式工作負載，以維持交易式效能。

Application Analytics

AIOps 和作業分析

  • 為每個來源 Azure 儲存體帳戶建立具有連結服務和資料集的單一Azure Synapse工作區，其中會傳送來自資源的作業資料。

  • 建立專用的 Azure 儲存體帳戶，並將其作為工作區主要儲存體帳戶來儲存 Synapse 工作區目錄資料和中繼資料。 使用階層命名空間進行設定，以啟用 Azure Data Lake Gen2。

    • 維持來源分析資料和 Synapse 工作區資料和中繼資料之間的分隔。
      • 請勿使用其中一個區域或全域 Azure 儲存體帳戶來傳送運算元據。

後續步驟

檢閱網路考慮的考慮。

網路與連線能力