TigerBeetle là cơ sở dữ liệu thú vị nhất thế giới

(amplifypartners.com)

23 điểm bởi GN⁺ 2025-10-02 | 6 bình luận | Chia sẻ qua WhatsApp

TigerBeetle, cơ sở dữ liệu cho giao dịch tài chính, là một cơ sở dữ liệu mới hỗ trợ ghi nợ (debit) và ghi có (credit) ở mức native; khác với các cơ sở dữ liệu SQL truyền thống cần 10–20 truy vấn cho một giao dịch, nó có thể xử lý 8.190 giao dịch chỉ trong một round trip duy nhất
Trong khi nhiều hệ thống chọn viết mã thật nhanh và mở rộng phụ thuộc, dự án này kiên định với các chiến lược đi ngược lẽ thường như viết mã chậm rãi, kiểm thử mô phỏng xác định (DST) và zero dependency
Khác với các cơ sở dữ liệu OLTP hiện có phụ thuộc vào kiến trúc một nút, hệ thống này tích hợp sẵn trong thiết kế phân tán theo mặc định, chịu lỗi đồng hồ (cluster time) và chịu lỗi lưu trữ, đồng thời bảo đảm tính đơn giản và khả năng quan sát của việc triển khai nhờ Viewstamped Replication và việc lựa chọn Zig
Áp dụng phương pháp TigerStyle lấy cảm hứng từ Power of Ten của NASA, với việc dùng trung bình hơn 2 assertion cho mỗi hàm, bắt buộc cấp phát bộ nhớ tĩnh, và giữ assertion bật cả trong môi trường production cùng các tiêu chuẩn mã hóa nghiêm ngặt khác
Với cấu trúc phù hợp cho thời đại siêu giao dịch hóa như thanh toán thời gian thực, gaming, tính cước năng lượng, hệ thống này đặt ra chuẩn mực hiệu năng và độ chính xác cho OLTP thế hệ tiếp theo, và nổi lên như một hệ thống xử lý giao dịch thế hệ mới có thể thay thế các cơ sở dữ liệu SQL đã 20–30 năm tuổi

Sự cần thiết của cơ sở dữ liệu lấy ghi nợ/ghi có làm trung tâm

TigerBeetle là một "cơ sở dữ liệu cho giao dịch tài chính" sử dụng ghi nợ (debit) và ghi có (credit) như các primitive cốt lõi
- Bản chất của transaction mà Jim Gray định nghĩa năm 1985 không phải là SQL transaction mà là business transaction (ghi nợ/ghi có)
- 20 năm sau, Gray vẫn định nghĩa xử lý transaction chuẩn là "DebitCredit": thực hiện ghi nợ từ tài khoản ngân hàng, ghi sổ kép, rồi phản hồi cho terminal
- Ghi nợ/ghi có không chỉ dành cho kế toán hay ngân hàng mà là ngôn ngữ chung thể hiện bản chất của giao dịch, và cũng là lý do để cung cấp các đảm bảo như ACID
Vấn đề khi triển khai ghi nợ/ghi có bằng cơ sở dữ liệu SQL truyền thống
- Để xử lý một thao tác ghi nợ/ghi có cần 10–20 truy vấn SQL như đọc số dư tài khoản, khóa hàng, chờ quyết định trong mã ứng dụng, ghi lại giao dịch ghi nợ/ghi có
- Phải giữ khóa hàng trong suốt thời gian mạng round-trip, làm trầm trọng thêm vấn đề hot row khi nhiều giao dịch cùng truy cập một "tài khoản nhà cái"
- Với hàng chục tỷ giao dịch thanh toán tức thời mỗi tháng ở Ấn Độ và Brazil, FedNow tại Mỹ, cùng tính cước thời gian thực trong năng lượng/game/cloud, thế giới đã trở nên định hướng giao dịch hơn ít nhất ba bậc độ lớn trong vòng 10 năm, nhưng các cơ sở dữ liệu SQL đang dùng lại là công nghệ từ 20–30 năm trước
Điểm khác biệt của TigerBeetle
- Thiết kế ghi nợ/ghi có như primitive hạng nhất, cho phép xử lý 8.190 giao dịch trong một round trip bằng một truy vấn 1MiB duy nhất
- Nhà sáng lập Joran gọi đây là một "ý tưởng hiệu năng 1000x" nhưng cũng nói rằng nó "không có gì đặc biệt"
- Thông thường xây cơ sở dữ liệu mất 10 năm, nhưng TigerBeetle đã hoàn thiện trong 3,5 năm và vượt qua kiểm thử Jepsen
- Tháng 6/2025, Kyle Kingsbury đã không thể phá vỡ nền tảng của TigerBeetle dù làm hỏng nhiều vị trí khác nhau trên mọi máy (chỉ tìm thấy 1 lỗi đúng đắn trong engine truy vấn đọc, không ảnh hưởng tới độ bền dữ liệu)

