Rediscovering Transaction Processing From History and First Principles

TigerBeetle · 2024 · 2. Tăng trưởng · Độ khó: Trung bình — bài gốc

Bài của nhà sáng lập TigerBeetle (Joran Dirk Greef) nhân dịp gọi vốn; vừa kể lý do ra đời vừa quảng bá sản phẩm. Mọi nhận định về giới hạn của database đa dụng là theo TigerBeetle. Bài sau về quy mô: TigerBeetle 2026.

Bối cảnh

• Năm 1985, Jim Gray đề xuất đo OLTP bằng TPS và gắn TPS với giá thành mỗi transaction. "Transaction" chuẩn của ông không phải SQL transaction mà là DebitCredit: ghi nợ một tài khoản, ghi sổ kép, trả lời terminal. Mỗi giao dịch cập nhật account (ngẫu nhiên), ghi history (tuần tự), cập nhật teller và branch (ngẫu nhiên).
• Năm 2020, tác giả tư vấn cho một payments switch của ngân hàng trung ương (Mojaloop, Quỹ Gates): hàng nghìn dòng code bao quanh một database đa dụng để ghi nợ/có. Nhiệm vụ là tìm nút thắt.

Phát hiện: khoá dòng nhân với round-trip

• Mỗi giao dịch tài chính sinh 10–20 câu SQL qua lại mạng trong khi giữ row lock: đọc số dư hai dòng, giữ khoá, chuyển dữ liệu lên tầng ứng dụng, quyết định đủ tiền hay không ở ngoài database, ghi số dư mới, ghi bản ghi giao dịch.
• Thêm phần cứng không tăng được thông lượng. Theo tác giả, giới hạn nằm ở concurrency control: khoá dòng tương tác với RTT. Ví dụ 2 RTT × 0,5 ms thì khoá bị giữ ít nhất 1 ms, tức tối đa khoảng 1000 giao dịch/giây trên mỗi dòng.
• Tệ hơn, giống tài khoản "branch" trong benchmark của Gray, doanh nghiệp có hàng chục triệu khách để ghi nợ nhưng chỉ vài tài khoản nội bộ để ghi có. Những dòng nóng này bị khoá trong hầu hết giao dịch, tuần tự hoá cả hệ và xoá mất lợi ích của scale ngang. OLTP vốn có tranh chấp nội tại.
• Bối cảnh tăng tải: thanh toán tức thời ở Ấn Độ tăng 7000 lần trong 7 năm lên 14 tỉ giao dịch/tháng (số liệu 2024); Pix ở Brazil, FedNow ở Mỹ; năng lượng, game, tính tiền cloud theo giây.

Thiết kế của TigerBeetle

• Debit/credit là primitive hạng nhất. Một debit/credit là 128 byte (2 cache line); một request 1 MiB chứa tới 8000 giao dịch, xử lý trong một round-trip, không row lock. Theo TigerBeetle, việc trước cần ít nhất 8000 câu SQL nay là 1 query: đây là ý tưởng "1000 lần" của họ, "không làm gì đặc biệt".
• Không bỏ được hẳn round-trip (nhúng database vào tiến trình vẫn cần replication và đồng thuận) nhưng khấu hao được.
• Primitive phong phú hơn: giao dịch pending để giữ tiền rồi post, tự hoàn khi hết hạn; theo tác giả, TigerBeetle làm điều phối viên two-phase commit tốt.
• An toàn: Protocol-Aware Recovery (2018) cho lỗi storage, theo "Power of Ten" của NASA (cấp phát bộ nhớ tĩnh, hơn 6000 assertion), chạy trong deterministic simulator với model checking trên chính code.
• Từ 2020 đến production mất 4 năm; khách đầu tiên là một nhà cung cấp năng lượng.

Vì sao

• Postgres, MySQL, SQLite (20–30 năm tuổi) tốt cho ứng dụng nhưng, theo TigerBeetle, được thiết kế cho thời kỳ ít giao dịch hơn ba bậc; extension hay stored procedure không gỡ được gốc là khoá giữ qua mạng.

Bài học cho SWE

• Trần thông lượng của giao dịch tương tác trên dòng nóng là 1 / (thời gian giữ khoá); thời gian giữ khoá gồm cả RTT tới ứng dụng (Hot partition và thundering herd).
• Đưa quyết định vào trong database và gom nhiều giao dịch vào một request đổi bài toán từ "giảm latency mạng" sang "khấu hao latency mạng" (Batching và khấu hao round-trip).
• Workload ghi sổ kép có hình riêng (ít dòng nóng, nhiều dòng lạnh); chọn engine theo hình đó thay vì mặc định database đa dụng (Chọn database theo workload).
• So sánh với Deno 2023: giao dịch không tương tác gói điều kiện và lệnh ghi thành một lô, cũng để bỏ round-trip giữa lúc giữ trạng thái.

Liên quan

• TigerBeetle 2026 · Deno 2023
• Batching và khấu hao round-trip · Hot partition và thundering herd · Chọn database theo workload · Giao dịch phân tán và nhất quán xuyên service