PlanetScale通过数据库分片技术，将768台服务器整合为单一逻辑单元，解决了大规模应用（如每秒百万级查询、PB级数据）的扩展难题。文章解释了从单节点到多分片数据库的演进过程，强调分片是扩展PostgreSQL或MySQL数据库的最佳方式。

让768台服务器看起来像1台——PlanetScale的数据库分片之道

当应用需要处理每秒数百万次查询、服务数百万用户时，数千台服务器协同工作已是常态。而其中最棘手的扩展难题，几乎总是数据库。单台数据库服务器无法应对如此需求，因此必须通过数据库分片将查询和数据分散到多台服务器上。

为什么需要分片？

在扩展关系型数据库时，垂直扩展（增加CPU/内存）和添加只读副本只能解决部分问题，以下瓶颈无法绕过：

1. 写入瓶颈：所有写入操作必须由主节点处理，写入日志（WAL）是共享资源，即使有数十个副本也无法缓解写入压力。
2. 数据容量限制：副本是主数据的完整拷贝，无法分散存储容量。
3. 备份耗时：对大型单体数据库进行备份可能耗时数小时甚至数天，无法满足频繁备份的需求。

分片如何解决？

分片将数据和查询分布到多个独立的主节点上。例如，2TB数据可拆分为4个分片，每个分片存储500GB并处理1/4的查询流量；而存储1PB数据时，可能需要256个分片（每个分片含1主+2副本），总计768台服务器。

关键挑战：让768台服务器看起来像1台

分片系统需要解决以下问题： - 数据如何分配到各服务器？ - 查询如何路由到正确服务器？ - 跨分片查询如何聚合结果？ - 如何监控全局健康状态？

代理层（Proxy Layer） 是核心组件。它作为中间件，不仅负责连接池管理和请求排队，还必须理解数据分布规则，将SQL查询路由到正确的分片。例如，插入数据时根据ID哈希值分配分片；读取时，简单查询直接路由到单分片，跨分片查询则需聚合结果。

实现方式

• 路由规则：通过JSON文件（如Vitess的VSchema或Neki的数据拓扑）定义分片策略，指定表按哪一列、用何种哈希算法分片。
• 多代理架构：面对256个分片、每秒数百万查询，需部署多个代理（如10-100个），并通过网络负载均衡器（NLB）将应用连接分发到不同代理，实现统一入口。
• 完整流程：应用连接至统一地址（如mydb.pscale.com）→ DNS解析到NLB IP → NLB将连接分配给某个代理 → 代理根据分片规则将查询路由到对应分片。所有复杂逻辑对应用透明。

何时开始分片？

建议在数据量超过数TB时启动分片，此时通常已遇到备份慢、写入瓶颈等问题。Vitess（用于MySQL）和Neki（用于PostgreSQL）是成熟的解决方案，已在全球大规模数据库中得到验证。

分片系统还涉及数据分布策略、故障处理、动态调整分片数、跨分片备份等更多细节，后续将陆续探讨。

根据评论内容，总结主要观点如下：

1. 对技术实现的质疑（评分：无，但讨论深入） - 评论4（drdexebtjl）质疑跨分片查询的可行性：序列生成、外键、分布式事务、排序和连接等操作在768台服务器上是否真能像单机一样工作？"I suspect the 768 servers look like 1 only on the very surface"（我怀疑768台服务器只是表面上看起来像一台） - 评论7（foxhill）指出通用实现的困难：某些SQL约束（如重叠约束、包含排除检查）在多写入者环境下难以保证ACID特性。"there's a reason why postgres writing is (mostly) serialised to a single writer... something something ACID"（Postgres写入序列化是有原因的...关乎ACID）

2. 对扩展必要性的质疑（评分：无，但多位用户持此观点） - 评论5（groundzeros2015）反对"单机无法满足需求"的前提："Did you max out the capacity of the best server you can buy?"（你试过最好的服务器了吗？）认为应先优化其他组件，最后才考虑分片 - 评论11（themgt）质疑"瓶颈很快出现"的说法："Err, do they? For what percent of real world use cases?"（真的吗？对多少实际用例而言？）指出OpenAI用50个副本已是极端案例，而文章却声称需要768台服务器

3. 对成本与复杂性的反思（评分：无） - 评论9（kjellsbells）认为从"宠物到牲畜"的转变并未真正节省成本："You can have a few honking servers or you can hand massage exotic k8s setups... dont delude yourself that the TCO of the latter is lower"（你可以用几台大服务器，也可以精心维护复杂的k8s...别自欺欺人认为后者总拥有成本更低）

4. 对文章性质的识别（评分：无） - 评论6（Hugsbox）指出："Took me an embarrassing amount of time to realize this is an ad"（花了好一阵才意识到这是广告）

5. 对可视化效果的正面评价（评分：无） - 评论2（jdw64）称赞动画效果："It's really nice to look at, well made, and easy to understand too"（看起来很棒，制作精良，易于理解）

6. 对竞品的提及（评分：无） - 评论12（hasyimibhar）提到竞品Multigres，并指出Neki首次公开内部架构

7. 其他技术疑问（评分：无） - 评论1（alightsoul）询问是否涉及负载均衡、微服务和水平扩展 - 评论8（skeptic_ai）询问复杂连接操作的分片实现方式 - 评论10（metalliqaz）询问图表/动画的制作工具