Join us at MongoDB.local London on 7 May to unlock new possibilities for your data. Use WEB50 to save 50%.
Register now >
Docs 菜单
Docs 主页
/ /
/ / /

操作数据层

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

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

  • 只读:用作高性能只读副本,以卸载来自源系统的查询并针对操作数据公开稳定的 API。

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

  • 读写:接受写入作为业务工作流程的一部分,实现操作现代化,并逐渐减少对遗留记录系统的依赖。

使用MongoDB的操作数据层的实现级别
点击放大

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

注意

下图说明了可实现开放数据层 (ODL) 的不同级别。它只是为了澄清概念,并不是作为该解决方案的参考架构。

操作数据层参考架构
点击放大

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

  1. 源系统

    企业应用程序、操作数据库、第三方 API 和传统平台充当记录系统。它们捕获业务事务和事件,并将其同步到 ODL 中,以便进行实时和上下访问权限。

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

  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. 消费类应用程序

    运营应用程序、Gen AI和代理AI系统以及BI工具使用MongoDB原生驱动程序、 Atlas SQL和连接器连接到 ODL。它们受益于整合、受管控且近乎实时的企业数据视图,而无需直接依赖传统系统。

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

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

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

  • 延迟与摄取费用:ODL 可以提供服务延迟查询,但数据新鲜度取决于摄取数据的方式。批量 ETL/ELT、CDC 和实时流媒体(示例通过MongoDB Kafka Connector和Atlas Stream Processing)具有不同的操作和费用概况。为真正需要近乎实时更新的使用案例保留始终在线的流媒体。

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

  • ODL 适用范围:ODL 最适合统一分散的运营数据;它们并不是为了取代纯粹的分析平台。虽然 ODL 并不是为了直接替代核心记录系统而设计的,但它可以提供服务多步骤迁移策略的第一步,随着时间的推移,该策略最终将取代传统记录系统。

1
  • 确定主节点 (primary node in the replica set)使用案例和业务领域(示例,支付中心、客户 360、统一商务、网络保障等)。

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

  • 根据风险承受能力、对遗留系统的依赖程度和现代化目标,决定是否从只读、扩展或写入ODL 开始。

2
3
  • 围绕 ODL 实施层级访问权限层:

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

    • 服务网格:使用 Istio Linkerd 等工具,通过双向 TLS、重试和跟踪来保护和观察服务到服务的流量。

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

4
  • OLTP:将事务性读取和写入路由到主节点 (primary node in the replica set)节点,以保证核心业务流的一致性和延迟操作。

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

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

5
  • 传输中和静态加密:对所有外部访问权限点实施 TLS,并使用Atlas内置加密功能来满足数据保护要求。

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

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

  • 审核和管理:使用 ODL 作为数据脱敏、聚合和访问权限策略的执行点,以便生产者和消费者保持解耦,同时跨域一致地管理。

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

后退

hybrid

在此页面上