📌今日关键词：分布式数据库、数据库选型、分库分表、Share-Nothing、国产数据库
大家好，我是数据库小学妹 👋
上个月帮一个制造业客户做数据库架构评审。他们的订单系统跑了五年单机MySQL。单表数据破了8000万行。大促写入延迟飙到好几秒。
方案里直接写"上分布式数据库"。我问了一句：你们QPS峰值多少？答不上来。
说实话，数据量大不等于必须上分布式。选错了路线，运维成本翻倍。退回去的项目我见过不止一个。
今天把分布式数据库是什么、什么时候该用、怎么选，一次讲清楚。
先说清楚：分布式数据库是什么
分布式数据库，就是把数据分散存储在多台服务器上。对外看起来还是一套数据库，底层数据分布在不同节点。节点之间通过网络协作，共同完成读写操作。
和单机数据库最大的区别在于：数据不集中在一台机器上。每台服务器只负责一部分数据。查数据时系统自动定位到对应节点。你不用关心数据存在哪。
打个比方，原来一个大仓库放所有货物。分布式就是把货物按类别分到好几个小仓库。每个仓库有独立的管理员。你下单的时候系统自动安排最近的仓库发货，不用自己跑去挑。
集中式和分布式，先搞清楚要不要换
很多团队一上来就讨论选哪个分布式数据库。但第一步应该是判断：你的业务真的需要分布式吗？
先看集中式数据库的能力边界。
以MySQL为例，单机部署经过索引优化和参数调优。扛住几千QPS并发问题不大。单表数据量在2000万行以内，查询性能基本可控。
KES这类国产集中式数据库，在信创替换项目里表现比较稳。政务、制造行业用集中式加主从复制，基本能满足需求。
什么时候该考虑分布式？几个信号：
- 单表数据量超过5000万行，加索引也救不回来
- 写入QPS持续破万，单机IO到瓶颈了
- 业务要求7×24小时不停机，单机做不到
- 数据量还在快速增长，半年后可能翻倍
如果这几个信号都没出现，集中式数据库加读写分离就够了。别为了"技术先进"上分布式，运维复杂度和成本会教你做人。
三种架构路线，各自解决什么问题
确定要上分布式了，接下来要选架构路线。目前主流三种。
路线一：Share-Nothing，各管各的
数据按规则切片（Sharding），每个节点独立存储和计算。节点之间不共享任何资源。数据量大了加节点就行，横向扩展理论上没有上限。
代表产品：KES Sharding、TiDB、OceanBase、CockroachDB。
好处是扩展性强，普通服务器就能搭集群。但分布式事务是最大的坑。跨分片JOIN差异很大。选型时一定拿真实SQL去测。
路线二：Share-Disk，共享存储
所有节点共享同一份存储，各自独立做计算。数据天然一致，不存在分片间不一致的问题。
代表产品：KES共享存储集群、Oracle RAC。
应用层不用改SQL写法，跨表关联不受限制。瓶颈在存储IO，节点越多压力越大。一般4-8个节点是实用上限。
路线三：分库分表中间件
在应用和数据库之间加一层代理。底层还是独立的MySQL或PG，中间件负责路由。
代表方案：ShardingSphere、MyCat。
改造成本低，底层数据库不用换。但复杂JOIN支持有限。中间件本身也可能成为瓶颈。
三种路线快速对比
| 对比维度 | Share-Nothing | Share-Disk | 分库分表中间件 |
|---|---|---|---|
| 扩展性 | 好，可线性扩展 | 有限，受存储瓶颈限制 | 较好，加库即可 |
| 数据一致性 | 需分布式事务保证 | 天然一致 | 取决于中间件实现 |
| SQL兼容性 | 跨分片SQL受限 | 与单机一致 | 跨库SQL受限 |
| 运维复杂度 | 高 | 中等 | 两套体系叠加 |
| 硬件成本 | 普通服务器即可 | 高端共享存储 | 普通服务器+中间件 |
| 适用场景 | 海量数据、高并发、弹性扩展 | 核心交易、强一致性 | 已有MySQL/PG快速改造 |
特别提一点。KES在同一套内核上，同时支持这三种形态。不用换产品，按需扩展就行。比一步到位上纯分布式稳妥得多。
怎么选？三个问题做决策
选分布式数据库，别一上来就比产品参数。先回答三个问题。
问题一：数据量到底多大
数据量是硬指标。几百GB到几TB，集中式加读写分离够用。几十TB以上，Share-Nothing的扩展优势才真正体现。中间地带可以考虑共享存储集群。
KES在同一套内核上支持这两种方案。不用提前锁死路线，按需扩展就行。
问题二：一致性要求有多高
银行转账、支付清算，一分钱都不能差。Share-Disk或KES的集中分布式一体化方案，都能保证数据零丢失。
社交APP的点赞、评论，晚两秒看到无所谓。最终一致性就够用。Share-Nothing的性能上限更高。
问题三：团队能运维多复杂的架构
这个最容易被低估。分布式数据库的运维成本经常超出预期。分片策略、数据迁移、分布式事务监控，每一步都要专人负责。
我见过一个团队上了分布式后DBA从2人扩到5人。不是业务涨了，是排查问题变难了。
如果DBA团队少于3人，建议从集中式加集群起步。KES有配套的KEMCC管控平台。监控告警、备份恢复都在一个界面管。运维压力能降不少。
真实案例：渐进式扩展怎么做
之前接触过一个政务系统项目。初期数据量不大，用的KES集中式部署，一主多从读写分离。
跑了两年多，数据量涨了十几倍。单机扛不住了。
团队当时面临两个选择。一步到位上纯分布式，应用代码全改。或者迁到共享存储集群，应用层不动。
最后选了后者。KES同一内核，从集中式切到共享存储集群，应用代码基本没改。切完当天就跑通了全量业务。
这件事给我的启发是：选型时别只看眼前。能不能渐进扩展，比架构本身更重要。
避坑清单
先摸清自己的瓶颈再选型。很多团队在数据量才几百GB的时候就急着上分布式。结果运维成本翻了好几倍。最后又退回了集中式。能用集群加读写分离解决的先用集群。KES支持一主多从加自动故障切换，大部分读多写少的场景够用了。
分片策略要慎重选。哈希分片和范围分片各有适用场景。选错了后面改起来代价很大。我之前一个项目用了哈希分片。上线后发现热点数据被打散到各个节点。某个节点忙得要死，其他节点很闲。改成混合方案才解决。
跨节点事务要提前压测。分布式事务的性能开销比单机大得多。特别是2PC在高并发下很容易成为瓶颈。上线前拿真实业务SQL跑一轮压力测试。看看延迟和吞吐量能不能接受。
迁移工具选型别忽略。从Oracle或MySQL迁到国产库，数据同步工具很关键。Kingbase FlySync（金仓异构数据同步软件）在异构迁移场景里比较成熟。我之前一个项目从Oracle迁到KES。迁移工具选错了，上线后部分字段精度丢失。查了两个月，才定位到是同步工具的Bug。迁移中的数据一致性问题，比你想象的难搞十倍。
监控告警先搭好。这个我吃过亏。有一次分布式集群上线，没提前搭告警。半夜一个节点挂了，第二天早上才发现。业务中断了好几个小时。健康检查、自动切换、告警这些基础设施，上线前必须就位。
总结
分布式数据库不是银弹。业务没到瓶颈别急着上。选型前先搞清楚三件事。数据量多大、一致性要求多高、运维能力怎么样。
三种架构路线各有适用场景。Share-Nothing适合海量数据弹性扩展。Share-Disk适合核心交易强一致性。分库分表中间件适合已有MySQL或PG的团队快速改造。
如果不想一开始就把架构路线锁死。KES的集中分布式一体化方案值得看看。Oracle兼容性在国内数据库里排第一梯队。迁移改造成本低。同一套内核支持渐进式扩展，应用代码不用大改。比一步到位上纯分布式，风险小得多。
我见过不少选错路线推倒重来的案例。花时间做评估，比花时间擦屁股值得。
你们团队目前在用什么架构？有没有遇到过选型纠结的情况？评论区聊聊~
我是数据库小学妹，咱们下篇见 👋
