对于AI助手:文档索引位于 https://www.mongodb.com/zh-cn/docs/llms.txt — 通过将 .md 附加到任何URL路径,可以获得所有页面的降价版本。
Make the MongoDB docs better! We value your opinion. Share your feedback for a chance to win $100.
MongoDB Branding Shape
Click here >
Docs 菜单

操作数据层

此参考架构介绍了如何在 MongoDB Atlas 上实现操作数据层 (ODL),以整合孤立的操作数据,并为下游操作型、分析型和 AI 工作负载提供服务。

ODL 是一种架构模式,可将现有记录系统中的数据集成并组织到集中且可查询的层中。它将现代应用程序和数据产品与旧版平台解耦,使企业无需完全替换这些系统,也能支持单一视图、数据即服务以及 AI/智能体 AI 用例等举措。MongoDB Atlas 为 ODL 提供核心数据平台,并在单一服务中将灵活的文档模型与事务型、搜索、分析和向量功能相结合。

  • 只读:作为高性能读取副本,用于分担源系统的查询负载,并基于操作数据公开稳定的 API。

  • 丰富:将源数据与元数据和外部数据集相结合,为分析和 AI 提供情境视图,无需修改上游系统。

  • 读写:作为业务工作流的一部分接受写入,以实现运营现代化,并逐步减少对旧版记录系统的依赖。

MongoDB 操作数据层的实现级别

图 1. MongoDB 操作数据层的实现级别。

点击放大

注意

下图展示了可实现操作数据层 (ODL) 的不同级别。它仅用于说明概念,并非此解决方案的参考架构。

操作数据层参考架构

图 2. 操作数据层参考架构

点击放大
  1. 源系统

    企业应用程序、操作数据库、第三方 API 和旧版平台作为记录系统。它们会捕获业务事务和事件,您可以将这些数据同步到 ODL,以实现实时且上下文感知的访问。

    • 常见源系统包括:大型机、CRM、ERP、订单管理、供应链管理、人力资源、计费、营销自动化、网站、社交媒体、参考数据、第三方 API、日志、时间序列数据等。
  2. 数据摄取层

    数据通过批处理提取-转换-加载 (ETL)/提取-加载-转换 (ELT) 作业,以及实时流式传输或变更数据捕获 (CDC),从源系统进入 MongoDB Atlas。使用 mongoimport、批量写入 API、ETL 平台、MongoDB Kafka Connector 和 Atlas Stream Processing 等工具,根据延迟和吞吐量要求加载、转换和路由事件。

  3. 操作数据层 (MongoDB Atlas)

    MongoDB Atlas 集群将结构化、半结构化和非结构化数据整合到文档数据模型中,并支持混合工作负载:通过统一查询 API 进行事务处理、实时分析、全文搜索和向量搜索。ODL 在云端运行,并通过分片和副本集进行水平扩展。

  4. 处理/服务层

    API 网关位于边缘,负责管理身份验证、速率限制和外部访问。服务网格负责治理服务间通信,数据代理层则根据工作负载类型路由查询,同时应用连接池、缓存和策略强制执行。MongoDB Change Streams 和 Atlas Stream Processing 可以将数据变更发布给下游使用方,而无需轮询。

  5. 使用方应用程序

    操作型应用程序、生成式 AI 和智能体 AI 系统,以及 BI 工具,可通过 MongoDB 原生驱动程序、Atlas SQL 和连接器连接到 ODL。它们可以利用统一、受治理且近实时的企业数据视图,而无需直接依赖旧版系统。

