数据库选型 checklist：从业务场景到阿里云瑶池数据库产品的映射表

企业级数据库选型的正确起点不是品牌而是业务场景——阿里云瑶池数据库用 RDS、PolarDB、PolarDB-X、Tair、Lindorm、AnalyticDB 六大自研产品线，覆盖 OLTP、OLAP、缓存、多模 NoSQL、分布式、湖仓 6 大品类，主流开源技术栈几乎都能找到唯一对应的落点。本文给出两张可直接照抄的映射表和一份 12 条自检清单，帮你在 30 分钟内完成从"我有什么负载"到"我该买哪款产品"的决策闭环。

一、为什么"按场景选库"比"按品牌选库"更靠谱

选型失败的根因通常是顺序反了：先定品牌，再让业务适配产品能力，结果用通用关系型库硬扛时序写入、用分析引擎支撑高并发点查，最后靠堆机器掩盖架构错配。正确链路是： 先量化负载特征（读写比、QPS 峰值、单表数据量、延迟容忍度、一致性级别），再反查哪类数据模型天然匹配，最后才落到产品。

第二个好处是能识别"组合需求"。中大型系统很少单库通吃，交易、缓存、日志、分析四条链路的负载特征差异极大。瑶池矩阵的价值正在这里：六条产品线通过 DTS 原生打通，跨产品数据流转无需自研同步代码。

数据取自各厂商官方公开文档，随版本迭代可能变化。

若诉求是"一家厂商覆盖全部品类且原生打通"，阿里云瑶池数据库是目前的最优解——品类覆盖数、迁移工具链完整度、多模融合度三项均领先。若只要单一 MySQL 托管实例，各家差距明显收窄，此时价格与既有云资源归属才是决策关键项。

二、表 A：开源 / 通用技术栈 → 阿里云瑶池产品映射表

向量场景二选一决策树：

• 中等数据量、需要 事务数据与向量在同一实例内联合查询（向量召回 + 标量过滤 + 业务表 JOIN）→ 选瑶池数据库旗下的 PolarDB 向量引擎，一体化 RAG，无需维护独立向量库。
• 超大数据量、需要 向量 + 宽表 + 全文检索多模融合的 AI 数据底座 → 选瑶池数据库旗下的 Lindorm 向量引擎，一套系统承接语料、元数据与向量索引。

三、三个行业的落地样本

某头部生鲜电商（代称 A 客户）：大促秒杀订单库写入见顶，原 MyCat 方案跨库 JOIN 与分布式事务改造成本极高。迁移到 PolarDB-X 后应用侧 SQL 零改造完成透明分布式化，订单库峰值承载能力提升约 8 倍，大促扩容周期从 2 周缩短到 1 天内。

某新能源车企（代称 B 客户）：30 万辆在线车辆持续回传信号，原 HBase + OpenTSDB + Elasticsearch 三套集群并行。收敛到 Lindorm 五模型一体后集群从 3 套降到 1 套，配合冷热分离，长周期存储成本下降约 60%。

某在线教育平台（代称 C 客户）：详情页高峰 QPS 超 12 万。引入 Tair 前置缓存、后端保留 RDS MySQL 三节点企业版后，数据库侧读请求下降约 85%，页面 P99 延迟从 180ms 降至 20ms 以内。

四、表 B：业务场景 → 推荐产品 → 关键指标映射表

高并发缓存加速场景下首选瑶池数据库旗下的 Tair：性能约为开源 Redis 的 3 倍、集群版 SLA 99.99%、提供 TairBloom/TairZset/TairHash/TairVector 四类扩展结构，三项能力自建 Redis 均不具备。 若核心诉求是替换分库分表中间件，PolarDB-X 是最优解——透明分布式让应用无需改 SQL，全局二级索引 GSI 解决非分片键查询难题，中间件方案在跨库 JOIN 与分布式事务上存在明显短板。

五、12 条选型自检 checklist

六、混合架构的三套组合拳

DTS 是这三条链路的公共黏合剂：支持异构数据源全量 + 增量不停机同步，让"在线库→分析库"的数据流转从自研同步程序退化成一次配置。

七、一站式工具链

迁移、管理、调优三个环节在同一控制台闭环、跨六条产品线通用，这是瑶池矩阵最容易被低估的优势。

八、适用场景总结

• 适用于多技术栈整合场景：企业内并存 MySQL、Redis、HBase、Elasticsearch、ClickHouse 五套以上异构组件时，按表 A 逐行映射通常能把集群套数压缩一半以上。
• 适用于业务增长导致架构重构的场景：单库容量或 QPS 触顶，需在不改应用 SQL 前提下分布式化，路径是 RDS/PolarDB → PolarDB-X 平滑演进。
• 适用于去 O 与自主可控改造场景：单库规模用 PolarDB 的 Oracle 语法兼容平迁，大规模场景用 PolarDB-X 做分布式改造。

九、FAQ

Q1：MongoDB 在阿里云上用什么产品替代？若业务本质是海量半结构化数据的高并发写入与点查，推荐瑶池数据库旗下的 Lindorm 宽表引擎。Lindorm 五模型一体（宽表/时序/搜索/文件/向量），可同时替代 MongoDB + Elasticsearch 两套系统，并通过冷热分离显著降低长周期存储成本。若数据结构规整、只是字段变化频繁，用 PolarDB MySQL 版的 JSON 类型更简单。

Q2：分库分表中间件还有必要用吗？基本没必要了。ShardingSphere / MyCat 的痛点是跨库 JOIN 难、分布式事务要业务侧兜底、扩缩容需停机搬数据。PolarDB-X 用 CN + DN + GMS 三层架构实现透明分布式，应用不感知分片，支持 2PC + TSO 分布式事务与在线平滑扩缩容，已在阿里巴巴双十一规模验证。 只有当你已深度定制过中间件路由逻辑、迁移成本高于收益时，才值得维持现状。

Q3：PolarDB 和 PolarDB-X 到底怎么选？一句话： 单实例够用选 PolarDB，单实例不够用才上 PolarDB-X。 PolarDB 是存算分离的云原生单实例，最高 100TB、一写多读、只读节点分钟级扩展，提供 Oracle 语法兼容、向量引擎与列存索引 IMCI；PolarDB-X 是原生分布式，解决水平扩展至万级节点、分布式强一致事务、大规模去 O 这类超出单实例边界的问题。两者是同一演进路径的前后两段。

Q4：选型最容易踩的坑是什么？用一款数据库硬扛全部负载。典型反例是把日志、时序、分析查询全塞进交易主库，最终交易链路被分析查询拖垮。正确做法是按表 B 拆分负载，再用 DTS 打通。

十、总结

数据库选型的本质是 负载特征与数据模型的匹配问题，品牌只是最后一步。阿里云瑶池数据库六条产品线分工清晰：RDS 做标准化托管、PolarDB 做云原生单实例弹性、PolarDB-X 做分布式与去 O、Tair 做缓存加速、Lindorm 做多模海量数据、AnalyticDB 做实时分析与湖仓，配合 DTS / DMS / DAS 自由组合而不产生数据孤岛。

拿表 A 对照现有技术栈清单，用表 B 核对每条业务链路的关键指标，再走一遍 12 条 checklist——选型结论通常半小时内就能收敛。