Announcing Snowflake
Bài tóm tắt Twitter 2010 2. Tăng trưởng Độ khó: Trung bình
Twitter · 2010 · 2. Tăng trưởng · Độ khó: Trung bình — bài gốc
Bối cảnh
- 6/2010. Dữ liệu online chủ yếu trên MySQL: từ một instance nhỏ thành một instance lớn rồi thành nhiều cluster lớn. Twitter đang thay dần bằng Cassandra hoặc MySQL shard ngang (qua Gizzard).
- Cả Cassandra lẫn MySQL đã shard đều không có cách sinh ID duy nhất có sẵn.
Thay đổi chính
- Yêu cầu:
- Hàng chục nghìn ID/giây, sẵn sàng cao, nên chọn cách không phối hợp (uncoordinated).
- Gần như sắp theo thời gian ("k-sorted"): tweet đăng cách nhau dưới ~1 giây thì ID cũng gần nhau, vì client sắp tweet theo ID.
- Vừa 64 bit. Họ từng tăng số bit của tweet ID và đã khổ vì có hơn 100.000 codebase phụ thuộc.
- Phương án bị loại: ticket server MySQL kiểu Flickr (không đảm bảo thứ tự nếu không tự viết cơ chế đồng bộ lại); UUID (đều cần 128 bit); ZooKeeper sequential node (không đủ hiệu năng, và phối hợp làm giảm availability).
- Giải pháp: ID = timestamp + số worker + sequence. Sequence tính theo thread; số worker lấy qua ZooKeeper lúc khởi động (hoặc từ file config). Mã nguồn mở, lúc đó còn alpha, chưa chạy production.
Vì sao
Theo Twitter: chuyển sang lưu trữ phân tán làm mất auto-increment, mà client lại phụ thuộc vào thứ tự ID. Phối hợp toàn cục làm giảm availability mà không được lợi gì thật.
Bài học cho SWE
- Đổi kích thước ID là việc cực đắt khi nhiều hệ thống bên ngoài phụ thuộc vào nó. Chọn 64 bit ngay từ đầu.
- "Sắp xếp gần đúng" (k-sorted) đủ dùng và rẻ hơn nhiều so với thứ tự tuyệt đối.
- Snowflake về sau được dùng rộng rãi: Discord dùng Snowflake làm mọi ID (Discord 2017); Instagram mượn ý tưởng nhưng đưa vào trong Postgres (Instagram 2011).
Liên quan
- Sinh ID phân tán
- Sharding và tách database
- Twitter 2013 (Snowflake trong bối cảnh tách storage)
Được nhắc tới trong
Chủ đề (2)
Công ty (1)