共用方式為

Azure 架構良好的架構檢閱 – 適用於 NoSQL 的 Azure Cosmos DB

  • 發行項

本文說明適用於 NoSQL 的 Azure Cosmos DB 最佳做法。 這些最佳做法可確保您可以在 Azure Cosmos DB 上部署解決方案，這些解決方案是有效率、可靠、安全、針對成本優化，且運作良好。 本指引著重於妥善架構架構架構中架構卓越五大要素：

本檢閱指南假設您有 Azure Cosmos DB 的工作知識，且熟悉其功能。 如需詳細資訊，請參閱 適用於 NoSQL 的 Azure Cosmos DB。

必要條件

了解架構完善的架構支柱有助於產生高品質、穩定且有效率的雲端架構。 建議您先使用 Azure 架構良好的架構檢閱評定來檢閱您的工作負載。

如需更多內容，請檢閱各種參考架構，以反映本指南的設計考慮。 這些架構包括，但不限於：

可靠性

如同任何雲端服務，服務與工作負載端都可能發生失敗。 無法防止所有潛在的失敗，但最好是將單一失敗元件對整個工作負載的影響降到最低。 本節包含一次性失敗後果的考慮和建議。

設計檢查清單

  • 請考慮所選的一致性層級和複寫模式如何影響全區域中斷中的恢復點目標 （RPO）。
  • 設計您的資料庫帳戶部署，使其跨越 Azure 中的至少兩個區域。 此外，在 Azure 區域內提供時，將您的帳戶分散到多個可用性區域。
  • 評估工作負載的多區域和單一區域寫入策略。 針對單一區域寫入，請將工作負載設計為至少要有第二個讀取區域進行故障轉移。 針對單一區域寫入和多重區域讀取案例啟用自動故障轉移。 針對多重區域寫入，請將複雜度和一致性的取捨與寫入至多個區域的優點進行比較。 在單一區域和多區域寫入帳戶的區域中斷期間，檢閱預期。
  • 為您的帳戶啟用 服務管理的故障轉移 。
  • 設計應用程式的高可用性端對端測試。
  • 逐步解 說常見的備份程式 ，包括但不限於;時間點還原、從意外破壞性作業復原、還原已刪除的資源，以及還原至另一個區域的時間點。 使用 連續備份設定帳戶，根據您的商務需求選擇適當的保留期間。
  • 探索設計復原應用程式指南、檢閱 SDK 的預設重試原則，以及規劃特定暫時性錯誤的自定義處理。 這些指南會提供最佳做法，讓應用程式程式碼能夠復原暫時性錯誤。

建議

建議 優點
將您的 Azure Cosmos DB 帳戶分散到可用性區域（可用時）。 可用性區域可為複本的子集提供不同的電源、網路和冷卻隔離硬體失敗。 Azure Cosmos DB 有多個複本，可在未使用可用性區域功能時跨越單一隨機可用性區域。 如果使用可用性區域功能，複本會跨越多個可用性區域。
設定您的 Azure Cosmos DB 帳戶，以跨越至少兩個區域。 跨越多個區域可防止您的帳戶在隔離區域中斷時完全無法使用。
為您的帳戶啟用服務管理的故障轉移。 服務管理的故障轉移可讓 Azure Cosmos DB 變更多區域帳戶的寫入區域，以保留可用性。 這項變更會在不需使用者互動的情況下發生。 瞭解服務管理的故障轉移的取捨，並在必要時規劃強制故障轉移。 如需詳細資訊，請參閱 建置高可用性應用程式。
透過暫時停用服務管理的故障轉移，手動測試故障轉移來驗證可用性。 暫時停用服務管理故障轉移可讓您使用腳本或 Azure 入口網站 啟動手動故障轉移，來驗證應用程式的端對端高可用性。 之後，您可以重新啟用服務管理的故障轉移。

Azure 原則定義

安全性

安全性是任何可輕鬆忽略以方便使用之架構的重要部分。 在建立第一個資源或概念證明之前，先考慮各種安全性最佳做法，以增強最終工作負載的安全性。 本節包含可減少最終工作負載安全性弱點數目的考慮和建議。

設計檢查清單

建議

