你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure 架构良好的框架评审 - 用于 NoSQL 的 Azure Cosmos DB
本文介绍适用于 NoSQL 的 Azure Cosmos DB 的最佳做法。 这些最佳做法可确保在 Azure Cosmos DB 上部署解决方案，这些解决方案高效、可靠、安全、针对成本进行了优化，且在操作上非常出色。 本指南重点介绍精心构建的框架中体系结构卓越五大支柱：
本评审指南假定你对 Azure Cosmos DB 有一个工作知识，并且非常熟悉其功能。 有关详细信息，请参阅 Azure Cosmos DB for NoSQL。
先决条件
了解精心构建的框架支柱有助于生成高质量、稳定且高效的云体系结构。 建议首先使用 Azure 架构良好的框架评审评估来评审工作负荷。
有关更多上下文，请查看各种参考体系结构，这些体系结构反映了本指南在设计中的注意事项。 这些体系结构包括但不限于：
- 使用 Azure Cosmos DB 的全球分布式任务关键型应用程序
- 使用 Azure Cosmos DB 的无服务器应用
- 使用 Azure Cosmos DB 副本 (replica) 的多区域 Web 应用
可靠性
与任何云服务一样，服务端和工作负荷端都可能发生故障。 无法阻止所有潜在故障，但最好是最大程度地减少单个故障组件对整个工作负荷的影响。 本部分包括注意事项和建议，以最大程度地减少一次性故障的后果。
设计清单
- 请考虑所选的一致性级别和副本 (replica)模式如何影响区域范围的中断中的恢复点目标（RPO）。
- 设计数据库帐户部署，使其至少跨越 Azure 中的两个区域。 此外，在 Azure 区域中提供时，在多个可用性区域中分配帐户。
- 评估工作负荷的多区域和单区域写入策略。 对于单区域写入，请将工作负荷设计为至少具有第二个用于故障转移的读取区域。 为单区域写入和多区域读取方案启用自动故障转移。 对于多区域写入，请将复杂性和一致性的权衡与写入到多个区域的优点进行比较。 查看 单区域和多区域写入帐户的区域中断期间的预期。
- 为帐户启用 服务管理的故障转移 。
- 为应用程序设计端到端的高可用性测试。
- 演练 常见的备份过程 ，包括但不限于时间点还原、从意外破坏性操作恢复、还原已删除的资源，以及还原到某个时间点的另一个区域。 使用 连续备份配置帐户，根据业务需求选择适当的保留期。
- 探索 设计弹性应用程序指南，查看 SDK 的默认重试策略 ，并规划 特定暂时性错误的自定义处理。 这些指南将提供最佳做法，使应用程序代码能够复原到暂时性错误。
建议
| 建议 | 好处 |
|---|---|
| 跨可用性区域分配 Azure Cosmos DB 帐户（如果可用）。 | 可用性区域为部分副本 (replica)提供不同的电源、网络和冷却隔离硬件故障。 未使用可用性区域功能时，Azure Cosmos DB 有多个跨单个随机可用性区域的副本 (replica)。 如果使用可用性区域功能，副本 (replica)跨多个可用性区域。 |
| 将 Azure Cosmos DB 帐户配置为至少跨越两个区域。 | 跨越多个区域可防止帐户在发生隔离区域中断时完全不可用。 |
| 为帐户启用服务管理的故障转移。 | 服务管理的故障转移允许 Azure Cosmos DB 更改多区域帐户的写入区域以保留可用性。 此更改在没有用户交互的情况下发生。 了解与服务托管故障转移的权衡，并在必要时规划强制故障转移。 有关详细信息，请参阅 生成高可用性应用程序。 |
| 通过暂时禁用服务托管故障转移手动测试故障转移来验证可用性。 | 通过暂时禁用服务管理故障转移，可以使用脚本或Azure 门户启动手动故障转移来验证应用程序的端到端高可用性。 之后，可以重新允许服务管理的故障转移。 |
Azure Policy 定义
安全性
安全性是任何体系结构的关键部分，为了方便起见，可以轻松忽略这些体系结构。 通过在创建第一个资源或概念证明之前先考虑各种安全最佳做法，增强最终工作负荷的安全性。 本部分包括减少最终工作负荷安全漏洞数量的注意事项和建议。
设计清单
- 通过根据 Azure Cosmos DB 的安全基线设计使用专用终结点来减少外围攻击区域。
- 根据最低特权访问原则 ，创建对帐户的控制平面和数据平面访问权限的角色、组和分配。 请考虑 禁用基于密钥的身份验证。
- 在当前全局个人数据要求上下文中评估服务级别 合规性 和 认证 。
- 使用服务管理的密钥或客户管理的密钥（CMK）加密静态数据或动态数据。
- 使用控制平面日志审核用户访问、安全漏洞和资源操作。
- 使用 数据平面指标监视数据出口、数据更改、使用情况和延迟。
建议
| 建议 | 好处 |
|---|---|
| 至少实现数据保护和标识管理安全基线。 | 浏览安全基线，包括标识管理和数据保护。 实施建议来保护 Azure Cosmos DB 帐户。 |
| 尽可能禁用公共终结点并使用专用终结点。 | 避免将不必要或未使用的公共终结点留给帐户的外围应用攻击。 |
| 使用基于角色的访问控制来限制对特定标识和组的控制平面访问，以及在定义明确的分配范围内。 | 使用基于角色的访问控制来防止对帐户进行意外访问。 为访问 Azure Cosmos DB 的用户或应用程序分配适当的角色和权限。 |
| 创建虚拟网络终结点和规则以限制对帐户的访问。 | 实现虚拟网络服务终结点和防火墙规则，以限制对 Azure Cosmos DB 帐户的访问。 使用网络安全组（NSG）控制进出 Azure Cosmos DB 资源的入站和出站流量。 限制对受信任网络的访问并应用适当的网络安全措施有助于保护数据免受未经授权的访问。 |
| 遵循最佳软件开发做法来保护对数据的访问。 | 开发与 Azure Cosmos DB 交互的应用程序时，请遵循安全编码做法并执行安全代码评审。 防范常见的安全漏洞，例如注入攻击、跨站点脚本（XSS）或不安全的直接对象引用（IDOR）。 为常见 HTTP 状态代码实现输入验证、参数化查询和适当的错误处理，以防止安全风险。 |
| 监视控制平面日志是否存在违规。 | 监视有助于跟踪访问模式和审核日志，确保数据库保持安全且符合相关数据保护法规。 监视数据平面指标还有助于识别可能显示安全漏洞的不熟悉模式。 有关详细信息，请参阅 Azure 数据库的安全检查列表。 |
| 启用 Microsoft Defender for Azure Cosmos DB | Microsoft Defender 检测到尝试利用 Azure Cosmos DB for NoSQL 帐户中的数据库。 Defender 检测到潜在的 SQL 注入、可疑访问模式和其他潜在攻击。 |
Azure Policy 定义
成本优化
工作负荷的特征和解决方案的实现可能会影响 Azure 中运行的最终成本。 在设计工作负荷时，请考虑主要驱动程序，例如分区策略、一致性级别、副本 (replica)和写入类型。 调整工作负荷大小时，请考虑数据的读/写性质、平均项的大小、规范化和 TTL。 本部分包括简化工作负荷成本的注意事项和建议。
- 设计索引策略，该策略考虑你在工作负荷中通常执行的操作和查询。
- 确定分区键或分区键集，其值具有较高的卡性且不会更改。 使用现有指南和最佳做法来帮助选择适当的分区键。 此外，在确定分区键时，请考虑 索引策略 。
- 选择适合工作负荷的吞吐量分配架构。 查看在数据库或容器级别分发的标准吞吐量和自动缩放吞吐量的优点。 此外，请考虑在适当情况下无服务器。 在选择吞吐量分配方案的上下文中查看工作负荷的流量模式 。
- 考虑一致性级别，因为它们与工作负荷相关。 此外，请考虑客户端会话是否应更改默认一致性级别。
- 计算工作负荷的预期总体数据存储。 项和索引的大小都会影响数据存储成本。 计算副本 (replica)和备份对存储成本的影响。
- 创建策略以自动删除不再使用或必要的旧项。 如果需要，请将这些项目导出到低成本存储解决方案，然后再将其删除。
- 评估最常见的查询，以最大程度地减少跨分区查找。 使用此信息通知选择分区键或自定义索引策略的过程。
建议
| 建议 | 好处 |
|---|---|
| 监视 RU/s 利用率和模式。 | 使用指标从解决方案的开头监视 RU 消耗量。 使用查询和其他数据研究技术在应用程序代码中查找反模式。 |
| 自定义索引策略以映射到工作负荷。 | 默认索引策略为项中的所有路径编制索引，此策略可能会对 RU 消耗和成本产生重大影响。 仅根据需要为常见查询编制索引的路径使用索引策略。 对于写入密集型工作负荷，请禁用查询中不使用的列的自动索引。 |
| 选择最适合工作负荷的分区键[s]。 | 分区键[s] 应跨逻辑分区均匀分配吞吐量消耗和数据存储。 选择还应最大程度地减少未绑定跨分区查询的数量。 避免接收流量不成比例的热分区，因为不平衡分区会增加吞吐量成本和暂时性错误。 使用最常见的搜索查询来确定可能只执行单分区或边界跨分区查询的潜在分区键[s]。 |
| 在适合工作负荷时，在数据库或容器级别使用无服务器或预配吞吐量、手动预配或自动缩放。 | 比较预配的吞吐量类型 ，并选择适合工作负荷的选项。 通常，较小的和开发/测试工作负荷可能会受益于无服务器吞吐量或数据库级别的手动共享吞吐量。 更大的任务关键型工作负荷可能会受益于在容器级别分配的预配吞吐量。 |
| 为应用程序配置默认一致性级别。 如果适用， 请降级客户端会话中的默认一致性级别 。 | 可能并不总是需要更改标准默认一致性级别或在客户端会话中重写它。 考虑在更强一致性级别与读取相关的较高成本。 |
| 对于开发/测试工作负荷，请使用 Azure Cosmos DB 模拟器。 | Azure Cosmos DB 模拟器是开发/测试和持续集成的选项，可以节省开发团队这些常见工作负载的成本。 模拟器也可用作 Docker 容器映像。 |
| 使用事务批处理操作 | 设计分区，以利用逻辑分区键中的事务批处理操作进行插入。 在客户端 SDKS 中使用批处理操作在单个事务请求中插入、更新或删除多个文档。 此步骤可以减少单个请求的数量，最终可能导致更好的吞吐量效率。 |
| 使用投影来降低大型查询结果集的吞吐量成本。 | 创作查询以仅投影结果集中所需的最少字段数。 如果需要对字段进行计算，请评估执行这些计算服务器端与客户端的吞吐量成本。 |
| 避免使用未绑定的跨分区查询。 | 评估和创作查询以确保尽可能在单个逻辑分区中进行搜索。 使用查询筛选器控制查询目标逻辑分区。 如果查询必须跨逻辑分区进行搜索，请将查询绑定到仅搜索逻辑分区的子集，而不是完全扫描。 |
| 实现生存时间（TTL）以删除未使用的项目。 | 使用 TTL 自动删除不再需要的数据。 通过删除过期或过时的数据来管理存储成本。 如有必要，请将过期的数据导出到低成本的存储解决方案。 |
| 考虑用于大量聚合的分析存储。 | Azure Cosmos DB 分析存储会自动将数据同步到单独的列存储，以便针对大型聚合、报告和分析查询进行优化。 |
Azure Policy 定义
卓越运营
部署工作负荷后必须受到监视，以确保其按预期执行。 此外，监视工作负荷有助于在规划阶段解锁新效率，这不会立即明显。 在灾难性方案中，诊断数据是发现高严重性事件发生的原因的关键。 本部分包括监视工作负荷的事件和特征的注意事项和建议。
设计清单
- 起草日志和指标监视策略，以区分不同的工作负荷、标记异常方案、跟踪异常/错误中的模式以及跟踪主机性能。
- 设计大型工作负荷以尽可能使用批量操作。
- 定义多个警报，以监视限制、分析吞吐量分配以及跟踪数据的大小。
- 设计监视策略，以便跨区域提供解决方案。
- 创建并强制实施自动部署 Azure Cosmos DB for NoSQL 帐户和资源的最佳做法。
- 根据分区和索引设计规划预期的指标阈值。 确保有计划监视这些指标，以确定它们与计划阈值的接近程度。
建议
| 建议 | 好处 |
|---|---|
| 确保应用程序开发人员使用最新版本的开发人员 SDK。 | 每个 Azure Cosmos DB for NoSQL SDK 都有最低建议的版本。 有关详细信息，请参阅 .NET SDK 和 Java SDK。 |
| 在客户端应用程序中创建标识符以区分工作负荷。 | 考虑标志（如用户代理后缀）来标识每个日志条目或指标应与之关联的工作负荷。 |
| 使用开发人员 SDK 捕获补充诊断。 | 使用每个 SDK 的诊断注入技术添加有关工作负荷的补充信息以及默认指标和日志。 有关详细信息，请参阅 .NET SDK 和 Java SDK。 |
| 创建与主机资源关联的警报。 | 由于客户端主机问题，可能会出现连接性和可用性问题。 使用 Azure Cosmos DB for NoSQL SDK 通过客户端应用程序监视主机上的 CPU、内存和存储等资源。 |
| 将客户端 SDK 的批量功能用于大型操作。 | 需要高度吞吐量的方案受益于使用 SDK 的批量功能。 批量 功能 会自动管理和批处理操作，以最大程度地提高吞吐量。 |
| 为吞吐量限制创建警报。 | 使用警报跟踪超出预期阈值的吞吐量限制。 随着时间的推移，查看和调整警报，了解与 Azure Cosmos DB 相关的工作负荷的详细信息。 规范化 RU 消耗指标是度量数据库或容器上预配吞吐量的百分比的指标。 如果此指标一致为 100%，则请求可能会返回暂时性错误。 |
| 使用指标跟踪查询性能。 | 使用指标跟踪随时间推移排名靠前的查询的性能。 通过更新索引策略或更改查询来评估是否有效率。 如果查询性能不佳，请对性能进行故障排除并应用查询最佳做法。 有关详细信息，请参阅 查询性能提示。 |
| 使用模板自动部署帐户资源。 | 请考虑使用 Azure 资源管理器、Bicep 或 Terraform 模板自动部署帐户和后续资源。 确保团队使用相同的模板部署到其他非生产环境。 |
| 跟踪关键指标，以确定工作负荷中的常见问题。 | 使用特定指标查找工作负荷中的常见问题，包括但不限于：RU 利用率、按分区、限制和按类型请求卷的 RU 利用率。 有关详细信息，请参阅 监视数据参考。 |
Azure Policy 定义
性能效率
- 为应用程序定义性能基线。 测量可能需要处理的并发用户和事务数。 考虑工作负荷特征，例如平均用户流、常见操作和使用量峰值。
- 研究最常见的和最复杂的查询。 标识使用多个查找、联接或聚合的查询。 在分区键或索引策略的任何设计注意事项中考虑这些查询。
- 对于最常见的查询，请确定每个页面预期的结果数。 此数字将有助于正式化预提取结果的缓冲项计数。
- 研究目标用户。 确定哪些 Azure 区域最接近它们。
- 标识使用一个或多个排序字段的查询。 此外，确定影响多个字段的操作。 在索引策略设计中显式包括这些字段。
- 设计项目，使其相应的 JSON 文档尽可能小。 考虑根据需要拆分数据跨多个项。
- 识别子数组上的查询，并确定它们是否是更高效的子查询的候选项。
- 确定工作负荷是否需要分析存储。 对于极其复杂的查询，请考虑分析存储和 Azure Synapse Link 等服务。
| 建议 | 好处 |
|---|---|
| 根据性能基线配置吞吐量。 | 使用容量计算器等工具来确定性能基线所需的吞吐量量。 使用自动缩放等功能缩放实际吞吐量，以更紧密地匹配实际工作负荷。 之后监视实际吞吐量消耗情况并进行调整。 |
| 适当时，在客户端和服务器端使用优化技术。 | 利用内置 集成缓存。 配置 SDK 以管理预提取（缓冲）的项数，并为每个页面返回。 |
| 将 Azure Cosmos DB for NoSQL 部署到离最终用户最近的区域。 | 通过将 Azure Cosmos DB for NoSQL 部署到最靠近最终用户的区域来减少延迟。 利用读取副本 (replica)，无论如何配置写入（单区域或多个区域），都可以提供高性能的读取性能。 将 （.NET/Java） SDK 配置为更靠近最终用户的区域。 |
| 为 直接模式配置 SDK。 | 直接模式是最佳性能的首选选项。 此模式允许客户端直接打开与服务中的分区的 TCP 连接，并直接在没有中间网关的情况下发送请求。 此模式提供更好的性能，因为网络跃点较少。 |
| 禁用批量操作的索引编制。 | 如果有许多插入/替换/upsert 操作，请在使用 相应 SDK 的批量支持 的同时禁用索引以提高操作的速度。 以后可以立即重新启用索引编制。 |
| 为复杂操作中使用的字段创建复合索引。 | 复合索引可以按数量级顺序提高对多个字段的操作效率。 在许多情况下，对具有多个字段的语句使用复合索引。ORDER BY |
| 优化 SDK 的主机客户端计算机。 | 对于最常见的情况，请使用 SDK（.NET/Java）在 64 口主机上使用至少 4 核和 8 GB 内存。 此外，在主机上启用 加速网络 。 |
对大多数 SDK 中的类使用单一实例模式 CosmosClient 。 |
将大多数 SDK 中的客户端类用作单一实例。 客户端类管理其自己的生命周期，旨在不释放。 不断创建和释放实例可能会导致性能降低。 |
| 使项目大小小于 100 知识库(KB)大小。 | 较大的项消耗更多吞吐量，用于常见读取和写入操作。 对投影所有字段的较大项的查询也可能具有显著的吞吐量成本。 |
| 从战略上使用子查询来优化联接大型数据集的查询。 | 如果涉及多个数组且未筛选，则联接子数组的查询可能会增加复杂性。 例如，联接至少 10 个项的两个数组的查询可以扩展到 1,000 多个 元组。 使用子查询在项内联接数组之前筛选数组，从而优化自联接表达式。 对于跨分区查询，请优化查询，以包含分区键上的筛选器，以优化查询路由到尽可能少的分区。 |
| 对最复杂的查询使用分析工作负荷。 | 如果在大型容器上运行频繁的聚合或联接查询，请考虑在 Azure Synapse Analytics 中启用分析存储和执行查询。 |
Azure Policy 定义
额外资源
考虑更多与 Azure Cosmos DB for NoSQL 相关的资源。
Azure 体系结构中心指南
- 多租户和 Azure Cosmos DB
- 在零售业中使用 Azure Cosmos DB 进行视觉搜索
- 使用 Azure Cosmos DB 进行游戏开发
- 使用 Azure Cosmos DB 的无服务器应用
- 使用 Azure Cosmos DB 实现个性化