数据库扩展：复制还是分片？

你的初创公司起飞了。但快乐变成了恐慌：数据库正在“窒息”。CPU 满了，查询挂起 5 秒钟。仅仅“增加 RAM”已经没有帮助了。是时候选择架构药丸了：复制还是分片？

架构师的困境

选择策略取决于你的“瓶颈”究竟在哪里：是在读取 (Read) 还是写入 (Write)。

1. 复制 (Replication)：扩展读取

本质： 你有一个“老板” (Master) 接受所有更改，还有许多“下属” (Slaves) 只提供数据。

• 何时使用： 80-90% 的负载是读取 (Read-heavy)。典型用于媒体、博客、电子商务目录。
• 优点： 易于配置 (PostgreSQL Streaming Replication, MySQL Binlog)。数据重复 (备份)。
• 缺点： 复制延迟 (Replication Lag)。你将数据写入 Master，但它在 100 毫秒后出现在 Slave 上。用户可能无法立即看到他们的评论。

2. 分片 (Sharding)：扩展写入

本质： Master 无法应付写入。我们将数据库切成块。用户 A-M 去服务器 1，N-Z 去服务器 2。

• 何时使用： 数据太大，一张磁盘装不下。或者当一个 Master 无法跟上写入速度 (Write-heavy)。
• 优点： 理论上无限扩展。
• 缺点： 这很痛苦。你失去了分片之间的 ACID 事务。你失去了 JOIN (如何连接来自服务器 1 和服务器 2 的表？)。备份成为噩梦。

NineLab 裁决

黄金法则： 将分片推迟到最后一刻。这是一个“核按钮”。

首先 —— 索引。然后 —— 缓存 (Redis)。然后 —— 复制。只有当你拥有 Telegram 或 Uber 级别的流量时 —— 分片。不要过早地使架构复杂化。