第8章 典型分布式数据库系统

第8章 典型分布式数据库系统

本章跟着一条线走：前七章攒下的原理与优化，最终要装进一个个真实产品里才见真章。这条线把四类系统——NewSQL、NoSQL、云原生、OLAP——连起来看，讲它们各用什么架构兑现了什么承诺，最后收束到一句选型判断：你的业务匹配哪个键上的"数据模型 + 一致性 + 负载"，答案就藏在哪个阵营里。

本章路线图

一条主线

从第 1 章的"临界线"一路走来，你已经看过数据怎么摊、怎么找、怎么一致、怎么自愈、怎么快——但理论不落地，就只是科幻片。这一章把理论接回地面：NewSQL（TiDB、CockroachDB）用"分片共识 + 分布式事务"同时吃掉扩展性和 ACID；NoSQL（Cassandra、MongoDB 等）用"近乎无限水平的扩展"换来了关系型纪律的松弛；云原生账则是"把数据库变成云平台上的托管服务"（Aurora、Spanner）；OLAP 阵营的 ClickHouse、Druid 则专治"列式大表只扫几列快得飞起"。四个阵营各占一块江山，也各有代价。

沿途站点

• 8.1 NewSQL：要扩展，又要 ACID——TiDB、CockroachDB 靠"分片 + 共识 + 分布式事务"两头都要。主线推进到：关系型能扩展了。
• 8.2 NoSQL：为规模把关系型纪律松掉的各族——Cassandra、MongoDB、Redis 集群、HBase。主线推进到：极致扩展但要在一致性上做让步。
• 8.3 云原生与 OLAP：云上托管与列式分析两类"另有所为"的系统。主线推进到：把分布式与特定工作负载做到极致。

拐点与结论

本章最关键的认知转折是：没有"全都要"的系统，只有"刚好匹配你业务"的系统。NewSQL 想要两头占，就要为共识与事务付出复杂度；NoSQL 要无限扩展，就要接受一致性降档；云原生要免运维，就要接受弹性的不确定与成本；OLAP 要分析快，就要牺牲写路径与点查。真正的选型不是比谁功能多，而是把你业务的"数据模型 + 一致性要求 + 负载类型"三个坐标卡上去，看哪个阵营恰好贴脸。

读完你应该

1. 描述 NewSQL 如何用分片与共识同时拿到扩展性与 ACID。
2. 说明 NoSQL 各族（文档/键值/列族）各自放了什么而换来什么。
3. 区分云原生托管库与自建库的取舍，以及 OLAP 的列式优势从哪来。
4. 用"数据模型 + 一致性 + 负载"三坐标完成一次真实的选型演练。

一句防"追新病"的总开关

整章读下来最该带走的，不是某个库的高级特性，而是这句选型总开关：没有"全都要"的系统，只有"恰好匹配你业务"的系统。 对着一张候选清单时，别让"哪个听起来更先进"先入为主，而是按三件事逐家过堂——你的数据模型是关系型、灵活文档还是简单键值；你的一致性要求是强事务、最终一致还是能接受短暂旧读；你的负载类型是核心交易 OLTP、海量高并发还是大规模分析 OLAP。三个坐标一套，候选名单立刻被砍到一两家。真到多选一时，再拿"生态成熟度、运维成本、团队熟悉度"去补最后几刀。这套流程，正是把前七章积累的判断力一次性用到一个真实决策里。

复盘与延伸

到这里，整套教程也算走完了一遍分布式从原理到产品的全景。往回看，第 2、4、6 章是"怎么把数据拆开并让它稳"，第 5 章是"怎么让多机做事不乱"，第 7 章是"怎么让它快"，第 8 章则是"这些都是谁、各自值不值得选"。若你想继续深入，可以按兴趣往三个方向钻：往"共识实现"深挖（读 Raft 论文与 TiKV 源码）、往"存储引擎"深挖（读 OceanBase 的存储设计）、或往"分布式事务新范式"深挖（研究 CockroachDB 的平行提交与跨行事务）。每深入一步，第 5 章那些 2PC/MVCC 的取舍都会再清晰一层。