建議 優點
至少實作數據保護和身分識別管理安全性基準。 流覽安全性基準，包括身分識別管理和數據保護。 實作保護 Azure Cosmos DB 帳戶的建議。
停用公用端點，並盡可能使用私人端點。 請避免將不必要或未使用的公用端點留給您的帳戶進行介面區攻擊。
使用角色型訪問控制來限制特定身分識別和群組的控制平面存取，以及定義完善的指派範圍內。 使用角色型訪問控制來防止對您的帳戶進行非預期的存取。 將適當的角色和許可權指派給存取 Azure Cosmos DB 的使用者或應用程式。
建立虛擬網路端點和規則，以限制對帳戶的存取。 實作虛擬網路服務端點和防火牆規則，以限制對 Azure Cosmos DB 帳戶的存取。 使用網路安全組 （NSG） 來控制 Azure Cosmos DB 資源的輸入和輸出流量。 限制對受信任網路的存取，並套用適當的網路安全性措施，有助於保護您的數據免於未經授權的存取。
請遵循最佳軟體開發作法，安全地存取數據。 在開發與 Azure Cosmos DB 互動的應用程式時，請遵循安全編碼做法並執行安全程式代碼檢閱。 防範常見的安全性弱點，例如插入式攻擊、跨網站腳本 （XSS）， 或不安全的直接物件參考 （IDOR）。 針對常見的 HTTP 狀態代碼實作輸入驗證、參數化查詢和適當的錯誤處理，以防止安全性風險。
監視控制平面記錄是否有缺口。 監視可協助您追蹤存取模式和稽核記錄，確保資料庫保持安全且符合相關數據保護法規的規範。 監視數據平面計量也可以協助識別可能顯示安全性缺口的不熟悉模式。 如需詳細資訊，請參閱 Azure 資料庫的安全性檢查清單。
啟用適用於 Azure Cosmos DB 的 Microsoft Defender Microsoft Defender 偵測到嘗試利用適用於 NoSQL 的 Azure Cosmos DB 資料庫。 Defender 會偵測潛在的 SQL 插入、可疑的存取模式，以及其他潛在的惡意探索。

Azure 原則定義

成本最佳化

工作負載的特性和解決方案的實作可能會影響在 Azure 中執行的最終成本。 在設計工作負載時，請考慮主要驅動程式，例如數據分割策略、一致性層級、復寫和寫入類型。 調整工作負載大小時，請考慮數據的讀取/寫入本質、平均專案大小、正規化和 TTL。 本節包含簡化工作負載成本的考慮和建議。

  • 設計索引編製原則，其會考慮您在工作負載中經常執行的作業和查詢。
  • 判斷分割區索引鍵或一組數據分割索引鍵，其具有高基數且不會變更的值。 使用現有的指引和最佳做法來協助選取適當的分割區索引鍵。 此外，在判斷分割區索引鍵時，請考慮您的 索引 編製原則。
  • 選取適合您工作負載的輸送量配置架構。 檢閱在資料庫或容器層級散發的標準和自動調整輸送量優點。 此外，請視情況考慮無伺服器。 在選取輸送量配置配置的內容中，檢閱工作負載的流量模式 。
  • 請考慮一致性層級，因為它們與您的工作負載相關。 此外，請考慮用戶端會話是否應該改變預設一致性層級。
  • 計算工作負載的預期整體數據記憶體。 專案和索引的大小都會影響您的數據記憶體成本。 計算復寫和備份對記憶體成本的影響。
  • 建立策略，以自動移除不再使用或必要的舊專案。 如有需要，請在移除這些專案之前，將這些專案匯出至低成本的記憶體解決方案。
  • 評估將跨分割區查閱降至最低的最常見查詢。 使用這項資訊來通知選取分割區索引鍵或自定義索引編製原則的程式。

建議

