ハクソク

世界を動かす技術を、日本語で。

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

236日前原文(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に拡張を加えれば、いろんなユースケースに役立つと思うんだけど。編集：ああ、もっとキー・バリュー型ストアに近いんだね。

└

彼らはAppleに買収されたと思ってたけど、その後どうなったの？

└

FDBが大人気じゃない唯一の理由は Apple だよ。彼らは2013年にリリースされた製品が気に入って、会社ごと買っちゃったから、他のFoundationDBユーザーは見捨てられて、使えなくなったんだ。いつでも引き抜かれる可能性のあるデータベースを誰が信頼する？確かに多くの製品にはこんなライセンス条件があるけど、こんなに急に中止されたのはほんの数例だよ。今はApacheライセンスの下だけど、信頼は戻ってこないね。

TigerBeetleを検討してたけど、いくつかのブロッカーがあったよ。* Cloudflare Workersを使ってるんだけど、TigerBeetleのクライアントアプリはサポートされてない。Cloudflare Containersを使えば動くかもしれないけど、Cloudflareを使う理由はWorkersのためなんだ。 --> https://github.com/tigerbeetle/tigerbeetle/issues/3177 * TigerBeetleは認証をサポートしてない。つまり、サーバー（例えばVPS）はIPで制限しなきゃいけない。問題は、サーバーレスには固定IPがないことだ。 --> https://github.com/tigerbeetle/tigerbeetle/issues/3073

└

でも、Cloudflare WorkersやAWS Lambdaの設定って、どんなDBでもうまくいかないよね？* 1000のワーカーがDBに接続を開くのは無理だし、* DBの前にサービスやプロキシを置けば解決できるし、* プロキシはDBにアクセスする方法を知ってるから、プライベートネットワークにして認証なんて気にしなくてもいいんじゃない？

└

え、待って？2025年のデータベースが認証の仕組みをサポートしてないの？金融データベースで？マジで？みんな、せめて認証プロキシや認証レイヤーを追加するためのガイドをサイトに載せるくらいはしてよ。特にHTTPを使ってないなら（ドキュメントからは簡単にはわからないと思うけど）、みんな「どうやってHTTPなしで認証プロキシを追加するんだ？」って悩むことになるし、結局オープンなインターネットに置くことになっちゃうよ…

└

認証などを論理レベルでエンドツーエンド暗号化で解決できるソリューションチームと話してみるといいよ。これは通常、私たちが顧客のためにやっていることなんだ。

彼らは本番環境でアサーションを有効にしてる。なんでそれをオフにするのか、ずっと理解できなかった。プロダクションでアサーションが失敗するのは、絶対に知りたいアサーションなんだ。（その「理解できなかった」は修辞的なものね）。

└

確認が難しいアサーションを書くのが好きなんだ。例えば、リストがソートされてるかどうかを確認するとか。

└

理論上は、アサーションは開発者がAPIを誤用しないようにするためのチェックだからね。ユーザー入力の場合は価値があるけど、その段階では、適切なエラーメッセージをエンドユーザーに返すようなビジネスロジックに変える方がいいと思う。

└

アサーションの存在意義は、コンパイル時やテスト時のチェックだからね。もし本番環境で実行したいなら、アサーションなんて使わずにif文を使うでしょ。じゃあ、アサーションって君にとって何なの？if文のちょっと便利な糖衣構文の代替品？

└

歴史的なことだけど、アサーションをオフにするとコードが速く動くんだよね。でも今は、コンパイラがどっちに行くかヒントを出せるなら、余計な比較なんて大したことじゃないよね。

TigerBeetleの正確性やコーディングプラクティスに対する姿勢、そして超専門化を目指す姿勢には賛同しているけど、投稿にはいくつかの批判があるんだ。マルチノードについての段落はちょっと誤解を招くと思う。クラウドネイティブの人たちが言うこととは逆に、しっかり調整された単一の強力なDBとコネクションプーラーがあれば、驚くほどのQPSを処理できるんだよ。前の職場では、メンテナンス期間中に、すべてのトラフィックが単一のMySQL 8 RDSインスタンスに向けられてしまったことがあったんだけど、その時は80-90K QPSくらいで、全然問題なかった。しかも、巨大なインスタンスじゃなくて、r6i.12xlargeだったし、ちゃんとしたスキーマと、まあまあのクエリ、ProxySQLとMySQLの良い調整があったからね。ピーク時には、そのライターと二つの.8xlargeのリードレプリカで120K QPSを難なく処理してたよ。ノードローカルのNVMeがあるサーバーにホストされたDBは、I/O能力が飽和する前にCPUの限界に達する可能性が高いよ。冗長性のために、ネットワーク活動用に設計されたすべてのRDBMSには、何らかのフェイルオーバーやホットスタンバイの機能があるんだ。もう一つの軽い批判は、TigerBeetleのコンセンサスに関する議論について。確かに賢いと思うし、他に依存関係もないけど、大きな行を扱うことには挑戦していないんだよね。8,190のトランザクションを1 MiBのパケットに収めて、一度の配信で済むなら、従来のRDBMSでは不可能なことも管理できるだろう。このことは彼らの成果を軽視するものではないし、彼らの製品には本当に感心しているよ。

└

伝統的なモダンRDBMSがすごく速いってのは、タイガービートルのユースケースにはあんまり役立たないんだよね。高い競合があるワークロードを含むから。そういう負荷の下では、最近のカンファレンスでのテストでもわかるように、たくさんのトランザクションが一つのアカウントに影響を与えるクラスターではスループットが劇的に落ちるんだ。編集: 直接の情報がいいよね。https://news.ycombinator.com/item?id=45437046

Joranと彼のチームがDSTや分散システムの認識、パフォーマンスプラクティスに関してやっている仕事が本当に好きだよ。特に依存関係がないというクレイジーなところが好き。だけど、彼らが普通のOLTP（彼らはOLGPと呼んでいる）を扱う方法には不公平感を感じているんだ。例えば、金融ワークロードのために明らかにサブ最適なインタラクティブSQLトランザクションを使った比較、コミット時に条件チェックを使わずに行をロックするようなことをするのは、「OLTPが設計された50年くらい前に意図された使い方だから」って。彼らが引用しているhttps://tigerbeetle.com/#performanceでは、スライダーの最小値は1%の競合なんだ。StripeがOLTP DBで1%の競合を持っていると思う？絶対に違うよ。競合を「期待する」システムを構築できて、非常に高いスループットで優雅にそれを扱うことができるんだ。これらのシステムはDBを競合から守るから、スケールし続けることができる。これらのシステムで働いている人たちと話していると、StripeのようなDBや他のシステムのトランザクショナル（金融）スループットの種類を大体知っているんだけど、彼らのパフォーマンス比較ページが提案しているよりも、はるかに多くのゼロがついているんだ。彼らのマーケティングはこの事実をほとんど無視していて、みんながジュニアエンジニアが設計したインタラクティブトランザクションでDBを叩いているかのように扱っている。ほとんどの開発者は（そう願いたいけど）そんなことはないと思うよ、特に決済会社で働いているならね。「ペイメントエンジニア」というタイトルも、競合や正確性を考える人のためにあるんだから。TigerBeetleは素晴らしいけど、他のOLTPについて誤解を招くようなパターンが気になるな。

└

StripeがOLTP DBで1%の競合を持っていると思う？絶対に違うよ。StripeはMongoDBの上で動いているけど、それ自体が恐ろしいことだし、いずれにせよ、RDBMSを運営している店と比較するのはリンゴとオレンジみたいなもんだね。

タイガービートルの分散ストーリーについてちょっと混乱してる。ここにあるドキュメントにはこう書いてあるんだよね: 「TigerBeetleは設計上、単一コアを使用し、イベントを処理するために単一のリーダーノードを使います。ノードを追加することで信頼性は上がるけど、スループットは増えません。」これってマルチリージョンだとどうなるの？つまり、ユーザーがどこにいても、書き込みをするためにはリーダーノードにリクエストしなきゃいけないってこと？分散は単なる冗長性のためなの？

└

私の理解では、そうだね。レイテンシーはリーダーノードに行って、十分なフォロワーにレプリケーションすることで決まるんだ。CAP定理によれば、強い整合性を求めるなら、彼らが提供する方法では、ノードの過半数と話さなきゃいけないんだよね、たしかN/2 + 1だったかな。PaxosやRaftもそんな感じ。どうやらそれに関するゲームもあるみたいだよ。https://tigerbeetle.com/blog/2023-07-11-we-put-a-distributed...

タイガービートルは素晴らしいけど、このアーティクルはタイガービートルに投資している投資会社が書いたものだってことを忘れないでね。https://www.amplifypartners.com/blog-posts/our-investment-in...

最近、タイガービートルスタイルの原則や提案をたくさん取り入れてるんだけど、主にRustとGoでね。もうめちゃくちゃおすすめだよ。 - 単一のエントリーポイント、ほぼゼロの依存関係 - ローカルでCIしてテスト、テスト、カバレッジ、リンティングを一つのコマンドで実行 - プロパティ/スナップショット/スワームテスト、シミュレーションを書くのが楽しくて、アサーションがクラッシュするのも好き - 高速/低速の分割 + すべてがシードで決定的 - 明示的な上限 + リソースプール。動的に割り当てることもあるけど、コードがシンプルに理解しやすくなるんだ。TBチームが最近出してる動画やドキュメントに感謝！

タイガービートルのやり方はすごく興味深いけど、マルチコア処理のサポートがない（または水平スケーリングのどちらも）ってのは、実際のデプロイメントにおいてはブロッカーだと思う。スケーラビリティにはハードリミットがあって、今は高いように見えても、限界に達したらどうすればいいの？金融データベースは、少なくとも15〜20年の成長を見越して計画しなきゃいけないからね。