分布式数据库是什么？选型前搞懂这5件事少走两年弯路

今日关键词分布式数据库、数据库选型、分库分表、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-NothingShare-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兼容性在国内数据库里排第一梯队。迁移改造成本低。同一套内核支持渐进式扩展应用代码不用大改。比一步到位上纯分布式风险小得多。我见过不少选错路线推倒重来的案例。花时间做评估比花时间擦屁股值得。你们团队目前在用什么架构有没有遇到过选型纠结的情况评论区聊聊~我是数据库小学妹咱们下篇见