TigerBeetleは非常に興味深いデータベースです

2025年10月1日原文(amplifypartners.com)

概要

TigerBeetle は、他のデータベースと一線を画す独自設計
金融トランザクション に特化し、デビット/クレジットを第一級プリミティブとして採用
分散構成とゼロ依存性、静的メモリ割当てなど、徹底した堅牢性追求
Zig言語 や独自の検証・テスト手法を活用し、短期間で高信頼性を実現
ストレージ障害や時計誤差 にも対応、次世代のトランザクション処理を牽引

TigerBeetle: 世界で最もユニークなデータベース

TigerBeetle は、従来とは真逆のアプローチで設計・開発
- コードは「 ゆっくり・慎重に」書く方針
- テスト を最重要視し、「決定論的シミュレーションテスト（DST）」を全面採用
- ゼロ依存性 の設計（Zigツールチェーンのみ）
静的メモリ割当て、 本番環境でもアサーション有効化、Viewstamped Replication採用、Zig言語選択など、徹底した独自路線

デビット＆クレジット思考の重要性

TigerBeetleは「 金融トランザクション専用データベース」を標榜
- プリミティブは デビット/クレジット、会計の基本単位
Jim Gray（Turing賞受賞者）の論文に基づく設計思想
- トランザクション処理の本質は「 現実世界のビジネストランザクション」
- ACID保証の原点もここにある
従来のSQLデータベースではデビット/クレジット処理が非効率
- 1トランザクションごとに10〜20回のSQLクエリ、ロック、ネットワーク往復が必要
- ホットロウ問題やリアルタイム性の要求に対応困難
TigerBeetleは 1MiBクエリで8190件のデビット/クレジット を1往復で処理
- 「1000倍パフォーマンス」アイデア
Jepsenテスト（Kyle Kingsbury）にも耐えた高信頼性

真のモダンデータベース設計

分散構成を前提とした設計

TigerBeetleは 分散をデフォルト としたアーキテクチャ
- どのノードも単純にバイナリをインストールするだけでクラスタ参加可能
- 非同期レプリケーションやZookeeper不要
MIT発の Viewstamped Replication プロトコルを採用
- 高可用性・厳密な直列化保証
- ゼロ依存性を実現

クロック障害耐性

物理クロックの精度・同期問題も考慮
- Linuxの複数クロック（CLOCK_MONOTONIC_RAW等）を適切に選択
- クラスタ内の大多数のクロックを組み合わせて「 クラスタタイム」を生成
- Marzulloアルゴリズムによる最適な時刻区間推定
- クロック障害やNTP停止を検出・警告可能

ストレージ障害への対応

Protocol Aware Recovery で全レプリカのデータ破損時以外は可用性維持
全データは イミュータブル・チェックサム・ハッシュチェーン で改ざん検知
カスタムページキャッシュ、O_DIRECTによるダイレクトI/O、ファイルシステム非依存
独自実装の LSM Forest （20本以上のLSMツリー）
Jepsenによるストレージ障害検証・合格実績

Zig言語の採用理由

TigerBeetleは 100% Zig言語 で実装
- CやC++ベースの従来DBMS（Postgres, MySQL, MSSQL等）と一線を画す
- 静的メモリ割当て、ゼロ依存性、パフォーマンスチューニングの自由度
- 新しい言語機能と安全性を活かした設計

TigerBeetleを支える技術と思想

決定論的シミュレーションテスト（DST） による完全自動検証
- VOPRクラスターでの徹底的な障害シミュレーション
TigerStyle ：本番でもアサーションを有効化し、バグを即時検知
静的メモリ割当て・ゼロ依存性で 予測可能性と堅牢性 を最大化

まとめ

TigerBeetleは 徹底した独自路線 と 最新研究の実装 で、次世代の金融トランザクション基盤を構築
分散・高可用性・ストレージ障害耐性・ゼロ依存性・新言語活用など、 現代の要請に応える設計
3.5年という短期間で Jepsen合格・本番運用可能 な堅牢性を実現

Hackerたちの意見

10年も経たないうちに、世界は少なくとも3桁以上トランザクショナルになったよね。でも、今でも使ってるSQLデータベースは20〜30年前のものなんだ。これが持つのかな？うーん、持つよ。実際、そんなに大変じゃないし。何かが約30年前に始まったからって、時代に合わせて更新されてないわけじゃないし、悪い基盤の上に作られたわけでもないからね。

