多模型数据库的出现，核心背景并非“数据库种类不足”，而是业务系统的复杂度在持续攀升。在真实项目落地中，“关系型数据库 + 图数据库”的混用模式，往往正是架构复杂度加速上升的关键起点。

这里需要明确：这并非图数据库本身存在缺陷，而是当两种不同模型的数据库被应用于同一业务链路、承载关联业务逻辑时，架构复杂度会以非线性方式快速增长——这种增长速度，往往远超我们在设计初期的预期。

从一个问题拆成两个割裂的系统

引入图数据库的初衷，往往非常合理：随着业务发展，关系型数据库在多跳关系查询场景下的性能瓶颈日益凸显，查询效率越来越难以满足业务需求。

由此，架构演进的路径也逐渐固定为：

• 原有关系型数据库继续承载核心职责，存储实体数据与核心业务字段；
• 新增图数据库，专门存储实体之间的关联关系，聚焦多跳查询能力；
• 应用层额外承担衔接职责，在两个数据库系统之间拼装数据、整合查询结果。

在设计阶段，这种拆分看似清晰且合理：关系型数据库负责回答“数据是什么”，图数据库负责回答“数据怎么连”，边界分明、各司其职。但问题的核心的是，真实的业务查询需求，从来不会严格遵循这种人为划分的边界。

真实查询场景，很少只落在一个模型里

在实际业务运转中，绝大多数查询需求都是“属性 + 关系”的混合模式，而非单一聚焦于某一种数据模型。例如：

• 先查询“最近 30 天活跃的用户”（属性过滤，依赖关系型数据库），再分析这些活跃用户之间的好友、互动关系（多跳查询，依赖图数据库）；
• 先筛选出“高风险账户”（基于账户属性、交易记录的过滤，依赖关系型数据库），再沿着账户关联路径向外扩散，排查潜在风险关联方（关系遍历，依赖图数据库）；
• 先基于多维度属性筛选出目标实体，再对这些实体进行多跳关联分析，挖掘隐藏的关联规律。

这些查询在业务逻辑上是一个完整的闭环，但在“关系 + 图”混用架构下，却被迫拆分成多步繁琐操作：

1. 在关系型数据库中，基于属性条件筛选出目标实体；
2. 将筛选结果通过同步或实时传入的方式，推送至图数据库；
3. 在图数据库中，基于传入的实体执行关系遍历、多跳查询；
4. 将图数据库的查询结果回传至应用层，与关系型数据库的原始数据拼装、二次处理，最终返回给业务侧。

这里的复杂度，从来不是来自数据库本身的性能或易用性，而是来自“跨系统拼接查询语义”的额外成本——应用层需要额外处理两个系统的数据衔接、格式兼容，还要应对中间环节的异常问题。

数据一致性问题，比想象中更难处理

当实体数据（存储在关系型数据库）与关系数据（存储在图数据库）分散在两个独立系统中时，数据一致性问题几乎无法避免，且大多隐蔽难排查。常见的异常场景包括：

• 关系型数据库中的实体已被删除，但图数据库中该实体对应的关联关系仍未清理，导致查询出现“幽灵关系”；
• 关系型数据库中实体的核心属性已更新（如用户状态、账户等级），但图数据库中依赖该属性的关系分析，仍基于旧数据执行，导致分析结果失真；
• 同一个业务动作（如用户解绑好友），需要同时更新关系型数据库的用户状态和图数据库的好友关联关系，两个操作无法原子执行，易出现“一边成功、一边失败”的不一致场景。

为了应对这些一致性问题，系统往往需要额外引入一系列辅助机制：

• 引入事件驱动架构或消息队列，实现两个数据库之间的数据同步；
• 设计补偿机制与定期校验任务，排查并修复不一致的数据；
• 被迫接受“宽松的一致性假设”，降低业务对数据实时一致性的要求。

这些机制本身并无对错，但它们会逐步改变系统的设计重心——让业务系统从“以业务逻辑为核心”，逐渐异化为“以容错、纠错为核心”，大量开发精力被消耗在一致性维护上，而非业务创新本身。

事务语义被拆碎，是最容易被忽视的问题

在单一数据库系统中，事务的边界清晰、语义完整，即一个业务操作对应的所有数据变更，都可以包裹在一个事务中，实现“原子性、一致性、隔离性、持久性”，异常时只需简单回滚即可。

