通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Azure 上任务关键型工作负荷的数据平台注意事项

  • 项目

选择有效的应用程序数据平台是一个进一步的关键决策领域，在其他设计领域具有深远的影响。 Azure 最终提供了许多关系数据平台、非关系和分析数据平台，这在功能上大相径庭。 因此，关键非功能要求必须与其他决策因素（如一致性、可操作性、成本和复杂性）一起充分考虑。 例如，在多区域写入配置中操作的能力将对全球可用平台的适用性产生重大影响。

此设计区域扩展了 应用程序设计，提供关键注意事项和建议，以告知选择最佳数据平台。

重要

本文是 Azure 架构良好的任务关键型工作负荷系列的一部分。 如果不熟悉此系列，我们建议从什么是任务关键型工作负荷开始 ？

大数据的四对

“四大大数据”提供了一个框架，以更好地了解高度可用数据平台的必要特征，以及如何使用数据来最大化业务价值。 因此，本部分将探讨如何在概念级别应用音量、速度、多样性和 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 定理所示。

    • 当读取器和编写器明显分布时，应用程序必须选择返回数据项的最快可用版本，即使它与另一个副本中该数据项的刚刚完成的写入（更新）相比，还是数据项的最新版本，这可能会导致额外的延迟来确定和获取最新状态。
    • 可以在平台级别或单个数据请求级别配置一致性和可用性。
    • 如果数据从最靠近用户的副本提供哪些用户体验，而该副本不反映不同副本的最新状态？例如，应用程序是否可以支持可能提供过时数据？

  • 在多区域写入上下文中，当在两个单独的写入副本中更改同一数据项后，才能复制任一更改，就会创建必须解决的冲突。

    • 可以应用标准化冲突解决策略，例如“上次写入胜利”或自定义逻辑的自定义策略。

  • 安全要求的实现可能会对吞吐量或性能产生不利影响。

  • 静态加密可以使用客户端加密在应用程序层中实现，并在必要时使用服务器端加密实现/或数据层。

  • Azure 支持各种加密模型，包括使用服务管理的密钥的服务器端加密、密钥库中的客户管理的密钥或客户控制的硬件上的客户管理的密钥。

    • 使用客户端加密，可以在密钥库或其他安全位置管理密钥。

  • MACsec（IEEE 802.1AE MAC）数据链接加密用于保护Microsoft主干网络上 Azure 数据中心之间移动的所有流量。

    • 数据包在发送之前在设备上进行加密和解密，防止物理“中间人”或窃听/窃听攻击。

  • 对数据平面和控制平面进行身份验证和授权。

    • 数据平台如何对应用程序访问和操作访问进行身份验证和授权？

  • 通过监视平台运行状况和数据访问实现可观测性。

    • 如何针对可接受的操作边界之外的条件应用警报？

设计建议

体积

  • 确保与有机增长相关的未来数据量不会超过数据平台功能。

    • 预测与业务计划相一致的数据增长率，并使用既定增长率来给出持续的容量需求。
    • 将汇总和每数据记录量与数据平台限制进行比较。
    • 如果在特殊情况下存在达到限制的风险，请确保实现操作缓解措施，以防停机和数据丢失。

  • 监视数据量并根据容量模型对其进行验证，同时考虑规模限制和预期的数据增长率。

    • 确保缩放操作符合存储、性能和一致性要求。
    • 引入新的缩放单元时，可能需要复制基础数据，这可能需要一段时间，并且可能会在复制时造成性能损失。 因此，如果可能，请确保这些操作在关键工作时间之外执行。

  • 定义应用程序数据层，以便根据使用情况和关键性对数据集进行分类，以便删除或卸载旧数据。

    • 请考虑将数据集分类为“hot”、“warm”和“cold”（“archive”）层。
      • 例如，基础参考实现使用 Azure Cosmos DB 来存储应用程序主动使用的“热”数据，而Azure 存储用于“冷”操作数据进行分析。

  • 配置管家过程以优化数据增长并提升数据效率，例如查询性能和管理数据扩展。

    • 为不再需要且没有长期分析值的数据配置生存时间（TTL）到期时间。
      • 验证在不对应用程序产生不利影响的情况下是否可以将旧数据安全地分层到辅助存储或是否可以直接删除旧数据。
    • 将非关键数据转移到辅助冷存储，但对其进行维护以进行分析和满足审核要求。
    • 收集数据平台遥测和使用情况统计信息，使 DevOps 团队能够持续评估管家要求和“大小正确的”数据存储。

  • 与微服务应用程序设计一致，请考虑并行使用多个不同的数据技术，并针对特定的工作负荷方案和卷要求使用优化的数据解决方案。

    • 避免创建单一的单片数据存储，因为可能难以管理扩展的数据量。

