创一代与富二代在 Shared Nothing 和 Shared Disk 上的抉择

在分布式系统的江湖里，一直存在着两条截然不同的路线。

如果你去看开源社区和独角兽们的成名作——ScyllaDB、Cassandra、TiKV、Ceph，以及最近大火的 DeepSeek 3FS，它们几乎清一色地选择了 Shared Nothing 架构。每个节点既是计算也是存储，守土有责，互不干涉，像是一个个占山为王的诸侯。

然而，当你把目光转向那几座由于垄断资源而建立起的“云端帝国”——Google Bigtable、Azure Storage (Blob/File)、Alibaba Cloud(OSS/EBS)，你会发现它们更倾向于 Shared Storage（或存算分离）架构。计算层是无状态的“打工人”，数据统一存放在底层的存储池里，像是一个中央集权的帝国。

为什么会有这种“小团队偏爱 Shared Nothing，大公司偏爱 Shared Disk”的规律？这背后，其实是创一代（技术突围者）与富二代（资源继承者）在面对不同约束条件时的最优解。

一、 创一代的武器：Shared Nothing 与“数据局部性”的执念

对于 ScyllaDB、Cassandra 或早期的 TiKV 团队来说，他们在起步时面临的核心约束是：没有“祖产”。

他们无法假设用户拥有像 Google Colossus 或 AWS EBS 那样稳定、无限扩展的分布式文件系统。他们的软件必须跑在裸金属服务器上，跑在普通的 AWS EC2 实例上，甚至跑在用户的私有机房里。

1. 交付的独立性 (Independence)

Shared Nothing 是软件交付的最优解。

• 开箱即用： 你下载一个 TiKV 或 Cassandra 的二进制包，部署在三台机器上，它们就能组成一个高可用的集群。
• 零依赖： 不需要依赖一个底层的 SAN、不需要依赖 S3、不需要依赖专有的硬件。这种“自包含”的特性，是开源软件能迅速占领市场的关键。

2. 对 IO 延迟的极致压榨 (Data Locality)

在“创一代”崛起的年代，网络往往是瓶颈。万兆网卡尚未普及，跨机访问数据的延迟远高于本地 NVMe SSD。 Shared Nothing 架构的核心优势在于 Data Locality（数据局部性）。计算就在数据旁边，SQL 请求发给节点，节点直接读本地磁盘。这种架构在性能测试（Benchmark）中极具杀伤力，能够以极低的硬件成本跑出极高的 TPS。

3. 同构硬件带来的运维极简 (Operational Minimalism of Homogeneous Hardware)

对于只有几个人的核心研发团队来说，维护两套异构系统（计算集群 + 存储集群）是难以承受的认知负载。 Shared Nothing 架构通常采用同构（Homogeneous）节点设计。

• 单一角色： 集群里每一台机器都是一样的。运维人员不需要分别关心“存储层水位”和“计算层负载”，只需要盯着一种节点。
• 线性规划： 缺资源了？加机器。这种简单粗暴的线性扩容逻辑，虽然在后期会导致资源浪费（见下文“富二代”的分析），但在创业初期，它极大地降低了容量规划（Capacity Planning）的复杂度。

代价是什么？是“既当爹又当妈”的系统复杂度。 既然选择了 Shared Nothing，你的软件就不能只做一个数据库，你必须同时做一个文件系统和资源管理器。系统必须在应用层实现所有功能：

• 不得不处理的底层故障（Disk Failures）： Google Bigtable 从不担心某块磁盘坏了，因为底层的 Colossus 文件系统会自动在后台修复副本。但在 Shared Nothing 架构下，TiKV 的工程师必须在代码里处理磁盘坏道、位翻转（Bit rot）和节点宕机。
• 痛苦的数据搬运（Rebalance）： 当集群扩缩容时，你没有共享存储池可以“挂载”，只能通过网络实打实地搬运数据。

二、 富二代的特权：Shared Disk 与“存算分离”的红利

当 Google 设计 Bigtable，或者微软设计 Azure Storage 时，他们的视角完全不同。他们是“富二代”，他们坐拥世界上最强大的网络基础设施和最完善的底层文件系统（GFS, Cosmos ）。

他们不需要为了“卖软件”而在这个架构里打包一个存储引擎，他们本身就是卖服务的。

1. 大规模作战的组织红利：模块复用与职责解耦

