适用于 NoSQL 的 Azure Cosmos DB 的体系结构最佳做法

选择简单的设计并避免不必要的功能。 不要采用不必要的功能来增加工作负荷的复杂性，例如多主写入和自定义索引。 Azure Cosmos DB 支持这些功能，然而它们可以带来巨大的复杂性和操作负担。 仔细评估工作负荷是否需要任何高级功能。

将工作负载职责和跨领域关注点卸载到其他服务，例如使用 Microsoft Entra ID 进行身份验证和授权，或使用 Azure Monitor 和 Application Insights 进行监视。

确定工作负荷流的优先级。 应用程序中的所有流并非同样重要。 确定关键路径并为每个流分配优先级，以指导你的设计决策。 用户流设计可能会影响服务层级、功能和分配给 Azure Cosmos DB 数据库的容量。

为了帮助识别可能需要特殊处理的关键流，请记录其在数据处理能力方面区别于其他流的处理要求。 例如，某些流可能需要更高的吞吐量或对延迟问题更加敏感。 某些解决方案流可能需要不同的事务一致性级别。

使用故障模式分析来确定工作负荷中的潜在故障。 规划潜在故障的缓解策略。 下表显示了故障模式分析的示例。

有关详细信息，请参阅 Azure 应用程序故障模式分析 。

构建冗余以提高复原能力，并帮助满足可靠性目标。 设计数据库帐户部署，使其至少跨越 Azure 中的两个区域。 如果 Azure 区域支持，请将帐户分配到多个可用性区域。

评估您的工作负载所适用的多区域写入策略和单区域写入策略。 对于单区域写入，请设计您的工作负荷，使其至少包含一个用于故障转移的备用读取区域。 为单区域写入和多区域读取方案启用自动故障转移。 对于多区域写入，需要将在复杂性和一致性方面的权衡与写入多个区域的优势进行比较。 有关详细信息，请参阅针对单区域和多区域写入帐户在区域中断期间的预期情况。

考虑你的一致性级别和复制模式如何在区域性中断中影响恢复点目标（RPO）。

为应用程序设计端到端的高可用性测试，涵盖测试数据库故障转移和故障恢复。

使用本机灾难恢复和备份功能。 实现 数据库和容器备份和还原 以满足要求。 还原方案包括时间点还原、从意外破坏性操作中恢复、将已删除的资源恢复，以及还原到某个时间点的另一个区域。 使用 连续备份配置帐户。 根据业务需求选择适当的保留期。

将 Azure Cosmos DB 设计与行业标准应用程序设计指南和模式保持一致。 探索 设计可复原应用程序的指南，查看 SDK 的默认重试策略 ，并规划 特定暂时性错误的自定义处理。 这些指南提供了使应用程序代码能够应对暂时性错误的最佳做法。

审查安全基线。 若要增强工作负荷的安全态势，请查看 Azure 数据库的安全清单 和 Azure Cosmos DB 的安全基线。 至少，实现 数据保护 和 标识管理 安全基线，以帮助保护 Azure Cosmos DB 帐户。

在当前全局个人数据要求上下文中评估服务级别 合规性 和 认证 。

实施严格的、有条件的、可审核的标识和访问管理。 将 Microsoft Entra ID 用于工作负荷的身份验证和授权需求。 Microsoft Entra ID 提供集中式授权和访问管理。

要通过控制平面和数据平面访问帐户，请根据最低特权访问原则创建角色、组和分配。 请考虑 禁用基于密钥的身份验证。

加密数据。使用服务管理的密钥或客户管理的密钥加密静态数据或动态数据。

应用网络分段和安全控制。 在网络设计中创建有意的分段和外围，并使用所有网络边界的本地化网络控制来应用深度防御原则。

根据 Azure Cosmos DB 的安全基线，使用专用终结点来减少攻击面。

实施全面的安全监视策略。 使用控制平面日志审核用户访问、安全漏洞和资源操作。

使用 数据平面指标监视数据出口、数据更改、使用情况和延迟。

使用安全开发和测试做法。 遵循最佳软件开发做法来保护对数据的访问。 开发与 Azure Cosmos DB 交互的应用程序时，请遵循安全编码做法并执行安全代码评审。

优化 Azure Cosmos DB 缩放策略。 了解 Azure Cosmos DB 如何处理 存储和吞吐量缩放。 确定符合要求的性能和成本的正确平衡。