Thiết kế cơ sở dữ liệu hiện đại

Kiến trúc phân tán theo mặc định

Ở thời kỳ Postgres và MySQL ra đời, mô hình một nút là chủ đạo, nhưng trong thời đại phần cứng cloud dùng chung ngày nay, mô hình phân tán mới là dòng chính
- Cơ sở dữ liệu hiện đại cần cung cấp serializability nghiêm ngặt và sao chép transaction giữa các máy để bảo đảm dư thừa, chịu lỗi và tính sẵn sàng cao
- Một số cơ sở dữ liệu OLTP phổ biến nhất hiện nay vẫn phụ thuộc nặng vào kiến trúc một nút, và có trường hợp không tích hợp sẵn tự động failover theo mặc định
Thiết kế phân tán của TigerBeetle
- Được xây dựng để phân tán theo mặc định, chỉ cần cài binary lên số lượng máy mong muốn trong cluster
- Không cần sao chép bất đồng bộ hay Zookeeper; thay vào đó đầu tư triển khai giao thức đồng thuận tiên phong của MIT là Viewstamped Replication
- Giữ zero dependency ngoài toolchain Zig, và tự đầu tư trực tiếp vào mọi phụ thuộc cốt lõi

Chịu lỗi đồng hồ

Với tư cách là cơ sở dữ liệu giao dịch, TigerBeetle coi độ chính xác của timestamp vật lý là quan trọng cho kiểm toán và tuân thủ
- Linux có nhiều loại đồng hồ: CLOCK_MONOTONIC_RAW, CLOCK_MONOTONIC, CLOCK_BOOTTIME
- Do sự không hoàn hảo vật lý của đồng hồ phần cứng, đồng hồ có thể chạy ở tốc độ khác nhau gây lỗi "drift", và tích lũy thành lỗi "skew" trong thời gian ngắn
- Thông thường NTP sửa các lỗi này, nhưng nếu NTP âm thầm ngừng hoạt động do sự cố mạng cục bộ, cluster đồng thuận có tính sẵn sàng cao có thể vận hành trong bóng tối
Cách triển khai cluster time
- Kết hợp đa số đồng hồ trong cluster để tạo thành một đồng hồ chịu lỗi gọi là "cluster time"
- Khi cần có thể căn chỉnh lại thời gian hệ thống của máy chủ, hoặc nếu có quá nhiều đồng hồ lỗi thì dừng an toàn
- Thực sự phát hiện khi Chrony, PTP hoặc NTP ngừng hoạt động và cảnh báo cho operator
- Theo dõi và lấy mẫu thời gian đồng hồ offset giữa các máy chủ, rồi dùng thuật toán Marzullo để ước lượng khoảng thời gian chính xác nhất

Xử lý lỗi lưu trữ

Các giả định của cơ sở dữ liệu truyền thống
- Giả định rằng khi đĩa lỗi thì hệ thống sẽ hỏng theo cách có thể dự đoán được cùng với thông báo lỗi
- Tài liệu SQLite nêu: "SQLite không thêm dự phòng vào file cơ sở dữ liệu để phát hiện hỏng hóc hay lỗi I/O, và giả định rằng dữ liệu được đọc ra hoàn toàn giống với dữ liệu đã ghi trước đó"
Các kịch bản lỗi lưu trữ trong thực tế
- Đĩa có thể âm thầm trả về dữ liệu hỏng, chuyển sai hướng I/O (đường đọc/ghi), hoặc đột ngột chậm đi mà không có mã lỗi — tức gray failure
Khả năng chịu lỗi lưu trữ của TigerBeetle
- Dùng Protocol Aware Recovery để duy trì tính sẵn sàng miễn là không phải mọi bản sao dữ liệu trên tất cả replica đều bị hỏng
- Mọi dữ liệu đều bất biến, và checksum cùng hash chain đem lại đảm bảo mạnh rằng không có hỏng hóc hay giả mạo
- Dùng page cache riêng, ghi dữ liệu xuống đĩa bằng O_DIRECT, chạy trực tiếp trên raw block device (không cần filesystem) để tối thiểu hóa các lớp giữa đĩa và phần mềm
- Dùng LSM Forest tự triển khai (khoảng 20 cây LSM) thay vì LSM có sẵn
- Không chỉ tuyên bố chịu lỗi lưu trữ mà còn là cơ sở dữ liệu phân tán duy nhất được Jepsen xác minh điều đó
- Khi máy cục bộ gặp lỗi, chỉ cần một sector đĩa lỗi là storage engine cũng được nối với consensus toàn cục để tự phục hồi thông qua cluster