对于“富二代”来说，技术架构往往映射着组织架构（康威定律）。Shared Storage 允许大厂进行“集团军式”的大规模协作。

• 模块可复用 (Reusability)： Google 造一个 GFS，不仅 Bigtable 能用，Spanner 能用，对象存储业务也能用。这种通用的底层基座，极大地分摊了研发成本。
• 团队职责解耦： 采用 Shared Storage 后，上层应用（如 Bigtable）完全不需要关心底层的物理故障。坏盘、位翻转（Bit rot）、副本修复，全都是底层存储团队的事。Bigtable 团队只需要专注于数据结构和查询优化。这种分工让每个团队都能在自己的领域做到极致，而不需要像“创一代”那样从磁盘驱动写到 SQL 解析。

2. 网络摩尔定律的逆袭

随着 RDMA (RoCEv2) 的普及，跨网络访问存储的延迟已经无限逼近本地磁盘。当网络不再是瓶颈，“数据局部性”的优势就被大大削弱了。 既然远程读写和本地读写差不多快，为什么还要把数据死死地绑在计算节点上？

3. 资源利用率与成本 (Bin Packing)

大厂最在意的是 TCO（总拥有成本）。 在 Shared Nothing 架构中，计算和存储是强耦合的。如果你的业务是“计算密集型”，CPU 跑满了但磁盘是空的，你依然得扩容节点，导致磁盘浪费。反之亦然。 Shared Storage 实现了存算彻底解耦。计算不够加 CPU，存储不够加磁盘。这种颗粒度的资源调度，只有在拥有超大规模资源池的“富二代”手中才能发挥出巨大的成本优势。

三、 为什么“创一代”不先造基座？——放弃 Shared Storage 的无奈与智慧

有人可能会问：既然 Google 的 GFS + BigTable 模式如此成功，为什么 TiKV、 ScyllaDB 的团队不先模仿 Google，造一个高性能的、Append-only 的分布式文件系统，然后再在上面构建数据库？

这并非技术上的短视，而是商业与工程上的精准算计。

1. 交付门槛：要“开箱即用”而不是“全家桶”

如果 TiKV 要求用户在部署数据库之前，先部署一套复杂的分布式文件系统（类似 HDFS 或 Ceph），那么它的尝试成本（Try-on Cost）将无限拔高。

• 大厂逻辑： 基础设施已经存在，业务直接复用。
• 创业逻辑： 用户环境是一张白纸。

为了让用户能用一行 docker run 或一个 binary 跑起来，”创一代”必须把复杂的存储管理、副本复制（Raft/Paxos）、故障恢复全部内聚在数据库进程内部。Shared Nothing 是实现“零依赖”交付的唯一路径。

2. 研发聚焦：造轮子还是造车？

打造一个生产级稳定（99.9999999% Durability）的通用分布式文件系统，其难度和周期丝毫不亚于开发一个数据库本身。 对于一家创业公司，资源只能集中在一点进行突围。如果先造文件系统，可能还没等到数据库上线，公司资金链就断了。只有拥有海量通用存储需求（网盘、虚拟机、大数据）的大厂，才有动力去平摊研发一个通用存储底座的成本。

3. 性能的垂直整合 (Vertical Integration)

通用的 Shared Storage 往往需要兼顾各种 IO 场景。而数据库的 IO 模型非常单一且明确（通常是 LSM-Tree 的顺序写）。 Shared Nothing 架构允许数据库直接管理本地磁盘（通过 RocksDB/LSM），将一致性协议（Raft Log）与存储引擎垂直整合。这种“定制化”设计，避免了通用文件系统的元数据开销和网络开销，在早期的硬件条件下，是获取高性能的最短路径。

结论： Shared Nothing 是“创一代”在没有基础设施红利的前提下，为了生存和独立交付而做出的必然选择。他们不是不想用 Shared Storage，而是造不起，也等不及。

四、 总结：你的屁股决定了你的架构

小团队为了生存和交付，选择把复杂性吞在肚子里（代码实现复杂），对外呈现一个简单的 Shared Nothing 整体。 大公司为了效率和规模，选择把复杂性拆解到基础设施层（运维部署复杂），对外呈现一个灵活的存算分离架构。

从 Shared Nothing 到 Shared Disk，并不是技术的优劣之分，而是从“单兵作战”到“集团军作战”的必然演进。

最后打个广告，想看"不正经但更有趣的技术"请移步《文件系统演义》