速度

  • 数据平台必须本质上设计并配置为支持高吞吐量，工作负荷分为不同的上下文，以使用方案优化的数据解决方案最大程度地提高性能。

    • 确保每个数据方案的读写吞吐量可以根据预期的负载模式进行缩放，且对意外变化有足够的容错。
    • 将不同的数据工作负载（例如事务性和分析性操作）分离到不同的性能上下文中。

  • 使用异步非阻止消息传送（例如使用 CQRS 或 事件溯源 模式）进行加载级别。

    • 写入请求之间可能存在延迟，以及何时有新数据可供读取，这可能会对用户体验产生影响。
      • 在关键业务需求的背景下，必须理解和接受这种影响。

  • 确保敏捷可伸缩性以支持可变吞吐量和负载级别。

    • 如果负载级别高度易失，请考虑过度预配容量级别，以确保保持吞吐量和性能。
    • 在无法维持吞吐量时测试并验证对复合应用程序工作负载的影响。

  • 通过自动缩放操作确定 Azure 本机数据服务的优先级，以便快速响应负载级别的波动。

    • 根据服务内部和应用程序设置的阈值配置自动缩放。
    • 缩放应在符合业务需求的时间范围内启动和完成。
    • 对于需要手动交互的方案，制定可以触发而不是执行手动操作的自动化操作“playbook”。
      • 考虑是否可以将自动化触发器作为后续工程投资的一部分应用。

  • 根据 P50/P99 延迟要求监视应用程序数据读取和写入吞吐量，并与应用程序容量模型保持一致。

  • 过度吞吐量应由数据平台或应用程序层正常处理，并由运行状况模型捕获，以用于操作表示形式。

  • 实现“热”数据方案的缓存，以最大程度地减少响应时间。

    • 为缓存过期和保留应用适当的策略，以避免数据增长失控。
      • 当支持数据更改时，缓存项过期。
      • 如果缓存过期时间严格基于生存时间（TTL），则需要了解为过时数据提供服务的影响和客户体验。