Lý do chọn ngôn ngữ lập trình Zig

Ngôn ngữ của các cơ sở dữ liệu truyền thống
- Postgres viết bằng C (thập niên 1970), MySQL bằng C và C++ (1979), MSSQL cũng bằng C và C++
- Ngôn ngữ lập trình đã tiến bộ rất nhiều trong 40 năm qua; nếu xây dựng theo hướng hiện đại thì có thể chọn Rust hoặc Zig
Vì sao TigerBeetle chọn Zig
- Có thể tận dụng toàn bộ hệ sinh thái C, đồng thời có toolchain và compiler rất tốt
- Dễ viết, đặc biệt dễ đọc, đôi khi dễ như TypeScript nhưng nhanh hơn nhiều
- Hỗ trợ cấp phát bộ nhớ tĩnh, một nguyên tắc cốt lõi của TigerBeetle
- Trải nghiệm lập trình viên tốt, học nhanh (vì thế có thể nhanh chóng đi vào mã nguồn TigerBeetle)
- Các thành viên đầu tiên của đội Rust như Matklad (người tạo Rust Analyzer), Brian Anderson (đồng sáng lập Rust cùng Graydon) cũng làm việc tại TigerBeetle
- Trong Rust, không dùng cấp phát bộ nhớ động là "hard mode", còn trong Zig thì việc này dễ hơn

Deterministic Simulation Testing và VOPR

Khái niệm cơ bản của DST

Deterministic Simulation Testing (DST) là kỹ thuật kiểm thử đột phá được đội FoundationDB (nay thuộc Apple) phổ biến
- Được dùng để phát triển cơ sở dữ liệu phân tán an toàn hơn, ít lỗi hơn trong thời gian ngắn hơn trước đây
- Hệ thống phân tán có vô số tổ hợp vấn đề đồng thời: mất gói tin, thứ tự chạy thread không thể đoán trước, v.v.
- Kiểm thử unit và integration truyền thống là không đủ, còn formal verification thì tốn kém và chậm
Cách DST hoạt động
- Một trình mô phỏng chạy có tính xác định gần như mọi kịch bản có thể mà hệ thống đối mặt trên một timeline cụ thể
- Cũng xét đến các yếu tố bên ngoài như hệ điều hành, mạng, sự cố đĩa hay nhiều kiểu độ trễ khác nhau
- Có thể cung cấp lượng kiểm thử tương đương nhiều năm chỉ trong thời gian ngắn (bản thân thời gian là xác định nên có thể chạy vòng lặp while true)
- Đặc biệt phù hợp với cơ sở dữ liệu (nặng về I/O, không nặng về tính toán)
- Kiểm thử Jepsen chỉ là một tập con những gì DST có thể làm

VOPR của TigerBeetle

Tổng quan về VOPR (Viewstamped Operation Replicator)
- Là cluster kiểm thử tự phát triển, lấy tên từ bộ mô phỏng WOPR trong phim WarGames
- Liên tục kiểm thử TigerBeetle trong vô số điều kiện khác nhau, từ cách các nút bầu leader cho đến trạng thái riêng lẻ và lỗi mạng
- Có thể mô phỏng ảo toàn bộ cluster phân tán trong một single thread
Quy mô của VOPR
- Là cluster DST lớn nhất trên Trái Đất, chạy trên 1.000 lõi CPU
- Quy mô lớn đến mức Hetzner phải gửi email riêng để xác nhận liệu họ có thực sự muốn nhiều lõi như vậy hay không
- VOPR-1000 chạy 24x7x365 để bắt được những điều kiện hiếm nhất có thể trước khi vào production
- Trong simulator, thời gian được trừu tượng hóa theo cách xác định và tăng tốc khoảng 700 lần, nhờ đó tích lũy khoảng 2.000 năm runtime mô phỏng mỗi ngày