建議 優點
監視 RU/秒使用率和模式。 使用計量來監視解決方案開頭的 RU 耗用量。 使用查詢和其他數據研究技術，在應用程式程式碼中尋找反模式。
自定義索引編製原則以對應至您的工作負載。 默認索引編製原則會為專案中的所有路徑編製索引，而且此原則可能會對 RU 耗用量和成本產生重大影響。 使用索引編製原則，只根據您需要為一般查詢編製索引的路徑來設計。 針對大量寫入工作負載，請停用查詢中未使用之數據行的自動編製索引。
選取適合您工作負載的分割區索引鍵[s]。 分割區索引鍵[s] 應該將輸送量耗用量和數據記憶體平均分散到邏輯分割區。 選取範圍也應該將未系結的跨分割區查詢數目降到最低。 避免經常性分割區接收不成比例的流量，因為不平衡的數據分割會增加輸送量成本和暫時性錯誤。 使用最常見的搜尋查詢來判斷可能只執行單一分割區或界限跨分割區查詢的潛在分割區索引鍵[s]。
針對您的工作負載，請在資料庫或容器層級使用無伺服器或布建的輸送量、手動布建或自動調整。 比較布建的輸送量類型 ，然後為您的工作負載選取適當的選項。 一般而言，較小的和開發/測試工作負載可能會受益於資料庫層級的無伺服器輸送量或手動共用輸送量。 較大的任務關鍵性工作負載可能會受益於在容器層級指派的布建輸送量。
設定應用程式的預設一致性層級。 適當時， 請降級用戶端會話中的預設一致性層級 。 您不一定需要變更標準預設一致性層級，或在用戶端會話中覆寫它。 請考慮在較強一致性層級上與讀取相關聯的較高成本。
針對開發/測試工作負載，請使用 Azure Cosmos DB 模擬器。 Azure Cosmos DB 模擬器是開發/測試和持續整合的選項，可節省開發小組這些常見工作負載的成本。 模擬器也可作為 Docker 容器映像使用。
使用交易式批次作業 設計分割區，以利用邏輯分割區索引鍵內的交易式批次作業進行插入。 在用戶端 SDKS 中使用批次作業，在單一交易要求中插入、更新或刪除多個檔。 此步驟可以減少個別要求的數目，最後可能會導致更好的輸送量效率。
使用投影來降低大型查詢結果集的輸送量成本。 撰寫查詢，只投影結果集所需的最少欄位數目。 如果需要欄位上的計算，請評估執行這些計算伺服器端與用戶端的輸送量成本。
避免使用未系結的跨分割區查詢。 評估並撰寫查詢，以確保盡可能在單一邏輯分割區內搜尋。 使用查詢篩選來控制查詢目標的邏輯分割區。 如果查詢必須跨邏輯分割區搜尋，請將查詢系結至只搜尋邏輯分割區的子集，而不是完整掃描。
實作存留時間（TTL）以移除未使用的專案。 使用 TTL 自動刪除不再需要的數據。 拿掉過期或過時的數據，以管理記憶體成本。 如有必要，請將過期的數據導出至成本較低的記憶體解決方案。
請考慮大量匯總的分析存放區。 Azure Cosmos DB 分析存放區會自動將數據同步至個別的數據行存放區，以針對大型匯總、報告和分析查詢進行優化。

Azure 原則定義

卓越營運

部署工作負載之後必須加以監視，以確保其如預期般執行。 此外，監視工作負載有助於在規劃階段無法立即發現新的效率。 在重大案例中，診斷數據是發現高嚴重性事件發生原因的關鍵。 本節包含監視工作負載事件和特性的考慮和建議。

設計檢查清單

  • 起草記錄和計量監視策略，以區分不同的工作負載、標幟例外狀況、追蹤例外狀況/錯誤中的模式，以及追蹤主計算機效能。
  • 儘可能設計大型工作負載以使用大量作業。
  • 定義多個警示來監視節流、分析輸送量配置，以及追蹤數據的大小。
  • 針對跨區域的解決方案可用性設計監視策略。
  • 建立並強制執行最佳做法，以自動部署適用於 NoSQL 的 Azure Cosmos DB 帳戶和資源。
  • 根據數據分割和索引設計規劃預期的計量閾值。 請確定有計劃監視這些計量，以判斷它們與計劃閾值有多接近。

建議

建議 優點
請確定應用程式開發人員使用的是最新版本的開發人員 SDK。 每個適用於 NoSQL SDK 的 Azure Cosmos DB 都有最低建議版本。 如需詳細資訊，請參閱 .NET SDK 和 Java SDK。
在用戶端應用程式中建立標識碼，以區分工作負載。 請考慮旗標，例如使用者代理程序後綴，以識別每個記錄專案或計量應該相關聯的工作負載。
使用開發人員 SDK 擷取補充診斷。 使用每個 SDK 的診斷插入技術，將工作負載的補充資訊與預設計量和記錄一起新增。 如需詳細資訊，請參閱 .NET SDK 和 Java SDK。
建立與主計算機資源相關聯的警示。 連線性和可用性問題可能會因為用戶端主計算機問題而發生。 使用適用於 NoSQL SDK 的 Azure Cosmos DB，透過用戶端應用程式監視主機機器上的 CPU、記憶體和記憶體等資源。
針對大型作業使用用戶端 SDK 的大量功能。 需要高度輸送量的案例，受益於使用 SDK 的大量功能。 大量 功能 會自動管理和批處理作業，以將輸送量最大化。
建立輸送量節流警示。 使用警示來追蹤超出預期閾值的輸送量節流。 一段時間后，當您深入瞭解 Azure Cosmos DB 的工作負載時，請檢閱並調整警示。 標準化 RU 耗用量計量是計量，可測量資料庫或容器上布建輸送量的百分比使用率。 如果此計量一致為 100%，要求可能會傳回暫時性錯誤。
使用計量追蹤查詢效能。 使用計量來追蹤您一段時間內最上層查詢的效能。 藉由更新索引編製原則或變更查詢，評估是否有效率。 如果查詢效能不佳，請針對效能進行疑難解答，並套用查詢最佳做法。 如需詳細資訊，請參閱 查詢效能秘訣。
使用範本自動部署帳戶資源。 請考慮 使用 Azure Resource Manager、 Bicep 或 Terraform 範本，將帳戶和後續資源的部署自動化。 請確定您的小組使用相同的範本部署到其他非生產環境。
追蹤關鍵計量，以識別工作負載中的常見問題。 使用特定計量來尋找工作負載中的常見問題，包括但不限於;依類型依分割區、節流和要求磁碟區的 RU 使用率、RU 使用率。 如需詳細資訊，請參閱 監視數據參考。

