ONNX Runtime 仓库开发指南：从 AGENTS.md 看架构脉络、编码规范与 Agent 协作机制
2026/9/14 1:14:42
1. 引言
在 Java 后端技术栈中，数据库选型往往是决定系统架构上限的关键决策之一。面对关系型与非关系型数据库的十字路口，MongoDB 与 TiDB 作为两类极具代表性的分布式数据库，经常让开发者陷入「选择困难症」。
MongoDB 以灵活的文档模型和强大的水平扩展能力著称，是 NoSQL 领域的标杆；TiDB 则凭借兼容 MySQL 协议与分布式事务能力，成为 NewSQL 阵营的明星产品。本文将从适用场景、架构特性、性能表现与选型建议四个维度，结合 Java 生态的实战视角，帮助你在两者之间做出理性决策。
2. 核心概念与架构对比
2.1 MongoDB：面向文档的 NoSQL 数据库
MongoDB 采用 BSON（二进制 JSON）格式存储数据，每个记录是一个文档（Document），集合（Collection）中的文档结构可以灵活变化，无需预先定义表结构。
- 数据模型：文档模型，支持嵌套对象与数组，天然契合 JSON 风格的数据交互。
- 扩展方式：分片集群（Sharding）实现数据水平拆分，副本集（Replica Set）保证高可用。
- 事务能力：自 4.0 版本起支持多文档事务，但主要面向副本集内的强一致场景。
- 查询语言：丰富的查询表达式，支持聚合管道（Aggregation Pipeline）完成复杂数据处理。
2.2 TiDB：兼容 MySQL 的分布式 NewSQL 数据库
TiDB 是一款开源分布式关系型数据库，采用计算与存储分离的架构，对外完全兼容 MySQL 协议，让 Java 应用可以像使用单机 MySQL 一样使用分布式数据库。
- 数据模型：关系型表结构，支持 SQL 标准语法，迁移成本极低。
- 扩展方式：TiDB Server（计算层）与 TiKV（存储层）均可独立水平扩展。
- 事务能力：基于 Percolator 模型的分布式事务，支持跨节点强一致 ACID。
- HTAP 特性：通过 TiFlash 列存引擎，实现同一份数据的实时分析处理。
2.3 架构对比一览
| 维度 | MongoDB | TiDB |
|---|---|---|
| 数据模型 | 文档型（BSON） | 关系型（SQL） |
| 协议兼容 | 自定义 Wire Protocol | MySQL 协议 |
| 事务支持 | 副本集内多文档事务 | 分布式强一致事务 |
| 扩展方式 | 分片 + 副本集 | 计算/存储分层扩展 |
| 一致性 | 可调（强/最终） | 强一致（Raft） |
| 适用查询 | 灵活文档查询、聚合 | 复杂 JOIN、标准 SQL |
3. 适用场景分析
3.1 MongoDB 的典型适用场景
场景一：内容管理与 CMS 系统
文章、评论、用户画像等数据结构多变，MongoDB 的文档模型允许字段动态增减，无需频繁执行 ALTER TABLE 迁移。
// Spring Data MongoDB 示例：动态字段存储publicclassArticle{@IdprivateStringid;privateStringtitle;privateMap<String,Object>metadata;// 灵活扩展字段}场景二：物联网与日志数据
设备上报数据往往具有高并发写入、时间序列特征明显的特点。MongoDB 的写入性能优异，配合 TTL 索引可自动清理过期数据。
场景三：实时个性化推荐
用户行为日志、商品标签等半结构化数据，借助 MongoDB 的聚合管道可快速完成实时特征计算。
3.2 TiDB 的典型适用场景
场景一：金融级核心交易系统
订单、账户、支付流水等数据对强一致性和事务隔离有极高要求，TiDB 的分布式事务能力可确保跨节点数据一致性。
-- TiDB 完全兼容 MySQL 语法STARTTRANSACTION;UPDATEaccountSETbalance=balance-100WHEREuser_id=1;UPDATEaccountSETbalance=balance+100WHEREuser_id=2;COMMIT;场景二：海量数据在线分析（HTAP）
当业务表数据量达到亿级，且需要同时支撑高并发点查与复杂分析查询时，TiDB 通过 TiFlash 列存引擎实现实时分析，避免维护多套系统。
场景三：MySQL 分库分表后的平滑演进
对于已经使用 ShardingSphere 或 MyCat 分库分表的系统，TiDB 提供了透明化的替代方案，应用层无需感知数据分布。
3.3 场景决策树
4. Java 生态集成实践
4.1 Spring Boot 集成 MongoDB
通过 Spring Data MongoDB，Java 开发者可以像操作 JPA 一样操作文档数据库。
@RepositorypublicinterfaceUserRepositoryextendsMongoRepository<User,String>{List<User>findByAgeGreaterThan(intage);}4.2 Spring Boot 集成 TiDB
TiDB 兼容 MySQL 协议，因此直接使用 MySQL 驱动即可，无需引入额外依赖。
spring:datasource:url:jdbc:mysql://tidb-server:4000/business_db?useSSL=false&serverTimezone=Asia/Shanghaiusername:rootpassword:your_passworddriver-class-name:com.mysql.cj.jdbc.Driver4.3 连接池与性能调优建议
| 配置项 | MongoDB | TiDB |
|---|---|---|
| 连接池 | mongodb-pool 默认 100 | HikariCP 建议 20-50 |
| 批量写入 | bulkWrite 提升吞吐 | 多值 INSERT 减少 RTT |
| 索引策略 | 复合索引 + TTL | 覆盖索引 + 分区 |
5. 选型建议与最佳实践
5.1 选型决策清单
在最终确定技术方案前，建议团队围绕以下问题展开评估：
- 数据模型稳定性：业务字段是否频繁变更？若是，优先 MongoDB。
- 事务边界：是否存在跨表、跨节点的强一致事务需求？若是，优先 TiDB。
- 团队技术栈：团队是否熟悉 SQL 与 MySQL 运维？TiDB 的学习曲线更平缓。
- 查询复杂度：是否需要多表 JOIN 与子查询？TiDB 的 SQL 能力更完整。
- 成本预算：MongoDB 社区版功能受限，TiDB 开源版功能完整。
5.2 混合架构实践
在实际生产环境中，两者并非互斥关系。一个典型的电商系统可以采用混合存储架构：
- 商品信息、用户画像→ MongoDB（灵活结构，快速迭代）
- 订单、支付流水→ TiDB（强事务，金融级可靠）
- 搜索、推荐→ Elasticsearch（全文检索与聚合分析）
5.3 常见误区提醒
- 误区一：认为 MongoDB 不支持事务。实际上 4.0+ 已支持多文档事务，只是性能与分布式场景有限制。
- 误区二：认为 TiDB 是 MySQL 的简单替代品。TiDB 的分布式事务与存储引擎差异，需要针对性调优。
- 误区三：忽视数据一致性需求。最终一致性场景选 MongoDB 更合适，强一致场景务必选 TiDB。
6. 总结
MongoDB 与 TiDB 代表了数据库领域两条截然不同的技术路线：前者以灵活性和开发效率见长，后者以强一致性和 SQL 兼容性立足。对于 Java 开发者而言，选型的核心不在于「哪个更好」，而在于「哪个更适合当前业务场景」。
- 如果你的业务数据结构多变、追求快速迭代，MongoDB 是理想选择。
- 如果你的业务强依赖事务与复杂查询、且数据量持续增长，TiDB 能提供平滑的扩展路径。
- 在大型系统中，两者完全可以共存，各司其职。
最终，建议团队在选型前进行充分的概念验证（POC），用真实业务流量验证性能与稳定性，才能做出最理性的技术决策。