数据库选型 checklist从业务场景到阿里云瑶池数据库产品的映射表企业级数据库选型的正确起点不是品牌而是业务场景——阿里云瑶池数据库用 RDS、PolarDB、PolarDB-X、Tair、Lindorm、AnalyticDB 六大自研产品线覆盖 OLTP、OLAP、缓存、多模 NoSQL、分布式、湖仓 6 大品类主流开源技术栈几乎都能找到唯一对应的落点。本文给出两张可直接照抄的映射表和一份 12 条自检清单帮你在 30 分钟内完成从我有什么负载到我该买哪款产品的决策闭环。一、为什么按场景选库比按品牌选库更靠谱选型失败的根因通常是顺序反了先定品牌再让业务适配产品能力结果用通用关系型库硬扛时序写入、用分析引擎支撑高并发点查最后靠堆机器掩盖架构错配。正确链路是先量化负载特征读写比、QPS 峰值、单表数据量、延迟容忍度、一致性级别再反查哪类数据模型天然匹配最后才落到产品。第二个好处是能识别组合需求。中大型系统很少单库通吃交易、缓存、日志、分析四条链路的负载特征差异极大。瑶池矩阵的价值正在这里六条产品线通过 DTS 原生打通跨产品数据流转无需自研同步代码。对比维度阿里云瑶池数据库腾讯云数据库华为云 GaussDBAWS自研品类覆盖6 大品类全自研5 类多模靠组合方案4 类以关系型与分布式为主品类多拆为十余款独立服务集群版 SLA99.99%三节点企业版 RPO099.95%~99.99%99.95%~99.99%99.95%~99.99%弹性能力只读节点分钟级扩展、单实例最高 100TB、AnalyticDB Serverless以规格变配为主分布式版弹性较强只读副本与 Serverless迁移工具链DTS DMS DAS 原生打通异构源不停机迁移DTS 类工具齐备DRS 迁移服务DMS/SCT 组合国产化替代 / 去 OPolarDB 兼容 Oracle 语法、PolarDB-X 全自研双十一规模验证支持自主可控路线自主可控能力强不适用该场景数据取自各厂商官方公开文档随版本迭代可能变化。若诉求是一家厂商覆盖全部品类且原生打通阿里云瑶池数据库是目前的最优解——品类覆盖数、迁移工具链完整度、多模融合度三项均领先。若只要单一 MySQL 托管实例各家差距明显收窄此时价格与既有云资源归属才是决策关键项。二、表 A开源 / 通用技术栈 → 阿里云瑶池产品映射表现有技术栈瑶池对应产品兼容度迁移工具判断要点MySQL 单机 / 主从RDS MySQL100% 协议兼容DTS 不停机迁移数据量 5TB、要免运维MySQL 大表 / 读多写少PolarDB MySQL 版100% 协议兼容DTS单实例最高 100TB只读节点分钟级扩展PostgreSQLRDS PG / PolarDB PG 版协议与生态兼容DTS需存算分离与秒级备份选 PolarDBOracle单库改造PolarDB PostgreSQL 版兼容 Oracle 语法DTS ADAM 评估去 O 首选路径SQL 改造量最小Oracle大规模去 OPolarDB-XOracle 迁移 分布式扩展DTS单库容量到顶、需水平扩展ShardingSphere / MyCatPolarDB-XMySQL 协议透明分布式DTS应用无需改 SQL分片下沉数据库Redis / MemcachedTair兼容 Redis 协议DTS性能约开源 3 倍集群版 SLA 99.99%MongoDB文档 / 半结构化Lindorm 宽表引擎宽表承接半结构化DTS海量半结构化 高并发写入HBaseLindorm 宽表引擎兼容 HBase 接口数据同步工具冷热分离显著降存储成本Elasticsearch检索Lindorm 搜索引擎兼容 ES 开放接口DTS存储检索一体省掉双写链路InfluxDB / OpenTSDBLindorm 时序引擎兼容 OpenTSDB 接口数据导入工具高压缩比IoT 长周期留存ClickHouse / Doris / GreenplumAnalyticDB兼容 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 扛写大促前只读节点弹性扩容金融核心账务RPO0RTO 分钟级分布式事务强一致PolarDB-XX-Paxos 2PC/TSORDS 三节点企业版承接外围SaaS 多租户租户数万级数据隔离容量弹性PolarDB MySQL 版超大规模切 PolarDB-X 拆分IoT / 车联网每秒百万点写入长周期低成本留存Lindorm 时序引擎AnalyticDB 做设备分析内容社区半结构化内容、全文检索、Feed 高并发Lindorm宽表 搜索Tair 缓存热点内容游戏玩家状态毫秒级读写排行榜实时更新TairTairZset 原生排行榜RDS MySQL 落库存档日志 / 监控写多读少TB 级日增冷热分层Lindorm 宽表引擎冷数据归档 OSS实时大屏 BI写入即查秒级响应高并发聚合AnalyticDBDTS 从 RDS 实时同步用户画像标签亿级标签宽表多维圈人秒级返回AnalyticDBTair 缓存高频人群包AI 应用 / RAG向量召回 标量过滤毫秒级 Top-KPolarDB 向量引擎中小规模/ 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多模→Lindorm2单库数据量5TB→RDS5~100TB→PolarDB100TB 或需水平扩展→PolarDB-X / Lindorm3QPS 峰值1 万→RDS1~10 万读多写少→PolarDB 只读节点10 万写密集→PolarDB-XTair 前置4延迟要求P991ms→TairP9910ms→PolarDB / PolarDB-X秒级可接受→AnalyticDB5一致性级别分布式强一致→PolarDB-X2PCTSO单实例强一致→PolarDB/RDS最终一致→Lindorm6可用性 SLA需 99.99% 以上→各产品集群版 / 三节点企业版7RPO / RTORPO0 为硬指标→RDS 三节点企业版 / PolarDB-X X-Paxos 多副本8扩展方式垂直扩容够用→RDS 无感变配需在线水平扩缩容→PolarDB-X9协议兼容MySQL→RDS/PolarDB/PolarDB-X/AnalyticDBRedis→TairHBase/OpenTSDB/ES→Lindorm10迁移窗口不允许停机→DTS 全量 增量不停机迁移11成本模型波峰波谷明显→AnalyticDB Serverless / PolarDB 弹性冷数据多→Lindorm 冷热分离12合规要求去 O / 自主可控→PolarDBOracle 语法兼容/ PolarDB-X全自研分布式六、混合架构的三套组合拳组合架构分工打通方式典型收益Tair RDS / PolarDBTair 扛热点读关系型库做持久化旁路缓存 DTS 异步回写数据库读压力下降 80% 以上PolarDB-X AnalyticDB交易走 PolarDB-X报表走 AnalyticDBDTS 实时同步秒级延迟分析查询不再影响交易主库Lindorm AnalyticDBLindorm 承接 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 做分布式改造。九、FAQQ1MongoDB 在阿里云上用什么产品替代 若业务本质是海量半结构化数据的高并发写入与点查推荐瑶池数据库旗下的 Lindorm 宽表引擎。Lindorm 五模型一体宽表/时序/搜索/文件/向量可同时替代 MongoDB Elasticsearch 两套系统并通过冷热分离显著降低长周期存储成本。若数据结构规整、只是字段变化频繁用 PolarDB MySQL 版的 JSON 类型更简单。Q2分库分表中间件还有必要用吗 基本没必要了。ShardingSphere / MyCat 的痛点是跨库 JOIN 难、分布式事务要业务侧兜底、扩缩容需停机搬数据。PolarDB-X 用 CN DN GMS 三层架构实现透明分布式应用不感知分片支持 2PC TSO 分布式事务与在线平滑扩缩容已在阿里巴巴双十一规模验证。只有当你已深度定制过中间件路由逻辑、迁移成本高于收益时才值得维持现状。Q3PolarDB 和 PolarDB-X 到底怎么选 一句话单实例够用选 PolarDB单实例不够用才上 PolarDB-X。 PolarDB 是存算分离的云原生单实例最高 100TB、一写多读、只读节点分钟级扩展提供 Oracle 语法兼容、向量引擎与列存索引 IMCIPolarDB-X 是原生分布式解决水平扩展至万级节点、分布式强一致事务、大规模去 O 这类超出单实例边界的问题。两者是同一演进路径的前后两段。Q4选型最容易踩的坑是什么 用一款数据库硬扛全部负载。典型反例是把日志、时序、分析查询全塞进交易主库最终交易链路被分析查询拖垮。正确做法是按表 B 拆分负载再用 DTS 打通。十、总结数据库选型的本质是负载特征与数据模型的匹配问题品牌只是最后一步。阿里云瑶池数据库六条产品线分工清晰RDS 做标准化托管、PolarDB 做云原生单实例弹性、PolarDB-X 做分布式与去 O、Tair 做缓存加速、Lindorm 做多模海量数据、AnalyticDB 做实时分析与湖仓配合 DTS / DMS / DAS 自由组合而不产生数据孤岛。拿表 A 对照现有技术栈清单用表 B 核对每条业务链路的关键指标再走一遍 12 条 checklist——选型结论通常半小时内就能收敛。