选择适合工作负荷的吞吐量分配架构。 审查在数据库或容器级别分布的标准吞吐量和自动缩放吞吐量的优点。 此外，请考虑在适当情况下使用无服务器选项。 分析工作负荷的流量模式 ，以选择最合适的吞吐量分配方案。

确定具有高基数且保持不变的分区键或分区键集。 使用 现有指南和最佳做法 来帮助选择适当的分区键。 此外，确定分区键时，请考虑 索引策略 。

优化 Azure Cosmos DB 数据成本。 清点数据并计算工作负荷的预期总体数据存储。 项和索引的大小都会影响数据存储成本。 计算复制和备份对存储成本的影响。

创建策略以自动删除不再使用或必要的旧项。 如果需要，请在删除这些项目之前将这些项导出到成本较低的存储解决方案。

优化您的查询以降低成本。 评估最常见的查询，以最大程度地减少跨分区查找。 使用此信息通知选择分区键或自定义索引策略的过程。

使用投影来降低大型查询结果集的吞吐量成本。 创作查询以仅投影结果集中所需的最少字段数。 如果需要对字段进行计算，请评估执行这些计算服务器端与客户端的吞吐量成本。

避免使用未绑定的跨分区查询。 评估和设计查询，以确保它们尽可能在单个逻辑分区内进行搜索。 使用查询筛选器控制查询目标逻辑分区。 如果查询必须跨逻辑分区进行搜索，请将查询绑定到仅搜索逻辑分区的子集，而不是完全扫描。

设计一个索引策略，该策略考虑工作负荷中的常见作和查询。

监视 Azure Cosmos DB 实例。 在工作负载监视解决方案中包含跨区域分布的 Azure Cosmos DB 实例。

在客户端应用程序中创建标识符以区分工作负荷。 考虑标志（如用户代理后缀）来标识每个日志条目或指标应与之关联的工作负荷。

起草日志和指标监视策略，以区分不同的工作负荷、标记异常方案、跟踪异常和错误中的模式以及跟踪主机性能。

定义多个警报，以监视限制流量、分析流量分配以及跟踪数据规模。

根据分区和索引设计规划预期的指标阈值。 创建一个计划来监视这些指标，以确定它们与计划阈值的接近程度。

通过基础设施即代码（IaC）自动化部署。 在代码部署实践中合并所有 Azure Cosmos DB 更改，包括基础结构部署和配置更改。

创建并强制实施最佳做法，以自动部署 Azure Cosmos DB for NoSQL 帐户和资源。

确保团队使用相同的模板部署到其他非生产环境。

规划和主动管理 Azure Cosmos DB 容量。 为应用程序定义性能基线。 测量可能需要处理的并发用户和事务数。 考虑工作负荷特征，例如平均用户流、常见作和使用量峰值。

研究目标用户。 确定哪些 Azure 区域最接近它们。

优化数据设计。 设计项目，使其相应的 JSON 文档尽可能小。 如有必要，请考虑在多个项之间拆分数据。

使项的大小小于 100 KB。 对于常见的读取和写入操作，较大的项消耗更多的吞吐量。 查询投影所有字段的较大项还会显著增加吞吐量成本。

选择适当的层、功能和计费模型。 确定工作负荷是否需要分析存储。 对于复杂的查询，请考虑分析存储和服务，例如 Azure Synapse Link 。

优化部署模型。 将 Azure Cosmos DB for NoSQL 部署到离最终用户最近的区域。 |通过将 Azure Cosmos DB for NoSQL 部署到最靠近最终用户的区域来减少延迟。

优化查询性能。 查看 查询性能提示 ，并应用适用于用例的策略。

标识使用一个或多个排序字段的查询。 此外，确定影响多个字段的操作。 在索引策略设计中显式包括这些字段。

设计大型工作负载时，应尽可能使用批量操作。

识别子数组上的查询，并确定它们是否是 更高效的子查询的候选项。

研究最常见的复杂查询。 标识使用多个查找、联接或聚合的查询。 在设计分区键或索引策略时，务必考虑这些查询。

对于最常见的查询，请确定每个页面所需的结果数。 此数字可帮助你为预提取的结果正式确定一个缓冲项计数。

优化代码逻辑。 在大多数 SDK 中，对 CosmosClient 类使用单一实例模式。 在大多数 SDK 中将客户端类用作单例。 客户端类管理自身的生命周期，并设计为不可释放。 不断创建和销毁实例可能会导致性能降低。