品种

  • 根据云和 Azure 原生设计的原则，强烈建议优先考虑托管的 Azure 服务，以减少运营和管理复杂性，并利用Microsoft未来的平台投资。

  • 根据松散耦合微服务体系结构的应用程序设计原则，允许各个服务使用不同的数据存储和方案优化的数据技术。

  • 验证所需的功能是否可用于选定的数据技术。

    • 确保支持所需的语言和 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。

    • 第一方 Azure Cosmos DB for NoSQL 提供最丰富的功能集，通常是首次提供新功能的 API。

  • Azure Cosmos DB 支持 网关和直接连接模式，其中 Direct 通过 TCP 与后端 Azure Cosmos DB 副本节点建立连接，以提高网络跃点的性能，而网关提供与前端网关节点的 HTTPS 连接。

    • 直接模式仅在使用 Azure Cosmos DB for NoSQL 时可用，目前仅在 .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 属性作为冲突解决路径应用时间同步时钟协议。 如果冲突解决路径值最高的项目成为赢家，并且如果多个项目具有相同的数值，则系统会选择一个赢家，以便所有区域可以聚合到已提交的项目的相同版本。
      • 删除冲突后，已删除的版本始终会赢得插入或替换冲突，而不考虑冲突解决路径值。
      • “最后写入者胜出”是默认的冲突解决策略。
      • 使用 Azure Cosmos DB for NoSQL 时，自定义数值属性（例如自定义时间戳定义）可用于冲突解决。
    • 自定义解决策略允许应用程序定义的语义使用检测到冲突时自动调用的已注册合并存储过程来协调冲突。
      • 在执行提交协议过程中，该系统可保证正好执行合并过程一次。
      • 自定义冲突解决策略仅适用于 Azure Cosmos DB for NoSQL，只能在容器创建时设置。

  • 在多区域写入配置中，依赖于单个 Azure Cosmos DB“中心”区域来执行所有冲突解决，并应用 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，以便在配置五个一致性级别中的任何一个时，为数据库帐户提供吞吐量、一致性、可用性和延迟。

    • 99.99% SLA 也适用于跨多个 Azure 区域的数据库帐户，这些区域配置了四个宽松一致性级别中的任何一个。

  • 可以在 Azure Cosmos DB 中预配两种类型的吞吐量，即标准吞吐量和 自动缩放，这些吞吐量是使用每秒请求单位（RU/秒）测量的。

    • 标准吞吐量分配保证指定 RU/s 值所需的资源。
      • 标准按小时计费，用于预配吞吐量。
    • 自动缩放定义最大吞吐量值，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 Policy 配置设置。

  • Microsoft Azure Cosmos DB 中的 Entra RBAC 支持适用于帐户和资源控制平面管理操作。

    • 应用程序管理员可以为用户、组、服务主体或托管标识创建角色分配，以授予或拒绝对 Azure Cosmos DB 资源上的资源和操作的访问权限。
    • 有多个 内置 RBAC 角色 可用于角色分配，自定义 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/s。

  • 可以根据两种不同的备份模式配置 Azure Cosmos DB。

    • 定期 是所有帐户的默认备份模式，其中备份按周期间隔进行，并通过与支持团队创建请求来还原数据。
      • 默认定期备份保留期为 8 小时，默认备份间隔为 4 小时，这意味着默认仅存储最新的两个备份。
      • 备份间隔和保留期在帐户中可配置。
        • 最长保留期延长至一个月，最小备份间隔为 1 小时。
        • 需要向 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）。
      • 可以使用 AZURE 门户 或 IaC 项目（如 ARM 模板）执行自助还原。
      • 连续备份存在一些 限制 。
        • 连续备份模式目前在多区域写入配置中不可用。
        • 目前只能为用于 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 数据工厂）的本机集成。

  • Azure Cosmos DB 文档表示实现自定义备份的两个潜在选项。

    • Azure Cosmos DB 更改源 ，用于将数据写入单独的存储设施。
    • 可以使用更改源实现连续或定期（批处理）自定义备份。
    • Azure Cosmos DB 更改源尚未反映删除，因此必须使用布尔属性和 TTL 应用软删除模式。
      • 当更改源提供完全保真更新时，不需要此模式。
    • Azure 数据工厂用于 Azure Cosmos DB 的连接器（用于 NoSQL 的 Azure Cosmos DB 或 MongoDB API 连接器）复制数据。
      • Azure 数据工厂 （ADF） 支持手动执行和计划、翻转窗口和基于事件的触发器。
        • 提供对存储和事件网格的支持。
      • ADF 主要用于定期自定义备份实现，因为它面向批处理的业务流程。
        • 由于业务流程执行开销，它不太适合使用频繁事件的连续备份实现。
      • ADF 支持高网络安全方案的Azure 专用链接

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，写入操作的 SLA 为 99.995% SLA）提供了更具吸引力的价格点。

    • 将应用程序配置为使用本地 Azure Cosmos DB 只读副本优化读取性能。

  • 选择最佳“中心”部署区域，其中冲突解决将在多区域写入配置中发生，所有写入操作都将在单区域写入配置中执行。

    • 在选择主要区域时考虑相对于其他部署区域和关联延迟的距离，以及可用性区域支持等必要功能。

  • 在支持 AZ 的所有部署区域中配置具有可用性区域（AZ）冗余的 Azure Cosmos DB，以确保对区域中的区域性故障的复原能力。

  • 使用 Azure Cosmos DB for NoSQL，因为它提供最全面的功能集，尤其是在性能优化方面。

    • 应主要考虑用于迁移或兼容性方案的替代 API。
      • 使用备用 API 时，验证所选语言和 SDK 是否提供了所需的功能，以确保最佳的配置和性能。

  • 使用直接连接模式通过与后端 Azure Cosmos DB 节点的直接 TCP 连接来优化网络性能，减少网络“跃点数”。

