Scaling Etsy Payments with Vitess: Part 1 – The Data Model

Phần 1/3. Phần 2: Etsy 2023 · Phần 3: Etsy 2023.

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

Bối cảnh

• Cuối 2020, hai database thanh toán đã ở cấu hình máy cao nhất của Google Cloud, không scale dọc được nữa; tăng đột biến có thể gây chậm hoặc mất giao dịch.
• 12/2020 → 5/2022: chuyển 23 bảng, hơn 40 tỉ dòng, từ bốn database thanh toán chưa shard vào một môi trường shard do Vitess quản lý. Vitess đã quản lý hạ tầng DB từ trước, nhưng đây là lần đầu dùng vindex để shard dữ liệu.

Thay đổi chính

• Mô hình lý tưởng để shard: nông, một thực thể gốc mà mọi bảng tham chiếu, nên mọi bảng dùng chung shardifier và dữ liệu liên quan nằm cùng shard (thao tác trên một shard, shard hỏng chỉ ảnh hưởng ít người).
• Giai đoạn 1, ledger người bán (gần lý tưởng): shard theo shop_id (đã là shardifier ở nơi khác của Etsy, và chừa đường cho một shop nhiều ledger). Vẫn nặng: thêm cột, sửa primary/unique key khi DB đang thiếu tài nguyên, backfill hàng tỉ dòng bằng script chỉnh tốc độ lúc chạy (nhanh tới 60 lần nhờ INSERT … ON DUPLICATE KEY UPDATE), sửa hàng trăm query và fixture test.
• Giai đoạn 2, DB thanh toán chính (hơn mười năm, gần 90 bảng): chỉ chuyển nhóm bảng có lượng query cao nhất và bảng liên quan. Mô hình không phải cây: một payment liên quan nhiều shop, adjustment liên quan nhiều loại transaction.
  • Phương án 1: thiết kế lại lõi (đổi tên, thêm thực thể Payment gom mọi thứ để shard theo payment_id). Đúng nhưng phạm vi vượt xa mục tiêu scale DB.
  • Phương án 2 (được chọn): dùng khoá có sẵn shard từng cây con; reference_id làm shardifier đa hình để transaction nằm cùng payment hoặc adjustment của nó (đổi lại adjustment và payment không cùng shard).
• Chỉ phần nhỏ bảng đó cũng giảm 60% tải DB chính. Theo Etsy, resharding và secondary (lookup) vindex của Vitess cho phép đổi thiết kế shard sau này.

Vì sao

• Mức độ khẩn cấp và yêu cầu giữ thanh toán ổn định khiến phương án ít động vào code thắng phương án mô hình đẹp.

Bài học cho SWE

• Hình dạng mô hình dữ liệu quyết định độ khó shard; mô hình phát triển lâu năm hiếm khi có một gốc chung.
• Chọn shardifier đã dùng ở nơi khác giúp nhất quán toàn hệ thống.
• Không phải chuyển mọi bảng: chuyển bảng nóng nhất đã đủ giảm phần lớn tải.

Liên quan

• Sharding và tách database
• Etsy chuyển toàn bộ sharding sang Vitess về sau: Etsy 2026