Gamify DST

TigerBeetle đã biến DST thành một trò chơi, cho phép trải nghiệm nhiều kịch bản lỗi khác nhau thông qua phản ứng của hệ thống
- Có thể chơi tại sim.tigerbeetle.com
- Chạy một instance VOPR thực ngay trong trình duyệt để mô phỏng TigerBeetle
- Được biên dịch sang WebAssembly, và các kỹ sư TigerBeetle đã xây dựng frontend trò chơi để trực quan hóa hệ thống thực

TigerStyle và Power of Ten

Phương pháp TigerStyle

TigerStyle là phương pháp kỹ thuật của TigerBeetle và được công khai trên GitHub
- "một sự trao đổi tập thể đang tiến hóa tại giao điểm giữa kỹ thuật và nghệ thuật, giữa con số và trực giác con người, giữa lý trí và trải nghiệm, giữa nguyên lý bậc nhất và tri thức, giữa độ chính xác và thi ca"
- Tiếp nhận khái niệm "Biodigital Jazz" từ phim Tron: Legacy: sự đan xen giữa con người và yếu tố số, tính hỗn loạn mà vẫn có cấu trúc của "Grid", và tinh thần ứng tác thể hiện tiềm năng con người trong công nghệ
- Trong TigerBeetle, đây là tinh thần đưa không chỉ khoa học mà cả nghệ thuật vào mã nguồn
Ảnh hưởng của TigerStyle
- Đưa ra các nguyên tắc kỹ thuật và mã nguồn bắt nguồn từ Power of Ten của NASA về cách viết mã hoàn hảo
- Bao quát từ các chủ đề như tính đơn giản và sự thanh nhã đến những ứng dụng như cách đặt tên
- Đã bắt đầu ảnh hưởng tới các công ty khác như Resonate và Turso
- Cũng được thảo luận trong podcast Lex Fridman

Cách dùng assertion

Quy tắc 5 của Power of Ten: Assertion
- Khái niệm mã hóa một cách tường minh ngay trong lúc viết kỳ vọng về hành vi của mã (không phải làm sau đó)
- Viết trên một dòng dưới dạng boolean: assert(a > b)
Quy tắc assertion trong TigerStyle
- Assert mọi đối số hàm, giá trị trả về, tiền điều kiện, bất biến; trung bình tối thiểu 2 assertion cho mỗi hàm
- Khi assertion quan trọng và gây ngạc nhiên, dùng assertion thay vì chú thích
- Assert quan hệ giữa các hằng số ở compile time để kiểm tra tính toàn vẹn của thiết kế trước khi chương trình chạy
- Không chỉ assert những điều cần xảy ra mà còn assert cả không gian phủ định — những điều không được kỳ vọng, nơi có thể xuất hiện các lỗi thú vị

Tư duy về hiệu năng

Lý giải và thiết kế về mã quan trọng hơn việc chỉ viết mã
- Thời điểm tốt nhất để giải quyết hiệu năng và giành chiến thắng 1000x là giai đoạn thiết kế, một thời điểm chính xác mà không thể đo hay profile
Các nguyên tắc hiệu năng của TigerStyle
- Thực hiện phép tính nháp cơ bản về "bốn màu cơ bản" (mạng, lưu trữ, bộ nhớ, CPU) và "hai loại kết cấu" (băng thông và độ trễ)
- Đưa ra các mẹo chiến thuật như phân biệt control plane và data plane, xử lý truy cập theo lô, tách hot loop thành các hàm độc lập để giảm phụ thuộc vào compiler

Trải nghiệm trực tiếp

TigerBeetle áp dụng nghiên cứu hiện đại vào một hình thức lâu đời để mang lại hiệu năng và đảm bảo độ ổn định chưa từng có
Là một engine OLTP hiện đại kết hợp mô hình ghi có/ghi nợ native, phân tán theo mặc định, chịu lỗi lưu trữ và đồng hồ, cùng đảm bảo chất lượng dựa trên DST
Phát triển kỹ nghệ hệ thống và lưu trữ như một loại hình nghệ thuật, đồng thời không quên yếu tố vui thú trong quá trình đó
Nhờ cách tận dụng DST đầy thông minh, hệ thống được xây dựng đạt chuẩn Jepsen chỉ trong vài năm ngắn ngủi
Việc cài đặt rất đơn giản với một binary duy nhất, và có thể nhanh chóng bắt đầu trải nghiệm chỉ với lệnh curl thông qua script cài đặt đơn giản trên trang chính thức