Azure Cosmos DB SLA 是通过平均失败的请求来计算的，这些请求可能与 99.999% 的可靠性层错误预算不直接对齐。 在设计 99.999% SLO 时，因此，规划区域和多区域 Azure Cosmos DB 写入不可用至关重要，确保在故障（例如用于后续重播的持久消息队列）时定位回退存储技术。

  • 跨逻辑分区和物理分区定义分区策略，以便根据数据模型优化数据分布。

    • 最大限度地减少跨分区查询。
    • 以迭代方式 测试和验证 分区策略，以确保最佳性能。

  • 选择最佳分区键。

    • 在集合中创建分区键后，无法更改分区键。
    • 分区键应为不更改的属性值。
    • 选择具有高基数的分区键，其可能值范围很广。
    • 分区键应跨所有逻辑分区均匀分布 RU 消耗和数据存储，以确保在物理分区之间均匀分布 RU 消耗和存储分布。
    • 针对分区列运行读取查询，以减少 RU 消耗和延迟。

  • 索引对于性能也至关重要，因此请确保使用索引排除来减少 RU/s 和存储要求。

    • 仅在查询中筛选所需的字段编制索引;为最常用的谓词设计索引。

  • 利用 Azure Cosmos DB SDK 的内置错误处理、重试和更广泛的可靠性功能。

  • 使用服务管理的加密密钥来降低管理复杂性。

    • 如果客户管理的密钥有特定的安全要求，请确保应用适当的密钥管理过程，例如备份和轮换。

  • 通过应用内置的 Azure Policy 禁用 基于 Azure Cosmos DB 密钥的元数据写入访问权限 。

  • 启用 Azure Monitor 以收集关键指标和诊断日志，例如预配吞吐量（RU/秒）。

    • 将 Azure Monitor 操作数据路由到专用于 Azure Cosmos DB 的 Log Analytics 工作区以及应用程序设计中的其他全局资源。
    • 使用 Azure Monitor 指标来确定应用程序流量模式是否适合自动缩放。

  • 评估应用程序流量模式，为 预配的吞吐量类型选择最佳选项。

    • 考虑自动缩放预配的吞吐量以自动横向扩展工作负荷需求。

  • 评估 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 提供了许多托管关系数据平台，包括Azure SQL 数据库和 Azure Database for common OSS 关系解决方案，包括 MySQL、PostgreSQL 和 MariaDB。 因此，本部分中的设计注意事项和建议将侧重于Azure SQL 数据库和 Azure 数据库 OSS 风格的最佳使用，以最大限度地提高可靠性和全球可用性。

设计注意事项

  • 虽然关系数据技术可以配置为轻松缩放读取操作，但写入通常受限于单个主实例，这会对可伸缩性和性能产生重大约束。

  • 分片 可用于跨多个相同的结构化数据库分布数据和处理，水平分区数据库以导航平台约束。

    • 例如，分片通常在多租户 SaaS 平台中应用，以将多组租户隔离到不同的数据平台构造中。

Azure SQL 数据库

  • 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 的数据库应用预留容量。

  • 时间点还原 可用于将数据库和包含的数据返回到以前的时间点。

  • 异地还原 可用于从异地冗余备份恢复数据库。

Azure Database For PostgreSQL

  • Azure Database For PostgreSQL 在三种不同的部署选项中提供：

    • 单一服务器 SLA 99.99%
    • 灵活服务器，提供可用性区域冗余，SLA 99.99%
    • 启用高可用性模式时，超大规模（Citus），SLA 99.95%。

  • 超大规模（Citus） 通过分片提供动态可伸缩性，而无需更改应用程序。

    • 跨多个 PostgreSQL 服务器分布表行是确保超大规模（Citus）中的可缩放查询的关键。
    • 多个节点可以集体保存比传统数据库更多的数据，在许多情况下，可以使用辅助角色 CPU 来优化成本。

  • 可以通过 Runbook 自动化配置自动缩放 ，以确保响应更改流量模式的弹性。

  • 灵活服务器通过停止/启动服务器以及适用于不需要连续计算容量的工作负荷的可突发计算层，为非生产工作负荷提供成本效益。

  • 备份存储最多 100% 的预配服务器存储无需额外付费。

    • 备份存储的额外消耗量根据消耗的 GB/月收费。

  • 可以使用单服务器预留折扣或超大规模（Citus）预留折扣来降低与 Azure Database for PostgreSQL 关联的计算成本。