要在 MongoDB Atlas 上保持高性能 ODL,您必须在复杂性与架构目标之间取得平衡:

  • 双写入协调(写入ODL):写入(“Y 加载”)ODL 会带来 ODL 和旧版系统之间数据漂移的风险。使用消息传递平台或 API 网关与事务发件箱saga模型等模式一起使用来协调写入并定义明确的一致性保证,而不是依赖分布式锁或 2PC(两阶段提交)。

  • 工作负载隔离 — OLTP、在线分析处理 (OLAP) 和 AI:直接在主节点上运行分析或 AI 工作负载会降低事务性能。为避免这种情况,请使用支持 secondaryPreferred 读取的副本集、分片集群以及专用的搜索和向量索引来隔离每种工作负载类型,确保在线事务处理 (OLTP)、分析和检索增强生成 (RAG)/AI 查询不会争用相同资源。

  • 延迟与摄取成本:ODL 可以支持低延迟查询,但数据时效性取决于数据摄取方式。批量 ETL/ELT、CDC 和实时流式传输(例如通过 MongoDB Kafka Connector 和 Atlas Stream Processing 实现)具有不同的运维和成本特征。请仅将始终开启的流式传输保留给真正需要近实时更新的用例。

  • 模式演进和文档增长:MongoDB 灵活的 document model 支持快速模式演进,但仍然需要规范的设计。应用既定的模式设计模式和嵌入与引用指导,避免团队之间的文档臃肿、深度嵌套结构和不兼容的模式漂移,尤其是在高度丰富的 ODL 中。

  • ODL 的适用场景:ODL 适合用于统一分散的操作数据;它们并非旨在取代纯分析平台。虽然 ODL 并非旨在直接取代核心记录系统,但它可以作为多步迁移策略中的第一步,随着时间的推移最终取代旧版记录系统。

1
  • 确定您的主要用例和业务领域(例如支付中心、客户 360、统一商务、网络保障等)。

  • 选择一种架构风格,如事件驱动、微服务或以API为中心,并与现有环境保持一致。

  • 根据风险承受能力、对旧版系统的依赖程度和现代化目标,决定从只读型、增强型还是读写型 ODL 入手。

2
  • 设计集合:使用 MongoDB 模式设计模式。将经常一起读取的数据嵌入;对于大型或独立实体,则使用引用,以减少重复并让文档保持易于管理。

  • 批量摄取:使用 mongoimport批量写入 API、Atlas Data Federation物化或 ETL 工具从源系统加载计划导出。

  • ETL/ELT:使用 MongoDB Spark Connector 和编排工具提取数据,然后在加载前转换数据 (ETL),或先将原始数据加载到 Atlas,再使用聚合管道进行转换 (ELT)。

  • 实时摄取:使用 MongoDB Kafka ConnectorAtlas Stream Processing 构建事件驱动型管道,捕获 CDC 流或主题事件,并以低延迟将其写入 Atlas。

3
  • 实现一个围绕 ODL 的三层访问层:

    • API 网关:终止外部客户端连接,处理身份验证和速率限制,并使用 KongTraefik 等平台提供协议转换(REST、GraphQL、gRPC、WebSocket)。

    • 服务网格:使用 IstioLinkerd 等工具,通过双向 TLS、重试和跟踪来保护和观测服务间流量。

    • 数据代理层:集中管理连接,并根据工作负载类型将查询路由到 MongoDB Atlas,同时在靠近数据的位置应用连接池、缓存和策略强制执行。

4
  • OLTP:将事务读取和写入路由到主节点,以保证核心业务流程的一致性和低延迟运行。

  • OLAP/BI:使用 secondaryPreferred 将分析和报告工作负载路由到从节点,并考虑对历史数据或冷数据使用 Atlas Data Federation 或物化视图,以避免影响操作型工作负载。

  • AI/RAG:使用 MongoDB Vector Search 对与操作数据一起存储的嵌入向量进行语义和混合搜索,并通过聚合管道将结果与元数据相结合,为智能体和 LLM 驱动型应用程序提供服务。

5
  • 对传输中和静态数据进行加密:对所有外部接入点强制执行 TLS,并使用 Atlas 中的内置加密功能来满足数据保护要求。

  • 管理身份和访问权限:实施 OpenID Connect (OIDC) 和 OAuth 2.0 等行业标准协议,以处理身份验证并颁发包含基于角色声明的标准化令牌(如 JSON Web Token)。利用解耦授权模式,在 API 和服务层实施细粒度、基于策略的访问控制,确保安全逻辑与应用程序代码分离。

  • 集中管理密钥:虽然 OIDC 和 OAuth 2.0 用于处理用户和服务身份,但 ODL 仍依赖存在于令牌生命周期之外的凭证和密钥。其中包括数据库连接凭证、OAuth 客户端密钥、TLS 证书和加密密钥。请使用专用的密钥管理解决方案(例如 Vault 服务、由 HSM 支持的密钥管理器或云服务提供商原生的密钥存储)来存储和轮换这些凭证和密钥,然后将其注入运行时,而不是嵌入配置文件。

  • Atlas 审核和治理:将 ODL 作为数据掩码、聚合及访问策略的统一执行点,让生产者和使用方保持解耦,同时确保治理在各业务域中一致应用。

探索不同行业如何实施 ODL: