A Trillion Transactions

TigerBeetle · 2026 · 3. Quy mô lớn · Độ khó: Khó — bài gốc

Bản viết của một talk, do nhà cung cấp (TigerBeetle) viết; phần demo một nghìn tỷ giao dịch chỉ có trong video. Mọi nhận định, nhất là phần phê phán sharding, là theo TigerBeetle.

Luận điểm

• Scale là khả năng sống sót, không chỉ hiệu năng: khó nhất là sống được khi mọi thứ hỏng.
• Workload khó nhất là OLTP: latency thấp, ghi nhiều kiểu Black Friday, tranh chấp theo luật luỹ thừa (hot key), strict serializability. Thước đo kinh điển là debit/credit (Jim Gray).
• Một nghìn tỷ giao dịch × khoảng 128 byte ≈ 128 TiB dữ liệu chính, đúng ngưỡng mà nhiều cloud database đặt giới hạn cứng (64/128/256 TiB).
• MTTR so với MTBF: dựng lại một máy 128 TiB qua NIC 100 Gbit mất khoảng 2,9 giờ, cộng dựng index thì gần 6 giờ. Nếu MTTR > MTBF thì hệ vào vòng xoắn chết: đang hồi phục thì máy khác hỏng. "Quá lớn để hồi phục" thì không còn làm chủ hệ.
• Để không bị giới hạn, mọi thành phần phải có giới hạn tường minh, kể cả giới hạn thời gian hồi phục.

Bảy giai đoạn tiến hoá của OLTP (theo TigerBeetle)

1. Log: cho thứ tự, độ bền, hồi phục khi mất điện; log càng dài thì replay càng lâu.
2. Snapshot: khởi động nhanh hơn, nhưng 1 TiB ở 10 GB/s mất 100 giây và không vượt được RAM.
3. LSM tree: snapshot tăng dần, khớp phân cấp bộ nhớ, tách nóng/lạnh; nhưng mất máy thì phải hồi phục từ backup.
4. Replicated state machine (Viewstamped Replication, 1988): failover sang primary mới trong tích tắc, không mất độ bền hay nhất quán; nhưng dựng lại một replica 128 TiB vẫn mất hàng giờ, máy khác hỏng giữa chừng thì có thể mất quorum.
5. Sharding ngang: chia trạng thái cho nhiều RSM. Theo TigerBeetle, sharding gắn chặt network, storage, memory, compute và scale chúng cùng một kiểu; tốt cho storage nhưng phá cache locality của giao dịch chéo key, đụng định luật Amdahl khi có tranh chấp. Họ dựng thử một cụm ngang khoảng 1 triệu USD/năm và thấy với tranh chấp 10%, thậm chí 1% hay 0%, một node Postgres còn tốt hơn.
6. Tách storage và compute (đẩy hết lên object storage): storage vô hạn, nhưng latency quá cao cho giao dịch.
7. Diagonal scaling: giữ working set nóng trong một RSM không shard, scale dọc (máy to, NVMe nhanh); đẩy khoảng 90% dữ liệu lịch sử (các tầng thấp của LSM) xuống object storage, scale ngang. RSM được giới hạn (ví dụ 16 TiB) nên thời gian hồi phục có trần, tách khỏi tổng dung lượng.

Thực hành

• TigerBeetle (database chỉ cho OLTP, thiết kế cho số nguyên và đếm thay vì chuỗi) mở rộng LSM với connector xuống object storage. Cụm demo: NVMe cục bộ + object storage, nửa petabyte flash.

Bài học cho SWE

• Đặt thời gian hồi phục làm ràng buộc thiết kế ngang hàng với throughput (Failover, replica và dự phòng dữ liệu).
• Sharding giải bài toán dung lượng nhưng không giải được bài toán tranh chấp; workload có hot key và cần serializable có thể hợp với scale dọc hơn (Sharding và tách database).
• Tiering nóng/lạnh có thể thiết kế để giới hạn MTTR, không chỉ để giảm chi phí (Chọn database theo workload).
• Đây là một phía của cuộc tranh luận. Các nguồn khác trong wiki shard thành công cho workload ít tranh chấp chéo shard.

Liên quan

• Sharding và tách database · Chọn database theo workload · Failover, replica và dự phòng dữ liệu