6 bình luận

happing94 2025-10-03

Nếu nghĩ về lý do vì sao DB không dùng các nút phân tán, thì có thể hiểu vì sao Postgres là một nút đơn.
Hãy nghĩ xem điều gì quan trọng hơn hiệu năng.

GN⁺ 2025-10-02

Ý kiến trên Hacker News

TigerBeetle rất tuyệt, nhưng cần lưu ý rằng đây là bài viết do một quỹ đầu tư đã rót vốn vào TigerBeetle viết liên kết liên quan
- Trong vài tháng tới tôi sẽ còn tiếp tục viết những bài như thế này, nên hy vọng mọi người sẽ thảo luận sôi nổi hơn; tôi đang tự hỏi liệu có nên thêm một tuyên bố miễn trừ ở đầu bài hay không, vì việc thêm vào cũng không khó
- Bài đó được đăng rất rõ ràng trên trang của quỹ đầu tư dưới nhãn “Portfolio Spotlight”, nên cần điều chỉnh kỳ vọng cho phù hợp
- Tôi sẽ không nhất thiết bàn về cách bài viết được trình bày, nhưng bài do quỹ đầu tư viết thì thực sự rất dễ nhận ra
Tôi là fan của sự theo đuổi tính đúng đắn, các thực hành lập trình và định hướng siêu chuyên biệt của TigerBeetle, nhưng vẫn muốn phê bình một vài điểm trong bài
- Phần giải thích về multi-node hơi dễ gây hiểu nhầm. Dù những người theo cloud-native có nói gì đi nữa, chỉ cần một DB đơn được tuning tốt cùng connection pooler là cũng có thể xử lý QPS cực lớn. Ở công ty cũ, trong lúc bảo trì, do nhầm lẫn mà toàn bộ traffic bị dồn vào một instance MySQL 8 RDS duy nhất, vậy mà vẫn xử lý ổn 80~90K QPS. Instance đó cũng không lớn, chỉ là schema, query và việc tuning ProxySQL/MySQL được làm tốt. Lúc peak, với một writer và hai read replica thì 120K QPS cũng không thành vấn đề
- Nếu dùng NVMe node-local trên server thì rất có thể sẽ chạm trần CPU trước
- Về bài toán dư thừa, nếu là RDBMS được thiết kế phù hợp với môi trường mạng thì cuối cùng đều có failover và hot standby
- Hệ thống consensus của TigerBeetle rất thông minh và không có phụ thuộc bên ngoài, nhưng nó không cố xử lý row lớn. Nếu xử lý hàng nghìn transaction trong một gói 1MiB, thì có thể làm được những điều mà RDBMS truyền thống không thể
- Những phê bình này không nhằm hạ thấp thành tựu của họ, và tôi vẫn rất ấn tượng với sản phẩm này
  - Chỉ ra giới hạn của giao thức đồng thuận mới chính là điểm mấu chốt. TigerBeetle đang cố tách riêng phần công việc chỉ dành cho transaction để xử lý, chứ không phải muốn thay thế mọi OLGP db. Ý đồ là đưa phần dữ liệu quan trọng sang một transaction DB riêng. Cách này cũng có thể thấy tương tự ở TurboPuffer
  - Đúng là RDBMS hiện đại đủ nhanh, nhưng use case của TigerBeetle là môi trường đặc thù có contention cao. Thực tế, họ đã trực tiếp chứng minh trong thử nghiệm rằng khi nhiều transaction cùng chạm vào một account thì throughput của cả cluster giảm mạnh. (tham khảo: bình luận HN liên quan)
