Etsy把425TB数据库切成1000片

Etsy的MySQL集群有425TB数据，切成1000个分片跑了多年。今年他们把这套"祖传架构"迁到Vitess，运维工单直接少了47%。

这不是小修小补。Ella Yarmo-Gray，Etsy高级软件工程师，在团队博客里说得很直白：他们用了8年时间自建分片系统，ORM层硬编码分片逻辑，每次扩缩容都是"人工排雷"。

Vitess是YouTube 2010年开源的项目，后来捐给CNCF（云原生计算基金会）。它干的事很简单：让MySQL像分布式数据库一样水平扩展，但不改MySQL本身。

Etsy的迁移分三步走。第一步，Vitess先当"透明代理"——查询从ORM过来，Vitess原样转发到指定分片，ORM里的分片逻辑不动。这一步花了18个月，只为验证稳定性。

第二步最折磨人：把ORM里的硬编码分片键，逐步迁移到Vitess的vindex（虚拟索引）系统。vindex决定一行数据落在哪个分片，也决定查询该路由到哪。Etsy的ORM之前用随机映射，没有算法规律，没法直接用Vitess现成的哈希方案。

Yarmo-Gray解释了这个坑："我们的分片键是业务ID的随机子集，不是哈希值。直接切到哈希vindex，数据会全乱。"团队最终写了自定义vindex，把旧映射规则"翻译"成Vitess能理解的格式。

1000个分片的"债务"怎么还

Etsy的分片架构始于2016年。当时单表数据膨胀，工程师手动把表拆到多个MySQL实例，用业务ID取模决定路由。这套方案跑通后，他们建了内部工具管理分片拓扑，但所有变更都要人工审核、手动执行。

8年积累下来，技术债务相当可观。Yarmo-Gray列了几组数字：分片扩容平均耗时2周，涉及跨团队协调；新增分片表需要改ORM代码、发版、全量回归测试；最头疼的是"热点分片"——某些商家促销时，单个分片CPU飙到90%，隔壁分片却闲置。

Vitess的卖点正是解决这些。resharding（重新分片）功能允许在线调整分片数量，数据在后台迁移，应用无感知。Etsy之前想都不敢想：他们的1000分片是"一次性设计"，从没拆分过。

迁移到Vitess后，第一个被"解锁"的是未分片表。Etsy有大量历史表仍在单实例MySQL，因为"再分一次太麻烦"。Vitess支持把未分片表挂到任意分片，后续随时转成真正的分片表，无需应用改造。

更隐蔽的收益是查询路由优化。Vitess的查询分析器能识别分片键条件，自动把查询发到目标分片，而不是广播到全部1000个。Yarmo-Gray提到一个案例：某报表查询原本扫描全部分片，优化后只触达3个，延迟从800ms降到12ms。

ORM这层"胶水"撕了3年

Etsy的技术栈有个特殊点：重度依赖内部ORM。这个ORM封装了MySQL访问，也硬编码了所有分片逻辑。迁移Vitess的最大阻力不是数据库，是这层ORM。

团队试过激进方案：一次性重写ORM，把分片逻辑全抽出去。评估后放弃——Etsy有2000多个服务调用这个ORM，任何break change都是"核事故"。

最终策略是"双轨制"。Vitess先以 sidecar 模式部署，ORM继续算分片、指定目标，Vitess只做转发。这一步让团队确认了Vitess的吞吐能力：峰值QPS 12万，P99延迟<5ms，和直连MySQL几乎无差。

第二阶段引入vindex，但保留ORM的"分片提示"作为fallback。如果Vitess的路由和ORM不一致，以ORM为准，同时打日志告警。这个设计让迁移可以灰度：先切1%流量验证，再逐步扩大。

整个迁移耗时36个月。前18个月是"影子模式"，Vitess只转发不决策；后18个月逐步接管路由，ORM的代码同步删减。到最后一个服务改造完成时，ORM里的分片相关代码从4.2万行降到800行。

开源方案的隐藏成本

Vitess是开源的，但Etsy的投入并不小。团队贡献了47个PR，包括自定义vindex的插件接口、监控指标增强、与内部CI/CD的集成工具。Yarmo-Gray说："我们算过，如果自研同等能力，需要再加5个DBA全职干两年。Vitess让我们省了这笔，但省的不是零成本。"

有个细节值得玩味。Vitess的resharding在理论上很美好，但Etsy第一次执行时踩了坑：后台数据迁移占满磁盘IO，导致在线查询抖动。团队最终限制了迁移带宽，并给Vitess提交了"IO限速"的PR。

另一个发现是运维心智负担的变化。之前DBA需要维护分片拓扑图、手动处理主从切换、监控2000多个MySQL实例的健康度。Vitess把这些收进控制平面，DBA的日常工作从"救火"变成调参和容量规划。

Yarmo-Gray分享了一组对比数据：迁移前，每月平均23起分片相关工单；迁移后12个月，降到12起，其中8起是"如何配置新vindex"的咨询，真正故障4起。47%的降幅背后，是工作性质的质变。

但Vitess并非万能药。Etsy明确没迁移的，是强一致性事务——跨分片事务在Vitess里需要两阶段提交，延迟和复杂度都高。这类场景他们仍用单实例MySQL，或改业务逻辑规避。

425TB数据、1000分片、36个月、47%工单降幅。这些数字背后，是一个经典的技术决策：当自建系统进入维护瓶颈，是继续投入人力优化，还是拥抱开源方案重新布线？

Etsy选了后者，但路径很克制——没有"大爆炸"重写，而是让新旧系统长期共存，逐步交接。Yarmo-Gray在博客结尾说，他们正在评估Vitess的跨地域复制能力，下一步可能是把部分分片迁到欧洲节点。这会是另一场36个月的马拉松吗？