The history of Postgres sharding

PlanetScale · 2026 · 4. Điều chỉnh · Độ khó: Trung bình — bài gốc

Nguồn thứ cấp, do nhà cung cấp viết: bài tổng quan lịch sử, kết thúc bằng giới thiệu sản phẩm Neki của chính PlanetScale. Mọi nhận định so sánh dưới đây là "theo PlanetScale"; các mốc về Instagram, Facebook nên đối chiếu với nguồn gốc trong wiki.

Nội dung chính

• Vì sao MySQL đi trước: thời LAMP, nhiều công ty thành công dùng MySQL nên công cụ shard và online schema change (gh-ost, Vitess) phát triển sớm hơn.
  • Facebook 2008: hơn 100 triệu user trên khoảng 1.800 node MySQL, shard ở tầng ứng dụng theo user ID; sau đó xây TAO.
  • YouTube: một primary → replica → shard trong ứng dụng → khoảng 2010 tách tầng định tuyến thành dự án riêng, tức là Vitess. Nhiều công ty LAMP sau đó gom về Vitess.
• Postgres: tự xây rồi sống chung với nó. Phần lớn giải pháp là nội bộ, không thành phần mềm độc lập.
  • Skype PL/Proxy (2007): proxy định tuyến bằng hàm SQL; mỗi mẫu query cần một hàm riêng.
  • Instagram (2012): khoảng 30 triệu user, shard logic bằng hàng nghìn schema trên vài máy vật lý, ánh xạ trong ứng dụng, không proxy. Đổi lại, query xuyên shard và việc dời schema do ứng dụng lo, và gắn với ID kiểu riêng (Instagram 2011).
• Đưa vào Postgres: Citus (fork năm 2011, thành extension năm 2016), mô hình coordinator/worker. Theo PlanetScale: coordinator thành nút cổ chai, quản lý shard và backup nửa thủ công. PgDog, Aurora Limitless thì làm proxy hoặc router; resharding và schema change vẫn nặng tay.
• Giấu khoá shard: Spanner (paper 2012, dịch vụ 2017), CockroachDB, Yugabyte tự chia và dời dữ liệu. Theo PlanetScale, vì không phải Postgres thật nên hạn chế extension và tính năng, và khó đoán vị trí dữ liệu: các dòng liên quan có thể trôi sang nơi khác, làm latency tăng.
• Lập trường của PlanetScale: shard tường minh (người dùng kiểm soát) trên Postgres thật, router không trạng thái scale ngang, và tự lo backup, failover, schema change. Đây là lập luận cho sản phẩm Neki của họ.

Bài học cho SWE

• Mẫu lặp lại ở nhiều công ty: một primary → replica → shard trong ứng dụng → tách tầng định tuyến thành hệ thống riêng (YouTube/Vitess, Facebook/TAO, Figma/DBProxy). Xem Sharding và tách database.
• Shard tường minh hay tự động là một trục lựa chọn thật: tường minh thì dễ đoán chi phí xuyên shard; tự động thì đỡ thiết kế nhưng khó đoán latency. Figma loại CockroachDB/Spanner vì lý do gần giống (Chọn database theo workload).
• Đọc bài của nhà cung cấp như đọc lập luận có chủ đích: phần lịch sử hữu ích, phần so sánh cần kiểm chứng.

Liên quan

• Sharding và tách database
• Chọn database theo workload
• Cùng công ty: PlanetScale 2025