Tôi thực sự thích công việc của Joran và đội ngũ về DST, nhận thức hệ thống phân tán và kiểm thử hiệu năng, đặc biệt là sự ám ảnh của họ với việc tối thiểu hóa phụ thuộc (dù cũng có thể xem OS là một dependency)
- Nhưng tôi luôn có cảm giác họ đối xử chưa công bằng với OLTP thông thường (đội ngũ gọi là OLGP). Ví dụ, khi nói về transaction tài chính, họ chỉ đưa ra những SQL transaction hiệu năng thấp như chỉ dùng row lock để so sánh, làm như thể OLTP vẫn đang bám vào cách thiết kế từ 50 năm trước
- Trên trang hiệu năng chính thức, contention chỉ có thể giảm xuống đến 1%. Tôi không nghĩ những nơi như Stripe lại chỉ có 1% contention trong OLTP DB
- Có thể xây dựng những hệ thống dự đoán contention, xử lý nó một cách thanh nhã và đạt throughput transaction cực cao. Những hệ thống như vậy bảo vệ DB khỏi contention để tiếp tục scale. Trên thực tế, thông số throughput của các hệ thống thanh toán quy mô lớn còn cao hơn nhiều so với bảng so sánh hiệu năng chính thức
- Nội dung marketing chủ yếu bỏ qua các điểm này và đối xử như thể mọi developer chỉ đang ném vào những transaction non tay, trong khi thực tế phần lớn là các kỹ sư thông minh hơn nhiều. Trong ngành thanh toán thậm chí còn có cả một vai trò nghề nghiệp gọi là 'payments engineer'
- TigerBeetle rất xuất sắc, nhưng tôi không thoải mái với kiểu marketing dễ khiến người ta hiểu sai về các OLTP khác
  - Cảm ơn lời khen
    - Tôi muốn hỏi liệu bạn có thực sự cho rằng workload OLTP đúng ra nên được xem là 0% contention không. Trên thực tế, khách hàng của chúng tôi đến từ các công ty chứng khoán lớn, công ty quản lý tài sản và sàn giao dịch ở nhiều quốc gia, là những chuyên gia đã làm việc với Postgres hàng chục năm. Các kỹ sư đều hiểu stored procedure các kiểu, nhưng những vấn đề liên quan đến concurrency còn đi sâu hơn xuống tận storage engine. Contention trong OLTP thực sự là vấn đề chí mạng
    - Chúng tôi đã quá mệt mỏi với việc scale ra ngoài DBMS hoặc các bài toán reconciliation system phức tạp, đến mức có cả các Chief Architect lập startup liên quan đến TB vì lý do này
    - Thông điệp chúng tôi muốn nhấn mạnh là để mọi người nhận thức được những vấn đề thực chất như contention và Amdahl’s Law
  - Bạn nói rằng OLTP DB của Stripe không ở mức 1% contention, nhưng Stripe dựa trên MongoDB. So sánh với RDBMS là so táo với cam
  - Về việc có thể xem OS nền tảng là dependency hay không, tôi từng làm với các hệ thống chạy hoàn toàn in-memory và vẫn tồn tại qua cả kexec. Trong những tình huống thậm chí không gọi được syscall thì OS hoàn toàn có thể là một dependency
  - Tôi muốn hỏi liệu bạn có thể đưa ví dụ về tối ưu hóa bằng transaction dựa trên lock so với cách kiểm tra điều kiện ở thời điểm commit hay không
Chúng tôi đã cân nhắc TigerBeetle, nhưng có những rào cản như sau
- Chúng tôi dùng Cloudflare Workers, nhưng ứng dụng client của TigerBeetle không được hỗ trợ. Liên kết issue Có thể Cloudflare Containers sẽ dùng được, nhưng workflow của chúng tôi xoay quanh Workers
- Không có tính năng xác thực (auth). Trên server (như VPS) thì chỉ có thể hạn chế theo IP, nhưng trong môi trường serverless thì không có IP cố định issue liên quan
  - Xác thực IP bằng khóa ECC thông qua Wireguard cũng có thể là một giải pháp
  - Thực tế, trong môi trường Cloudflare Workers hay AWS Lambda, nếu 1000 worker cùng mở kết nối tới DB thì sẽ phát sinh vấn đề. Vì vậy thường người ta giải quyết bằng cách đặt một proxy hoặc một lớp dịch vụ phía trước DB. Proxy biết cách truy cập DB, nên trong mạng riêng không phải lo vấn đề auth
  - Nếu trao đổi với đội giải pháp của TigerBeetle, bạn có thể nhận được đề xuất về các giải pháp tùy chỉnh như xác thực ở mức logic thông qua mã hóa end-to-end
  - Thật khó tin là đến năm 2025 vẫn có DB không có tính năng xác thực. Nếu là DB tài chính thì chí ít cũng nên có hướng dẫn trên trang chủ về cách thêm proxy/layer xác thực tối thiểu. Nếu không dùng HTTP (điều này không rõ chỉ qua tài liệu), thì ai cũng sẽ thắc mắc phải gắn proxy xác thực như thế nào khi không có HTTP. Để nguyên trạng như vậy mà phơi ra internet thì cực kỳ nguy hiểm