设计建议

  • 考虑分片以根据不同的应用程序和数据上下文对关系数据库进行分区，有助于浏览平台约束、最大程度地提高可缩放性和可用性，以及实现故障隔离。

    • 当应用程序设计考虑三个或多个 Azure 区域时，此建议尤其普遍，因为关系技术约束可能会显著阻碍全球分布式数据平台。
    • 分片并非适用于所有应用方案，因此需要根据上下文进行评估。

  • 由于 Azure SQL 数据库在 Azure 平台上很成熟以及具有大量的可靠性功能，因此需要满足关系要求时优先使用 Azure SQL 数据库。

Azure SQL 数据库

  • 使用业务关键服务层最大程度地提高可靠性和可用性，包括对关键复原能力功能的访问权限。

  • 使用基于 vCore 的消耗模型有助于独立选择计算和存储资源，根据工作负荷量和吞吐量要求定制。

    • 确保应用定义的容量模型来通知计算和存储资源要求。

  • 配置区域冗余部署模型，以跨可用性区域分散在同一区域中业务关键数据库副本。

  • 使用 活动异地复制 在所有部署区域中部署可读副本（最多四个）。

  • 使用自动故障转移组向次要区域提供 透明故障转移 ，并应用异地复制，以便向其他部署区域提供复制，以便进行读取优化和数据库冗余。

    • 对于仅限两个部署区域的应用方案，应优先使用自动故障转移组。

  • 考虑自动化操作触发器（基于与应用程序运行状况模型保持一致的警报）在影响自动故障转移组内的主实例和辅助实例时执行到异地复制实例的故障转移。

重要

对于考虑超过四个部署区域的应用程序，应认真考虑应用程序范围的分片或重构应用程序以支持多区域写入技术，例如 Azure Cosmos DB。 但是，如果应用程序工作负荷方案中这不可行，建议将单个地理位置中的区域提升为主要状态，包括异地复制实例以更均匀地分布的读取访问。

  • 将应用程序配置为查询副本实例以进行读取查询，从而优化读取性能。

  • 在 Azure SQL DB 中使用 Azure Monitor 和 Azure SQL Analytics 进行近实时操作见解，以检测可靠性事件。

  • 使用 Azure Monitor 评估所有数据库的使用情况，以确定其大小是否合适。

    • 确保 CD 管道考虑在代表性负载水平下进行负载测试，以验证相应的数据平台行为。

  • 计算数据库组件的运行状况指标，以观察与业务需求和资源利用率相关的运行状况，并在适当情况下使用 监视和警报 来推动自动化操作。

    • 确保合并关键查询性能指标，以便在发生服务降级时快速采取措施。

  • 使用 查询性能见解 和Microsoft提供的常见 性能建议 优化查询、表和数据库。

  • 使用 SDK 实现重试逻辑，以缓解影响Azure SQL 数据库连接的暂时性错误。

  • 在应用服务器端透明数据加密（TDE）进行静态加密时，优先使用服务管理的密钥。

    • 如果需要客户管理的密钥或客户端（AlwaysEncrypted）加密，请确保使用备份和自动轮换设施适当复原密钥。

  • 请考虑将 时间点还原 用作操作 playbook，以便从严重的配置错误中恢复。

Azure Database For PostgreSQL

  • 建议将灵活服务器用于业务关键工作负荷，因为它的可用性区域支持。

  • 将“超大规模”（Citus）用于业务关键工作负荷时，启用高可用性模式以接收 99.95% SLA 保证。

  • 使用“超大规模”（Citus）服务器配置将多个节点的可用性最大化。

  • 为应用程序定义容量模型，以通知数据平台中的计算和存储资源要求。

热层数据的缓存

可以通过显著增加读取吞吐量和改善热层数据方案的端到端客户端响应时间来应用内存中缓存层来增强数据平台。

Azure 提供了多个适用于缓存密钥数据结构的功能的服务，Azure Redis 缓存定位为抽象和优化数据平台读取访问权限。 因此，本部分将重点介绍 Azure Redis 缓存在需要额外的读取性能和数据访问持久性的情况下的最佳使用。

设计注意事项

  • 缓存层提供额外的数据访问持久性，因为即使中断影响基础数据技术，应用程序数据快照仍可通过缓存层进行访问。

  • 在某些工作负荷方案中，可以在应用程序平台本身中实现内存中缓存。

