Migrating Etsy's database sharding to Vitess

Etsy · 2026 · 4. Điều chỉnh · Độ khó: Nâng cao — bài gốc

Bối cảnh

• Etsy shard MySQL từ khoảng 2010: ~1.000 bảng trên ~1.000 shard, hơn 425 TB, ~1,7 triệu request/giây (2026).
• ORM tự viết quản lý shard:
  • mỗi bảng shard có một "shardifier id" (phần lớn là shop_id hoặc user_id, tổng cộng hơn 30 loại) để đặt dữ liệu liên quan cạnh nhau;
  • khi tạo bản ghi, ORM chọn shard ngẫu nhiên rồi lưu ánh xạ vào một "index database" không shard; mỗi query phải tra DB này trước.
• Ưu: scale được; một shard sập chỉ mất 1/1000 traffic.
• Nhược:
  • scale ngang làm tay, phức tạp, mất nhiều tháng;
  • index DB là điểm hỏng chung: nó sập là sập cả site, và số sự cố tăng theo thời gian;
  • developer phải hiểu và tự quản lý sharding.

Thay đổi chính

• 2018: đặt Vitess vào giữa ORM và MySQL; lúc đầu ORM vẫn chỉ định shard, để kiểm chứng các thành phần mới trước. Làm quen với vindex (chiến lược shard của Vitess) bằng cách shard vài bảng payments chưa từng shard.
• Không reshard dữ liệu: ánh xạ cũ là ngẫu nhiên nên không thể dùng ngay hash vindex có sẵn; reshard toàn bộ thì sẽ mất nhiều năm. Thay vào đó:
  1. đổi thuật toán gán shard của ORM sang giống hash vindex của Vitess, nên ID mới không cần tra index DB nữa;
  2. chuyển các ánh xạ cũ sang SQLite chỉ đọc, copy thẳng lên mỗi server Vitess (nhanh, không phụ thuộc DB ngoài);
  3. viết vindex lai: ID nhỏ hơn ngưỡng (trước mốc đổi thuật toán) thì tra SQLite, lớn hơn thì dùng hash.
• Chuyển từng bảng một, tăng dần % traffic bằng nền tảng experiment, so sánh hiệu năng, hạ về 0 được ngay. Vitess đòi shardifier id phải có trong WHERE, trong khi ORM cũ không đòi, nên phải sửa nhiều query.
• Transaction: cách cũ và cách mới tạo connection khác nhau, mà tính nguyên tử chỉ có trong một connection, nên các bảng ghi chung trong một transaction phải chuyển cùng lúc. 27 model (3% số bảng) chiếm 1/3 traffic và dính nhau qua transaction, phải chuyển đồng loạt với sự phối hợp toàn công ty.
• Scatter query (query thiếu khoá shard thì gửi tới mọi shard): một query giảm từ ~2 giây xuống ~20ms, nhưng mặc định bị tắt để tránh vô tình bắn query đắt tới 1.000 shard. Phải bật rõ ràng qua ORM.

Kết quả

Mất 5 năm, ~2.500 PR, ~6.000 query.

• Scale vận hành giờ tính bằng ngày thay vì tháng.
• Bỏ được điểm hỏng index DB.
• Developer không còn phải thấy sharding.
• Hiệu năng gần như không đổi.
• Mở đường cho reshard, rebalance, MoveTable.

Vì sao

Theo Etsy: số sự cố do index DB tăng, scale bằng tay quá chậm, và sharding làm khó developer.

Bài học cho SWE

• Tầng sharding tự xây thường giấu một điểm hỏng chung (bảng tra cứu shard). Đổi sang thuật toán (hash) thì bỏ được bảng tra.
• Thay cơ chế route mà không dời dữ liệu: dùng vindex lai cho dữ liệu cũ và mới. Tách "đổi cách tìm" khỏi "đổi chỗ để".
• Transaction là thứ làm các thay đổi "từng bảng một" dính lại thành một khối lớn.
• Scatter query vừa là sức mạnh vừa là mối nguy, nên mặc định phải tắt. Xem thêm Figma DBProxy (Figma 2024).
• Cùng xu hướng với Twitter, Slack, GitHub: thay tầng tự xây bằng Vitess (Twitter 2023).

Liên quan

• Sharding và tách database
• Migration không downtime
• Hot partition và thundering herd