分布式数据库选型这事,别光看 PPT

上一篇结尾的问题，业务要做分布式改造，第一个要回答的问题是什么。

我的答案是，你的数据模型里有没有一个天然的分片键。

这个问题一出，一半的方案直接出局。有清晰分片键、join 能按亲和设计的多租户或按业务线隔离的系统，Citus 这类分库分表路线走得通。没有分片键、查询全是跨全库的随机组合，那你要的是原生分布式或者 MPP，硬上分库分表等于给自己上刑。我自己参与过的选型评审，凡是跳过这个问题直接聊产品功能的，最后都交了学费。

这篇把整个 PG 系分布式地图铺开，给你们一套我实际在用的选型方法。

先把选手按血统归队

第 17 篇讲过 Shared Nothing 内部还分两类，现在把具体产品填进去。

插件或中间件路线的分库分表，Citus 是代表，应用要感知分片键，内部是协调节点加单机 PG。优点是跟 PG 社区同步快、上手成本低，缺点是 SQL 能力有边界。

原生分布式路线，对应用透明。这条线上又分两个亚种。MPP 分析型，Greenplum 是标杆，为并行扫全量数据而生。NewSQL 交易型，CockroachDB、TiDB 是代表，目标是线性扩展加分布式事务加高可用全都要。

CockroachDB 值得单独看一眼，它是 Spanner 思想的开源实现，数据按 64MB 的 Range 切分，三副本，副本间靠 Raft 同步，SQL 层完全按 PostgreSQL 的语法解析，协议层兼容 PG，客户端拿 PG 驱动直连。TiDB 跟它思路相似，计算存储分离，PD 管元数据，TiKV 管存储，差别在事务模型的具体实现和存储引擎的行列选择上。这俩的好处是扩容和故障恢复近乎自动，64MB 的小分片搬起来轻。

国产阵营这几年很热闹，也得认识一下。openGauss 从 PG 9.2 内核演进，华为做了大量改造，最大可用模式、双写、并行回放这些特性都是实打实增强，单机和主备场景竞争力强。GaussDB 200 是 XC 血脉的 MPP，加了集群管理组件做故障自愈。GaussDB 300 往 HTAP 走，GTM 的事务号存进了 etcd 集群。TBase 也是 XC 系。TDSQL 贴着 MySQL 社区做分库分表加强同步。POLARDB 走 Shared Storage，一写多读、存算分离、共享分布式文件系统。看出脉络了吗，全是前几篇讲过的架构路线的工程化延续。

我的选型五问

方案再多，评审的时候我就问五个问题。

一问负载类型，OLTP 点查点写为主，还是 OLAP 扫全量算聚合，还是混合。OLAP 重就直接看 MPP，Greenplum 或者 GaussDB 200 这一类，别犹豫。OLTP 重看 Citus 或 NewSQL。混合负载先想清楚谁主谁次，HTAP 这个词很美，但混合负载里一定有侧重。

二问分片键，刚才说了，这决定走不走得了分库分表路线。

三问 SQL 兼容性底线。把业务里最复杂的十句 SQL 拉出来，对着候选方案的限制清单逐条过。Citus 的 join 限制、非分片列 count distinct 限制，Greenplum 的高并发点查短板，逐条验证。PPT 上不会写限制，官方文档的限制章节才是选型的主战场。

四问维护成本。组件越多越贵，XL 那种 GTM 加 Proxy 加 Coordinator 加 Datanode 的阵容，搭起来是工程，养起来是负担。Citus 两个角色，CockroachDB 一种角色。团队多少人、什么水平，直接决定能养得起多复杂的方案。这一条的分量经常被低估，分布式系统凌晨三点出问题，排查链路每多一环都是血泪。

五问社区和未来。XL 的教训还热乎着，选型一定要看社区活跃度、版本跟进速度、商业公司的健康状况。你选的不是今天的功能，是未来五年谁给你修 bug。

选型定完别急着上线，POC 该做还得做