Có câu hỏi rằng: “Trong 10 năm, lượng transaction đã tăng hơn 1000 lần, còn DB đang dùng lại là SQL 20-30 năm tuổi. Liệu có chịu nổi không?” Theo tôi là hoàn toàn có thể.
- Dù là phần mềm 30 năm tuổi thì nó vẫn liên tục được cập nhật, và nền tảng khi đó vốn đã được thiết kế rất vững chắc
  - Tôi là Joran (TigerBeetle). Với workload thông thường thì không vấn đề gì, nhưng trong xử lý transaction thì row lock của SQL gặp vấn đề do contention theo power law (tham khảo Amdahl's Law). Chúng tôi đã đưa lên trang chủ một contention calculator để tính giới hạn hiệu năng tối đa về mặt lý thuyết, bạn có thể xem tại đây contetion calculator
  - Ngay cả DNS cũng được công bố từ năm 1983 mà đến giờ vẫn là nền tảng của internet, điều đó cho thấy nếu nền móng đủ tốt thì một hệ thống hơn 30 năm tuổi vẫn hoàn toàn có thể trụ vững. SQL là quá đủ tốt cho phần lớn workload
  - Không phải lúc nào công nghệ mới và hào nhoáng cũng tốt hơn công nghệ cũ đã được dùng qua mọi kiểu và kiểm chứng kỹ càng. Có những lúc tôi cảm thấy kỹ sư phần mềm là những kỹ sư “kém trí nhớ” nhất trong ngành
  - Khi xử lý hàng chục DB trong một hệ thống phân tán thì transaction phân tán (như Sagas) là bắt buộc. Còn trong bối cảnh máy đơn thì relational DB vẫn rất tuyệt vời
  - Trên phần cứng ngày xưa thì hiệu năng còn thiếu, nhưng giờ công nghệ đã tiến bộ nên ngược lại chạy còn nhanh và tốt hơn
FoundationDB cũng có khá nhiều điểm chung với thảo luận về TigerBeetle
- Viết code chậm, DST, không phụ thuộc, mặc định là môi trường phân tán trong production, dùng optimistic locking để chấp nhận sai số đồng hồ, kiểm thử khắc nghiệt kiểu Jepsen, thử nghiệm bằng ngôn ngữ mới (Flow), v.v. Với FDB cũng có thể giải quyết gần như cùng các bài toán, còn TigerBeetle có lẽ được tối ưu hơn cho use case của mình
- Lý do duy nhất khiến FDB không phổ biến là thiếu các layer được làm tốt. Tuy vậy hiện cũng có một vài người đang tự phát triển các layer SQS, DynamoDB và SQLite
  - Lý do thực sự khiến FDB không phổ biến là Apple. Sản phẩm ra mắt năm 2013, hay đến mức họ mua luôn công ty, rồi toàn bộ người dùng hiện hữu đều bị ngừng dịch vụ. Ngay cả sau khi thời hạn độc quyền kết thúc thì niềm tin cũng không phục hồi
  - Tôi đang cộng tác với đội FDB và cũng đang chuẩn bị một bài viết về DST
  - Tôi cũng tò mò không biết sau thương vụ mua lại thì mọi chuyện đã diễn ra thế nào
  - Tôi thực sự nghĩ đó là 'the one true database'
  - Tôi tự hỏi “vì sao mọi hyperscaler không dùng FDB”, rồi tìm trên github thì hóa ra cuối cùng nó lại nằm dưới trướng Apple
Gần đây tôi đã thử áp dụng phong cách phát triển của TigerBeetle vào Rust, Go, v.v. và thực sự muốn khuyên dùng mạnh mẽ
- Một điểm vào duy nhất, phụ thuộc gần như bằng 0
- CI cục bộ, chạy test/coverage/lint bằng một lệnh duy nhất
- Khiến tôi hứng thú với việc đưa mô phỏng vào qua property/snapshot/swarm test
- Phân biệt nhanh/chậm, mọi test đều dùng seed để deterministic
- Upper bound tường minh + vận hành resource pool, ngay cả cấp phát động cũng khiến code dễ hiểu hơn
- Đó là nhờ các video và tài liệu của đội TB
  - Thật vui khi TigerStyle thực sự giúp ích, cảm ơn phản hồi của bạn
Việc “bật assertion trong production” làm tôi rất ấn tượng
- Tôi chưa bao giờ hiểu vì sao lại tắt assertion. Nếu assert thất bại trong môi trường vận hành thì phải biết ngay chứ (nói theo kiểu tu từ)
  - Về mặt lịch sử, tắt assertion từng giúp cải thiện hiệu năng. Nhưng ngày nay thêm vài phép so sánh nữa cũng không tạo khác biệt lớn
  - Ban đầu assertion là các kiểm tra nhằm ngăn việc developer dùng sai API. Ở giai đoạn xử lý input người dùng, hợp lý hơn là chuyển sang logic nghiệp vụ với thông báo lỗi tử tế
  - Có lúc tôi muốn dùng assertion cho cả những thứ không dễ kiểm tra. Ví dụ như xác nhận rằng một danh sách đang được sắp xếp
  - Mục đích gốc của assertion là kiểm tra lúc compile/test. Nếu muốn dùng trong prod thì có thể đổi thành câu lệnh if. Cần nghĩ xem assert có chỉ là cú pháp đường cho tiện hay không
Tôi muốn đội TB quảng bá rộng hơn mô hình double-entry cho các kịch bản ngoài tài chính. Nó cũng rất hữu ích cho cổ phiếu, vé biểu diễn, v.v. API giờ đã được cải thiện xong xuôi, nên đã đến lúc nói nhiều hơn về cách ứng dụng
- Tôi là nhà phân tích, dùng SQL nhiều nhưng không phải người viết code. Nhìn chung tôi hiểu phần giải thích tổng quan và lợi ích hiệu năng. Tôi có vài thắc mắc a) Cấu trúc dữ liệu của TigerBeetle thực tế trông như thế nào? Có lẽ không phải dạng bảng thông thường b) Nếu không dùng được SQL query thì sẽ sử dụng nó như thế nào c) Nếu áp dụng mô hình double-entry cho cổ phiếu, vé, v.v. thì sẽ ra sao? Ví dụ một địa điểm biểu diễn đang giữ 1000 vé, khi bán một vé thì ghi nhận từ tồn kho sang tiền mặt, từ doanh thu chưa thực hiện sang nghĩa vụ phải thực hiện? Hay trước khi bán vé thì chưa có entry nào cả?
- Trong Postgres cũng có thể triển khai double-entry tương tự
Câu nói “đa số đội ngũ viết code thật nhanh, xem test như cực hình và chồng chất phụ thuộc” thực ra là tiêu chuẩn từ 25 năm trước. Trước khi Google và Facebook đưa văn hóa “move fast and break things” vào, mọi người đều làm chậm mà chắc, kiểm thử cẩn thận rồi mới phát triển. Tôi hy vọng TigerBeetle sẽ được công nhận nhiều hơn. Báo cáo Jepsen cũng rất đáng đọc Jepsen report
- Hãy đợi 25 năm nữa xem TigerBeetle có trở thành Google hay không, hay một sản phẩm chậm nhưng hoàn hảo sẽ bị đối thủ nhanh hơn nuốt chửng
- “Move fast and break things” là khẩu hiệu của Facebook. Google thì ngược lại, từng rất ám ảnh với kiểm thử. Dĩ nhiên cũng phải đáp ứng đúng các yêu cầu thực sự tồn tại, và kỹ sư đôi khi tạo ra quá nhiều yêu cầu giả định dẫn đến kém hiệu quả. Đưa sản phẩm đến tay người dùng thật nhanh và nhận phản hồi để phản ánh lại vẫn có giá trị hơn rất nhiều so với việc mài giũa sản phẩm vô hạn trong một “bong bóng”

onestone 2025-10-02

Ngoài nội dung của bài viết trên, bản thân website của TigerBeetle cũng khá ấn tượng.

Nó tạo cảm giác như thứ gì đó cực kỳ nhanh, và thiết kế cho thấy họ đang cố gắng diễn giải mọi thứ theo cách vui nhộn thay vì bằng kỹ thuật nặng nề, nên tôi thấy khá thú vị.

Liên kết: https://tigerbeetle.com