共用方式為

Azure 上任務關鍵性工作負載的數據平台考慮

  • 發行項

選擇有效的應用程式數據平臺是進一步重要的決策領域，在其他設計領域具有深遠的影響。 Azure 最終提供許多關係型、非關係型和分析數據平臺，其功能差異很大。 因此，關鍵非功能性需求必須與其他決策因素一起充分考慮，例如一致性、操作性、成本和複雜度。 例如，在多重區域寫入組態中運作的能力，對於全域可用平臺的適用性將具有重大影響。

此設計區域會 擴充應用程式設計，提供重要考慮和建議，以告知選取最佳數據平臺。

重要

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

四對巨量數據

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

  • Volume：傳入多少數據來通知記憶體容量和階層處理需求，也就是數據集的大小。
  • V位置：處理數據的速度，可以是批次或連續數據流，也就是流量速率。
  • Variety：數據的組織與格式、擷取結構化、半結構化和非結構化格式，也就是跨多個存放區或類型的數據。
  • 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 數據中心之間移動的所有流量。

    • 封包會在傳送前先在裝置上加密和解密，防止實體「中間人」或竊探/竊訊攻擊。

  • 數據平面和控制平面的驗證和授權。

    • 數據平臺如何驗證和授權應用程式存取和作業存取？

  • 透過監視平臺健康情況和數據存取的可檢視性。

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

設計建議

體積

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

    • 預測符合商務計劃的數據增長率，並使用已建立的比率來通知進行中的容量需求。
    • 比較匯總和個別數據記錄磁碟區與數據平臺限制。
    • 如果在特殊情況下有達到限制的風險，請確定已備妥作業風險降低措施，以防止停機和數據遺失。

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

    • 請確定調整作業符合記憶體、效能和一致性需求。
    • 引進新的縮放單位時，可能需要復寫基礎數據，這可能需要一段時間，而且可能會在復寫發生時造成效能損失。 因此，如果可能的話，請確定這些作業會在關鍵上班時間以外執行。

  • 定義應用程式數據層，以根據使用方式和關鍵性來分類數據集，以利移除或卸除較舊的數據。

    • 請考慮將數據集分類為「經常性」、「暖」和「冷」（『archive』） 層。
      • 例如，基礎參考實作會使用 Azure Cosmos DB 來儲存應用程式主動使用的「經常性」數據，而 Azure 儲存體 則用於「冷」作業數據以供分析之用。

  • 設定管家程式，以優化數據成長並提升數據效率，例如查詢效能，以及管理數據擴充。

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

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

    • 避免建立單一整合型數據存放區，其中數據磁碟區無法進行擴充。

速度

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

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

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

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

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

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

  • 使用自動化調整作業來排定 Azure 原生數據服務的優先順序，以加速對負載層級波動的快速回應。

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

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

  • 過度的輸送量應該由數據平臺或應用層正常處理，並由健康情況模型擷取以取得作業表示法。

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

    • 針對快取到期和保留套用適當的原則，以避免數據成長失控。
      • 備份數據變更時，快取專案會過期。
      • 如果快取到期時間嚴格是以存留時間（TTL）為基礎，則必須瞭解服務過時數據的影響和客戶體驗。

品種

  • 為了配合雲端和 Azure 原生設計的原則，強烈建議您將受控 Azure 服務排定優先順序，以減少作業和管理複雜度，並利用Microsoft未來的平台投資。

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

  • 驗證所選數據技術是否可使用必要的功能。

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