五问问完、速写对完号，也只是纸面结论。我经手的项目，定方案之后还有一轮 POC 验证，拿真实的数据模型、真实的 SQL 负载、真实的数据量灌进去跑。重点验三样，Top 复杂 SQL 的兼容性和性能，扩容缩容的真实流程，故障场景的切换表现。分布式方案的坑大多藏在这三样里，文档里看不出来的， POC 一周全暴露。

还有个小建议，POC 期间就把监控告警体系搭起来，分布式集群的监控项比单机多一个数量级，这个阶段搭好的监控就是日后生产的底子。

POC 这个话题，我面架构向的候选人必问。问题很简单，你们选型的时候 POC 验了什么。答跑了下 benchmark 的，我会追问，用谁的数据、谁的 SQL。拿官方样例数据跑 tpcc 的，跟拿自己业务 Top 十慢 SQL 灌真实数据量跑的，是两个物种。我会再问一句，扩容缩容演练过吗，故障切换看过吗。这三样是分布式坑的藏身处，文档里看不出来，POC 一周全暴露。答得头头是道的，多半是真交过学费的。

五问之外还有两个非技术因素，分量不比技术轻。一是团队的人才储备，选了一个招不到人、没人会维护的方案，等于给自己埋雷，PG 系方案的一个隐性优势就是 PG 人才池相对深。二是商业支持和合同层面的东西，出问题有没有地方打电话， license 怎么算，合规要求满不满足，这些在评审会上往往比技术参数更早一票否决。

一张决策速写

把五问的答案落到具体场景，速写长这样。数据仓库、BI 分析、大宽表聚合，Greenplum。多租户 SaaS、分片键清晰、想留在 PG 生态，Citus。全球化部署、强一致交易、能接受脱离 PG 内核，CockroachDB 或 TiDB。国产化合规要求明确的，openGauss 系和 GaussDB 系按场景对号。老系统扩容又懒得改架构，POLARDB 这类存算分离的云原生路线可以看看。

还有一条最重要的，别为了分布式而分布式。动手之前先算一笔容量账，单机 PG 的天花板比多数人以为的高，配上第二季讲的优化手段、第三季讲的读写分离，数据量几个 TB、日增几百万行的业务单机跑得稳稳的。单机 PG 加分区加读写分离能扛住的，别上分布式。这个系列前面二十一篇讲的所有单机功夫，都用完了、顶到头了，分布式才是下一步。复杂度是最贵的成本，能不买就不买。

面试官爱问什么

• 分布式选型第一个问题是什么。数据模型里有没有天然的分片键，有就走分库分表路线，没有就看原生分布式或 MPP。跳过这步直接聊产品功能的评审，最后都交了学费。
• OLTP 和 OLAP 怎么分方案。分析重看 MPP，Greenplum、GaussDB 200 这类。交易重看 Citus 或 NewSQL。混合负载先想清楚谁主谁次，HTAP 这个词很美但一定有侧重。
• POC 该验什么。Top 复杂 SQL 的兼容和性能、扩容缩容的真实流程、故障场景的切换表现，用真实数据真实负载跑，拿样例数据跑 benchmark 是骗自己。
• 国产分布式怎么评。先认血统，openGauss 是 PG 9.2 内核演进，GaussDB 200、300 和 TBase 是 XC 血脉，POLARDB 走存算分离，TDSQL 贴着 MySQL。血统看清了，特性就好评了。
• 技术之外还看什么。团队人才储备、商业支持、license、合规，这些经常比技术参数更早一票否决。

第四季到这里收尾。这个系列从安全、优化、高可用一路写到分布式，技术内容讲完了。最后一篇番外，聊点不一样的，我自己考 PGCM 认证的经历，上机考试八小时都考了什么真题，以及面试里最常被问到的那些 PG 问题。正在考虑考证的读者，下一篇是写给你的。

干货已送达，点赞是签收，转发是好评，留言是售后！

关于我：郭一军 | 云贝教育创始人 | 25 年数据库老兵，长期为银行、证券等金融机构授课，专注信创数据库人才培养。