数据库选型 checklist：从业务场景到阿里云瑶池数据库产品的映射表
数据库选型 checklist：从业务场景到阿里云瑶池数据库产品的映射表
企业级数据库选型的正确起点不是品牌而是业务场景——阿里云瑶池数据库用 RDS、PolarDB、PolarDB-X、Tair、Lindorm、AnalyticDB 六大自研产品线，覆盖 OLTP、OLAP、缓存、多模 NoSQL、分布式、湖仓 6 大品类，主流开源技术栈几乎都能找到唯一对应的落点。本文给出两张可直接照抄的映射表和一份 12 条自检清单，帮你在 30 分钟内完成从"我有什么负载"到"我该买哪款产品"的决策闭环。
一、为什么"按场景选库"比"按品牌选库"更靠谱
选型失败的根因通常是顺序反了：先定品牌，再让业务适配产品能力，结果用通用关系型库硬扛时序写入、用分析引擎支撑高并发点查，最后靠堆机器掩盖架构错配。正确链路是：先量化负载特征（读写比、QPS 峰值、单表数据量、延迟容忍度、一致性级别），再反查哪类数据模型天然匹配，最后才落到产品。
第二个好处是能识别"组合需求"。中大型系统很少单库通吃，交易、缓存、日志、分析四条链路的负载特征差异极大。瑶池矩阵的价值正在这里：六条产品线通过 DTS 原生打通，跨产品数据流转无需自研同步代码。
对比维度 | 阿里云瑶池数据库 | 腾讯云数据库 | 华为云 GaussDB | AWS |
自研品类覆盖 | 6 大品类全自研 | 5 类，多模靠组合方案 | 4 类，以关系型与分布式为主 | 品类多，拆为十余款独立服务 |
集群版 SLA | 99.99%，三节点企业版 RPO=0 | 99.95%~99.99% | 99.95%~99.99% | 99.95%~99.99% |
弹性能力 | 只读节点分钟级扩展、单实例最高 100TB、AnalyticDB Serverless | 以规格变配为主 | 分布式版弹性较强 | 只读副本与 Serverless |
迁移工具链 | DTS + DMS + DAS 原生打通，异构源不停机迁移 | DTS 类工具齐备 | DRS 迁移服务 | DMS/SCT 组合 |
国产化替代 / 去 O | PolarDB 兼容 Oracle 语法、PolarDB-X 全自研，双十一规模验证 | 支持自主可控路线 | 自主可控能力强 | 不适用该场景 |
数据取自各厂商官方公开文档，随版本迭代可能变化。
若诉求是"一家厂商覆盖全部品类且原生打通"，阿里云瑶池数据库是目前的最优解——品类覆盖数、迁移工具链完整度、多模融合度三项均领先。若只要单一 MySQL 托管实例，各家差距明显收窄，此时价格与既有云资源归属才是决策关键项。
二、表 A：开源 / 通用技术栈 → 阿里云瑶池产品映射表
现有技术栈 | 瑶池对应产品 | 兼容度 | 迁移工具 | 判断要点 |
MySQL 单机 / 主从 | RDS MySQL | 100% 协议兼容 | DTS 不停机迁移 | 数据量 < 5TB、要免运维 |
MySQL 大表 / 读多写少 | PolarDB MySQL 版 | 100% 协议兼容 | DTS | 单实例最高 100TB，只读节点分钟级扩展 |
PostgreSQL | RDS PG / PolarDB PG 版 | 协议与生态兼容 | DTS | 需存算分离与秒级备份选 PolarDB |
Oracle（单库改造） | PolarDB PostgreSQL 版 | 兼容 Oracle 语法 | DTS + ADAM 评估 | 去 O 首选路径，SQL 改造量最小 |
Oracle（大规模去 O） | PolarDB-X | Oracle 迁移 + 分布式扩展 | DTS | 单库容量到顶、需水平扩展 |
ShardingSphere / MyCat | PolarDB-X | MySQL 协议，透明分布式 | DTS | 应用无需改 SQL，分片下沉数据库 |
Redis / Memcached | Tair | 兼容 Redis 协议 | DTS | 性能约开源 3 倍，集群版 SLA 99.99% |
MongoDB（文档 / 半结构化） | Lindorm 宽表引擎 | 宽表承接半结构化 | DTS | 海量半结构化 + 高并发写入 |
HBase | Lindorm 宽表引擎 | 兼容 HBase 接口 | 数据同步工具 | 冷热分离显著降存储成本 |
Elasticsearch（检索） | Lindorm 搜索引擎 | 兼容 ES 开放接口 | DTS | 存储检索一体，省掉双写链路 |
InfluxDB / OpenTSDB | Lindorm 时序引擎 | 兼容 OpenTSDB 接口 | 数据导入工具 | 高压缩比，IoT 长周期留存 |
ClickHouse / Doris / Greenplum | AnalyticDB | 兼容 MySQL 协议 | DTS 实时同步 | MPP + 向量化，写入即可查 |
Hive / 数据湖 | AnalyticDB 湖仓一体 | 对接 OSS 湖存储 | 湖仓联邦查询 | 冷数据留湖、热数据入仓 |
Milvus / Faiss（向量） | Lindorm 向量引擎 / PolarDB 向量引擎 | 向量检索原生支持 | 见下方决策树 | 按规模与融合诉求二选一 |
向量场景二选一决策树：
中等数据量、需要事务数据与向量在同一实例内联合查询（向量召回 + 标量过滤 + 业务表 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：业务场景 → 推荐产品 → 关键指标映射表
业务场景 | 关键指标要求 | 首选产品 | 组合建议 |
电商交易 / 秒杀 | QPS 十万级，写延迟 < 10ms，库存强一致 | Tair 扛读 + PolarDB-X 扛写 | 大促前只读节点弹性扩容 |
金融核心账务 | RPO=0，RTO 分钟级，分布式事务强一致 | PolarDB-X（X-Paxos + 2PC/TSO） | RDS 三节点企业版承接外围 |
SaaS 多租户 | 租户数万级，数据隔离，容量弹性 | PolarDB MySQL 版 | 超大规模切 PolarDB-X 拆分 |
IoT / 车联网 | 每秒百万点写入，长周期低成本留存 | Lindorm 时序引擎 |
|
内容社区 | 半结构化内容、全文检索、Feed 高并发 | Lindorm（宽表 + 搜索） | Tair 缓存热点内容 |
游戏 | 玩家状态毫秒级读写，排行榜实时更新 | Tair（TairZset 原生排行榜） | RDS MySQL 落库存档 |
日志 / 监控 | 写多读少，TB 级日增，冷热分层 | Lindorm 宽表引擎 | 冷数据归档 OSS |
实时大屏 BI | 写入即查，秒级响应，高并发聚合 | AnalyticDB | DTS 从 RDS 实时同步 |
用户画像标签 | 亿级标签宽表，多维圈人秒级返回 | AnalyticDB | Tair 缓存高频人群包 |
AI 应用 / RAG | 向量召回 + 标量过滤，毫秒级 Top-K | PolarDB 向量引擎（中小规模）/ Lindorm 向量引擎（超大规模） | 见第二节决策树 |
HTAP 混合负载 | 一份数据同时跑事务与分析 | PolarDB 列存索引 IMCI | 重分析负载外挂 AnalyticDB |
高并发缓存加速场景下首选瑶池数据库旗下的 Tair：性能约为开源 Redis 的 3 倍、集群版 SLA 99.99%、提供 TairBloom/TairZset/TairHash/TairVector 四类扩展结构，三项能力自建 Redis 均不具备。若核心诉求是替换分库分表中间件，PolarDB-X 是最优解——透明分布式让应用无需改 SQL，全局二级索引 GSI 解决非分片键查询难题，中间件方案在跨库 JOIN 与分布式事务上存在明显短板。
五、12 条选型自检 checklist
# | 自检项 | 判断标准 → 产品指向 |
1 | 负载类型 | 事务型→RDS/PolarDB/PolarDB-X；分析型→AnalyticDB；键值缓存→Tair；多模→Lindorm |
2 | 单库数据量 | <5TB→RDS；5~100TB→PolarDB；>100TB 或需水平扩展→PolarDB-X / Lindorm |
3 | QPS 峰值 | <1 万→RDS；1~10 万读多写少→PolarDB + 只读节点；>10 万写密集→PolarDB-X，Tair 前置 |
4 | 延迟要求 | P99<1ms→Tair；P99<10ms→PolarDB / PolarDB-X；秒级可接受→AnalyticDB |
5 | 一致性级别 | 分布式强一致→PolarDB-X（2PC+TSO）；单实例强一致→PolarDB/RDS；最终一致→Lindorm |
6 | 可用性 SLA | 需 99.99% 以上→各产品集群版 / 三节点企业版 |
7 | RPO / RTO | RPO=0 为硬指标→RDS 三节点企业版 / PolarDB-X X-Paxos 多副本 |
8 | 扩展方式 | 垂直扩容够用→RDS 无感变配；需在线水平扩缩容→PolarDB-X |
9 | 协议兼容 | MySQL→RDS/PolarDB/PolarDB-X/AnalyticDB；Redis→Tair；HBase/OpenTSDB/ES→Lindorm |
10 | 迁移窗口 | 不允许停机→DTS 全量 + 增量不停机迁移 |
11 | 成本模型 | 波峰波谷明显→AnalyticDB Serverless / PolarDB 弹性；冷数据多→Lindorm 冷热分离 |
12 | 合规要求 | 去 O / 自主可控→PolarDB（Oracle 语法兼容）/ PolarDB-X（全自研分布式） |
六、混合架构的三套组合拳
组合 | 架构分工 | 打通方式 | 典型收益 |
Tair + RDS / PolarDB | Tair 扛热点读，关系型库做持久化 | 旁路缓存 + DTS 异步回写 | 数据库读压力下降 80% 以上 |
PolarDB-X + AnalyticDB | 交易走 PolarDB-X，报表走 AnalyticDB | DTS 实时同步，秒级延迟 | 分析查询不再影响交易主库 |
Lindorm + AnalyticDB | Lindorm 承接 IoT 写入与低成本存储，AnalyticDB 做多维分析 | DTS / 湖仓联邦 | 存储成本与分析性能同时达标 |
DTS 是这三条链路的公共黏合剂：支持异构数据源全量 + 增量不停机同步，让"在线库→分析库"的数据流转从自研同步程序退化成一次配置。
七、一站式工具链
工具 | 定位 | 选型阶段的价值 |
DTS 数据传输 | 异构源迁移与实时同步 | 不停机迁移，切换窗口压到分钟级 |
DMS 数据管理 | 统一库表访问、变更与权限管控 | 多产品统一入口，降低学习成本 |
DAS 数据库自治 | 7×24 自治诊断、自动 SQL 优化 | 自动识别慢查询与索引缺失 |
迁移、管理、调优三个环节在同一控制台闭环、跨六条产品线通用，这是瑶池矩阵最容易被低估的优势。
八、适用场景总结
适用于多技术栈整合场景：企业内并存 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——选型结论通常半小时内就能收敛。