Azure 原則定義

效能效益

  • 定義應用程式的效能基準。 測量您可能需要處理的並行使用者和交易數目。 請考慮工作負載特性，例如您的平均使用者流程、一般作業，以及使用量尖峰。
  • 研究最常見的和最複雜的查詢。 識別使用多個查閱、聯結或匯總的查詢。 在分割區索引鍵或索引編製原則的任何設計考慮中，請考慮這些查詢。
  • 針對最常見的查詢，判斷每個頁面預期的結果數目。 此數字有助於將預先擷取結果的緩衝專案計數正規化。
  • 研究您的目標使用者。 判斷哪些 Azure 區域最接近它們。
  • 識別使用一或多個排序欄位的查詢。 此外，識別影響多個字段的作業。 在編製索引原則設計中明確包含這些欄位。
  • 設計專案，使其對應的 JSON 檔盡可能小。 視需要分割數據跨越多個專案。
  • 識別子陣列上的查詢，並判斷它們是否為更有效率的子查詢候選專案。
  • 判斷您的工作負載是否需要分析存放區。 針對極其複雜的查詢，請考慮分析存放區和服務，例如 Azure Synapse Link 。
建議 優點
根據您的效能基準設定輸送量。 使用容量計算機之類的工具來判斷效能基準所需的輸送量數量。 使用自動調整等功能來調整實際輸送量，以更符合實際工作負載。 之後請監視實際的輸送量耗用量，並進行調整。
適當時，在用戶端和伺服器端使用優化技術。 利用內 建整合式快取。 設定 SDK 來管理預先擷取的項目數（已緩衝處理），並針對每個頁面傳回。
將適用於 NoSQL 的 Azure Cosmos DB 部署到最接近用戶的區域。 盡可能將適用於 NoSQL 的 Azure Cosmos DB 部署到最接近用戶的區域，以減少延遲。 利用讀取複寫來提供高效能讀取效能，不論您如何設定寫入 （單一或多個區域）。 將 （.NET/Java） SDK 設定為偏好更接近用戶的區域。
設定適用於直接模式的 SDK。 直接模式是最佳效能的慣用選項。 此模式可讓您的用戶端直接開啟 TCP 連線至服務中的數據分割，並直接在沒有中繼閘道情況下傳送要求。 此模式提供較佳的效能，因為網路躍點較少。
停用大量作業的索引編製。 如果有許多插入/取代/upsert 作業，請停用索引編製，以改善作業的速度，同時使用 對應 SDK 的大量支援 。 稍後可以立即重新啟用索引編製。
為複雜作業中使用的欄位建立複合索引。 複合式索引可以依大小順序增加多個字段的作業效率。 在許多情況下，針對具有多個字段的語句使用複合索引。ORDER BY
優化 SDK 的主機用戶端電腦。 針對最常見的情況，請在使用 SDK （.NET/Java） 的 64 口主電腦上使用至少 4 核心和 8 GB 記憶體。 此外，在主計算機上啟用 加速網路 功能。
在大部分 SDK 中使用 類別的單一模式 CosmosClient 。 使用大部分 SDK 中的用戶端類別做為單一 SDK。 客戶端類別會管理自己的生命週期，且設計為不會處置。 不斷建立和處置實例可能會導致效能降低。
將專案大小保持在小於 100 KB 的大小。 較大型的專案會取用更多常見的讀取和寫入作業輸送量。 針對專案較大的專案進行查詢，這些專案的所有欄位也可能具有顯著的輸送量成本。
以策略方式使用子查詢來優化聯結大型數據集的查詢。 如果涉及多個數位且未篩選，聯結子陣列的查詢可能會增加複雜度。 例如，聯結至少 10 個專案之兩個陣列的查詢可以擴充至 1,000個以上的 Tuple。 在專案內聯結陣列之前，使用子查詢來篩選陣列，以優化自我聯結表達式。 針對跨分割區查詢，將您的查詢優化，以包含分割區索引鍵上的篩選，以優化查詢的路由到可能最少的分割區數量。
針對最複雜的查詢使用分析工作負載。 如果您在大型容器上執行頻繁的匯總或聯結查詢，請考慮在 Azure Synapse Analytics 中啟用分析存放區並執行查詢。

Azure 原則定義

額外資源

請考慮更多與適用於 NoSQL 的 Azure Cosmos DB 相關的資源。

Azure 架構中心指引

雲端採用架構 指導方針

下一步

使用 Bicep 範本部署適用於 NoSQL 的 Azure Cosmos DB 帳戶