用于 Redis 的 Azure 缓存

  • Redis 缓存是开放源代码 NoSQL 键值内存中存储系统。

  • 企业层和企业闪存层可以通过异地复制跨区域中可用性区域和不同的 Azure 区域部署在主动-主动配置中。

    • 在每个区域中至少部署三个 Azure 区域和三个或更多个可用性区域时，为所有缓存实例启用活动异地复制时，Azure Redis 缓存提供 99.999% 的 SLA，用于连接到一个区域缓存终结点。
    • 在单个 Azure 区域中跨三个可用性区域部署时，会提供 99.99% 的连接 SLA。

  • 企业闪存层在 RAM 和闪存非易失性内存存储的组合上运行，尽管这引入了一个较小的性能损失，但它还支持非常大的缓存大小，最多 13TB 的群集。

  • 使用异地复制时，除了与缓存实例关联的直接成本外，区域之间的数据传输费用也将适用。

  • 计划更新功能不包括应用于基础 VM 操作系统的 Azure 更新或更新。

  • 在横向扩展操作期间，数据迁移到新实例时，CPU 使用率将增加。

设计建议

  • 考虑为“热”数据方案优化缓存层，以提高读取吞吐量并缩短响应时间。

  • 对缓存到期和保养工作应用适当的策略，以避免数据增长失控。

    • 考虑在支持数据更改时使缓存项过期。

用于 Redis 的 Azure 缓存

  • 使用高级或企业 SKU 最大程度地提高可靠性和性能。

    • 对于数据量非常大的方案，应考虑 Enterprise Flash 层。
    • 对于只需要被动异地复制的方案，也可以考虑 Premium 层。

  • 在所有考虑的部署区域中，在活动配置中使用异地复制部署副本实例。

  • 确保在每个考虑的 Azure 区域中跨可用性区域部署副本实例。

  • 使用 Azure Monitor 评估 Azure 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 （5） 分钟。
      • 自动同步完成后，可以从 Azure Synapse 查询最新数据。
    • 分析存储存储使用基于 消耗的定价模型，该模型 对数据量和读取和写入操作数收费。 分析存储定价独立于事务存储定价。

  • 使用 Azure Synapse Link，可以直接从 Azure Synapse 查询 Azure Cosmos DB 分析存储。 这样就可以从 Synapse 进行无 ETL 混合事务分析处理（HTAP），以便几乎实时地查询来自 Synapse 的其他分析工作负荷的 Azure Cosmos DB 数据。

  • 默认情况下，Azure Cosmos DB 分析存储未分区。

    • 对于某些查询方案，通过使用 查询谓词中经常使用的键对分析存储 数据进行分区来提高性能。
    • 分区由 Azure Synapse 中的作业触发，该作业使用 Synapse Link 运行 Spark 笔记本，该作业从 Azure Cosmos DB 分析存储加载数据，并将其写入 Synapse 工作区的主存储帐户中的 Synapse 分区存储中。

  • Azure Synapse Analytics SQL Serverless 池可以通过自动更新的视图或通过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 机器学习模型。

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

设计建议

  • 确保分析性工作负载不影响事务性应用程序工作负载，从而维持事务性性能。

应用程序分析

  • 将 Azure Synapse Link 与 Azure Cosmos DB 分析存储配合使用，通过创建优化数据存储（不会影响事务性能）对 Azure Cosmos DB 操作数据执行分析。

  • 使用 Azure Synapse Link 设置 Azure Cosmos DB 分析存储的优先级，而不是使用 Azure Cosmos DB 更改源来维护分析数据存储。

    • Azure Cosmos DB 更改源可能适用于非常简单的分析方案。

AIOps 和 Operational Analytics

  • 为每个源创建一个 Azure Synapse 工作区，其中包含链接服务和数据集Azure 存储帐户，其中将资源中的操作数据发送到其中。

  • 创建专用Azure 存储帐户，并将其用作工作区主存储帐户来存储 Synapse 工作区目录数据和元数据。 使用分层命名空间对其进行配置，以启用 Azure Data Lake Gen2。

    • 在源分析数据和 Synapse 工作区数据和元数据之间保持隔离。
      • 请勿使用发送操作数据的区域或全局Azure 存储帐户之一。

下一步

查看有关网络注意事项的注意事项。

网络连接和连接