但在“关系 + 图”混用架构下，事务语义会被彻底拆碎，原本简单的业务操作，变得异常复杂：

• 一个完整的业务操作，被拆分成多个独立的数据库操作（一部分在关系型数据库，一部分在图数据库）；
• 原本可实现的强一致事务，被迫退化为最终一致，业务需要承受中间状态的不确定性；
• 事务的回滚逻辑，从数据库层转移到应用层，需要开发者手动设计回滚方案，应对各种异常场景。

这种拆分带来的直接后果是：

• 业务代码中出现大量冗余的“状态判断”，用于校验两个系统的操作结果；
• 错误处理逻辑侵入核心业务流程，导致代码可读性、可维护性大幅下降；
• 系统行为越来越难以推理，排查一个异常需要跨两个数据库、梳理完整的调用链路，定位成本极高。

从长期来看，这种由事务拆分带来的复杂度，对系统稳定性的侵蚀，往往远超单点性能问题——性能可以通过扩容、优化缓解，但混乱的事务逻辑，会逐渐成为系统的“隐形债务”。

架构复杂度会反过来限制业务演进

当系统的复杂度累积到一定阈值后，架构本身会开始“反噬”业务，成为业务迭代的绊脚石。此时，技术不再是业务的支撑，反而变成了业务演进的约束。具体表现为：

• 一个简单的新需求，需要同时改动关系型数据库、图数据库和应用层的衔接逻辑，开发、测试成本翻倍；
• 系统出现异常时，排查问题需要跨多个技术栈（关系型数据库、图数据库、消息队列、应用层），定位一个小问题可能需要数天时间；
• 技术决策越来越保守，为了避免破坏现有复杂的衔接逻辑，团队不敢轻易尝试新的技术方案，甚至会拒绝一些合理的业务优化需求。

此时，即便图数据库本身具备极强的查询性能和扩展性，也很难充分发挥其价值——大部分精力都被消耗在架构衔接、问题排查上，而非利用图数据库的优势赋能业务。

问题并不在“图”，而在“分裂的数据视图”

再次强调：我们并非否定图数据库的价值，也不是说“关系 + 图”混用一定不可行。真正的问题，从来不在“使用了图数据库”，而在于“人为拆分了业务的数据视图”。

同一个完整的业务视图，被强行拆分成两个独立的数据视图：关系型数据库存储实体和属性，图数据库存储关联关系。这种拆分，让开发者不得不在应用层，额外承担“整合数据语义”的职责——而这部分工作，本应是数据库自身需要承担的核心能力之一。

简单来说：业务看到的是“实体 + 关系”的完整数据，而架构层面却把它拆成了两部分，中间需要应用层“粘起来”——这个“粘贴”的过程，就是所有复杂度的根源。

回到多模型的思路：统一，而不是叠加

多模型数据库的出现，核心要解决的问题，并不是“图数据库性能不够”，也不是“关系型数据库不够灵活”，而是如何打破这种数据视图的分裂，实现“实体 + 关系”的统一管理。具体来说，就是要回答三个核心问题：

• 是否可以在一个系统中，同时高效存储和表达实体、属性与关联关系，无需跨系统拆分？
• 是否可以在一次查询中，同时完成属性过滤与关系遍历，无需应用层多步拼装？
• 是否可以在一个统一的事务语义下，完成实体与关系的数据更新，避免事务拆分带来的一致性问题？

以 ArangoDB 这类多模型数据库为例，它的设计重点并非“取代所有数据库”，而是在需要混合查询的核心业务路径中，避免人为拆分数据模型——将实体、属性、关系统一存储在一个系统中，支持一次查询完成“属性筛选 + 多跳关系遍历”，同时保证事务的原子性，从根源上减少跨系统衔接带来的复杂度。

写在最后

“关系 + 图”混用本身并不是错误的选择，但它有一个不可逾越的前提：业务边界清晰、系统规模可控，且团队有足够的精力长期承担复杂度维护的成本。

但在实际业务中，当复杂度已经成为制约业务发展的主要矛盾时，继续通过“增加一个数据库”的方式解决单点问题，往往只会陷入“越叠加、越复杂”的恶性循环，系统会变得越来越臃肿，维护成本越来越高，最终反过来限制业务的迭代速度。

而这，正是多模型数据库被提出的真正背景之一：不是为了“多一种选择”，而是为了“少一种拆分”，用统一的数据视图，化解混合查询带来的架构复杂度。