準確性

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

    • 將數據復本分散到區域內 可用性區域 （AZs），或使用區域備援服務層級，以最大化區域內的可用性。

  • 一致性需求允許的地方，請使用多區域寫入數據平台設計，將整體全域可用性和可靠性最大化。

    • 當在兩個不同的寫入複本中變更相同數據項時，請考慮衝突解決的商務需求，再復寫任一項變更，因而造成衝突。
      • 盡可能使用標準化的衝突解決原則，例如「最後一個獲勝」
        • 如果需要具有自定義邏輯的自定義策略，請確定已套用 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） 會使用系統定義的 timestamp _ts 屬性作為衝突解決路徑來套用時間同步處理時鐘通訊協定。 如果衝突解決路徑的最高值與項目發生衝突，且如果多個專案具有相同的數值，則系統會選取優勝者，讓所有區域可以聚合至相同版本的已認可專案。
      • 刪除衝突時，無論衝突解決路徑值為何，已刪除的版本一律都會勝過插入或取代衝突。
      • 上次寫入 Wins 是預設衝突解決原則。
      • 使用適用於 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 針對具有多重區域寫入的寬鬆一致性層級，提供最低 RTO 0，或 RPO 為 0，以便與單一寫入區域保持強式一致性。

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

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

  • Azure Cosmos DB 提供 99.99% SLA，以在設定五個一致性層級中的任何一個時，針對範圍設定為單一 Azure 區域的資料庫帳戶提供 99.99% SLA。

    • 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 Azure Cosmos DB 中的 Entra 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 帳戶讀取者角色」的角色指派，才能設定備份記憶體備援。
      • 包含兩個備份復本不需額外費用，但額外的備份會產生額外費用。
      • 根據預設，定期備份會儲存在無法直接存取的個別異地備援記憶體 （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 區域內，使用支援 可用性區域 的區域備援記憶體 （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 Cosmos DB 變更摘要尚未反映刪除，因此必須使用布爾屬性和 TTL 來套用虛刪除模式。
      • 當變更摘要提供完整逼真度更新時，就不需要此模式。
    • 適用於 Azure Cosmos DB 的 Azure Data Factory 連接器（適用於 NoSQL 的 Azure Cosmos DB 或 MongoDB API 連接器）來複製數據。

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 支援在所有部署區域中設定具有可用性區域 （AZ） 備援的 Azure Cosmos DB，以確保對區域內區域性失敗的復原能力。

  • 使用適用於 NoSQL 的 Azure Cosmos DB，因為它提供最完整的功能集，特別是在效能微調相關之處。

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

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

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 資料庫 業務關鍵 或進階層，可用性 SLA 為 99.99%。

  • 使用異地復寫設定時，Azure SQL 資料庫 業務關鍵 層會提供 30 秒的復原時間目標 （RTO），以 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

  • 使用業務關鍵服務層級來最大化可靠性和可用性，包括存取重要的復原功能。

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

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

  • 設定區域備援部署模型，以將 業務關鍵 資料庫複本分散在相同區域內的 可用性區域。

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

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

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

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

重要

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

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

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

  • 使用 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） 分析案例會形成高度可靠數據平臺的重要層面。

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

描述 分析 交易
使用案例 分析大量資料（「巨量數據」） 處理大量個別交易
最佳化對象 讀取許多記錄的查詢和匯總 近乎即時的建立/讀取/更新/刪除 （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）分鐘。
      • 具有共用輸送量和大量容器的資料庫，自動同步延遲最多可達五（5）分鐘。
      • 一旦自動同步完成，就可以從 Azure Synapse 查詢最新的數據。
    • 分析存放區記憶體會使用以耗用量為基礎的 定價模型 ，針對數據量和讀取和寫入作業數目收費。 分析存放區定價與交易式存放區定價不同。

  • 使用 Azure Synapse Link，可以直接從 Azure Synapse 查詢 Azure Cosmos DB 分析存放區。 這可啟用 Synapse 的無 ETL 混合式交易分析處理 （HTAP），以便近乎即時地從 Synapse 查詢 Azure Cosmos DB 數據與其他分析工作負載。

  • Azure Cosmos DB 分析存放區預設不會分割。

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

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

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

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

  • 您可以使用 Azure Synapse Spark 查詢 Azure Cosmos DB 分析存放區數據。

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

Azure Cosmos DB 分析數據行存放區

Azure Synapse

  • Azure Synapse 將分析功能整合在一起，包括 SQL 數據倉儲、Spark 巨量數據，以及用於記錄和時間序列分析的數據總管。

    • 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

設計建議

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

應用程式分析

AIOps 和 Operational Analytics

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

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

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

後續步驟

檢閱網路考慮的考慮。

網路和連線能力