└

反対だね。N個の異なるデータベースがある分散システムについて話してるなら、分散トランザクションは読者の課題として残される（だからSagasみたいなものがあるんだ）。一台のマシン内では、そう、リレーショナルDBはまだまだバッチリ動くよ。

└

その通り。古いデータベースは、今のハードウェアよりもずっと性能が低いものでもちゃんと動くよ。

└

TigerBeetleのJoranだ！一般的なワークロードにはあまり手間がかからないけど、トランザクション処理はパワーローの競合があって、SQLの行ロックを殺しちゃうんだ（Amdahlの法則参照）。理論上の最良ケースの限界を示す競合計算機をホームページに載せてるけど、思ったよりも低いよ：https://tigerbeetle.com/#general-purpose-databases-have-an-o...

└

DNSは今でも健在で、1983年11月にリリースされたんだよね。今もインターネットのほとんどを支えてるし、ほとんどの場合、SQLは90%のワークロードには十分だよ。

└

新しいキラキラしたものが、確立された、時が試された退屈な技術よりも常に良いって言ってるの？時々、ソフトウェアエンジニアは他のエンジニアの中で最悪の記憶を持っている気がする。

└

そうだね、SQLが問題じゃない。少なくともほとんどは。リレーショナルモデルは、Coddが言った通り、柔軟で強力なモデルであることを証明してきたし、SQLの比較的劣化した形でもそうなんだ。実際、ストレージを抽象化する普遍的で柔軟なデータモデルとしての可能性は、まだ完全には解放されていない。既存のSQLデータベースについては、確かに多くはもはや真実ではないメモリや二次ストレージの性質に関する基本的な仮定に基づいて構築されている。私たちの業界の多くの人は、まだ回転する磁気ディスクの過去の世界に頭を突っ込んでいる。現実のハードウェアは進化しているし、10-15年前よりも一般的に利用可能なIOPSは数桁高い。だから、CedarDBや他の製品（その前のUmbraなど）にワクワクしているんだ。SQLを捨てることが「パフォーマンス」のレシピではないし、ストレージシステムとデータモデルを分離することの教訓は、1960年代から重要なんだ。TigerBeetleのような専門的なトランザクション/レジャーシステムが特定の業界やドメインで最適化戦略としての役割を果たすことは認めるけど、これをリレーショナルモデルやデータストレージ全般に関する一般的な問題として捉えるのは間違いだよ。

これらはFoundationDBにも当てはまるよ。 - コードを書くのが遅い。 - DST - 依存関係なし - プロダクションではデフォルトで分散 - 楽観的ロックによる時計の耐障害性 - JepsenはFDBのテストが彼らができるよりも厳格だって言ってた。 - テスト用の新しいプログラミング言語、Flow。多分、FDBでも同じ問題を解決できると思うけど、TigerBeetleはそのユースケースにもっと最適化されてるんじゃないかな（そうであってほしい...）。私の知る限りでは、FDBが大人気じゃない理由は、誰もその上に良いレイヤーを書こうとしないからだと思う。SQSやDynamoDB、SQLiteのレイヤーを書いてる人たちが何人かいるのは知ってるよ。

└

今、彼らのチームと一緒にDSTについての投稿を作ってるところだよ、ハハ！

└

唯一無二のデータベース

└

確かに、FDBが大人気じゃないのは、誰もその上に良いレイヤーを書こうとしないからだと思う。SQSやDynamoDB、SQLiteのレイヤーを書いてる人が何人かいるのは知ってる。コメントを書き始めたんだけど: > 面白そうだけど、これが何のためかを考えると、ハイパースケーラーたちはなんで使ってないんだろう？書いてるうちにFoundationDBを探して、これを見つけた: > https://github.com/>/foundationdb ああ、なるほどね :-p

└

もっと真面目なコメントを、下のくだらないのと分けるために：SQLクライアントなしでリリースしたのは面白いね、互換性を持たせる方法はないのかな？SQLに拡張を加えれば、いろんなユースケースに役立つと思うんだけど。編集：ああ、もっとキー・バリュー型ストアに近いんだね。

Hacker Newsで議論の続きを見る

ハクソク