AI 向けをうたう新しいデータベースは、機能の多さや性能の数字ばかりが先に目立ちやすいです。ですが、実際に大事なのは「壊れたときに何が起きるか」「並行アクセスでどこまで壊れないか」です。今回の Jepsen の報告は、ParticleDB が掲げていた “Full ACID” という主張を、かなり厳しい現実の側から点検したものです。しかも問題は理論上の細かな穴ではなく、書き込み消失やクラッシュ、奇妙な表示崩れまで含んでいました。
Jepsen は ParticleDB の 1.1.4 から 1.1.18.11.rc-22 までを調べ、単一サーバー構成の挙動に絞って検証した。レプリケーション機能はエンタープライズ向けのクラウドでしか使えず、今回のビルドでは対象外だったためだ。結果として、ParticleDB が「Full ACID」とうたうには時期尚早だと結論づけている。報告書では 96 個の問題が列挙され、内容はクラッシュ、deadlock、データ消失のような分かりやすい障害から、より妙なものまで広がっている。たとえば、部分的に見えない行が削除できなくなったり、WHERE 4 = 5 のような条件が妙な振る舞いをしたり、削除したはずのテーブルが歪んだ形で再登場したり、列が混乱したり、文字列が整数に変わったりする。多くは、サーバー1台、クライアント1つ、故障注入なしでも起きたという。
検証は、Jepsen のテスト基盤を使って Debian 13 の単体ノード上で実施され、コンテナと EC2 VM の両方で試された。プロセスを強制終了してクラッシュを起こしたり、LazyFS を使って fsync 前の書き込みを失わせたり、ディスクファイルを切り詰めたり破損させたりもしている。さらに、WAL（Write-Ahead Log）の同期方法として sync、groupsync、nosync を切り替え、--txn-mode も各種試した。ところが、ドキュメントはこのあたりの説明がかなり不安定だった。ある場所では occ がデフォルトで「safe under concurrency」とされ、別の場所では table-2pl や serializable が最強の設定として説明される。fast、occ、zero-copy-occ、table-2pl などのモードは用意されていたが、何をどこまで保証するのかが文書だけではつかみにくい。
Jepsen はさらに、ParticleDB の Java SDK が案内されていたにもかかわらず、実際には JAR もソースも見つからなかったため、まず PostgreSQL JDBC を使い、その後で ParticleDB の Java SDK 1.0.0〜1.0.2 にも対応した。ワークロードは、整数の読み書きをする rw、リストへの追加を行う append、内部整合性を試す internal、そして ParticleDB と PostgreSQL の挙動差を直接比べる compare などで構成された。compare は単純な SQL 断片だけを使う生成テストだったが、これが意外なほど多くの不整合をあぶり出したという。後半では、より複雑なトランザクションでの内部不整合を探る hybrid internal-sim まで作られている。本文の中では、オリジナルのドキュメント同士で default 設定が食い違っていたこと、最終的に 1.1.18.11.rc-22 では 96 個のうち 10 件を除いて解消されたこと、しかし occ の通常運用でコミット済み書き込みを失う問題や、serializable でも内部異常や Lost Update が残ったことが明記されている。さらに Orkes はその後 1.1.19-rc.13 を出し、残る問題をすべて直したと主張している。
この報告で一番引っかかるのは、単にバグが多かったことではなく、製品の説明と実体がかなり離れて見える点だと思う。Full ACID、safe under concurrency、Jepsen-safe、strongest setting といった言葉は、どれも利用者に安心感を与える。ところが、実際にはその言葉の定義が文書内で揺れていて、どのモードがどの保証を持つのかすら読み取りづらい。これは技術的な失敗というより、説明責任の失敗に近い。データベースは「大丈夫そう」では通らない。壊れたときにどう壊れるかが重要だからだ。
私が気になったのは、こうした曖昧さが単なるドキュメントの不備で済まないことだ。運用者は、保証内容が分からなければ本番投入をためらうし、逆に誤解したまま採用すれば事故の責任だけが残る。特に ParticleDB は AI ワークロード向けを掲げ、SQL、key-value、vector search、analytics まで一体で扱う野心的な製品だった。だからこそ、機能が多いぶんだけ「どこまで安全か」を明確にしないと、期待だけが先に膨らむ。性能が速いという宣伝は強いが、今回のように安全性の根拠が弱いと、長く使うほど不信感が積み上がるはずだと思う。
Jepsen の報告は、数のインパクトも大きい。96 件という数字だけを見ると、かなり大規模な不良品のように聞こえる。けれど、もっと重要なのは、その多くがクラッシュ耐性のような特別な状況ではなく、単一ノードで普通に動かしただけでも出てきたことだ。しかも compare のように PostgreSQL と振る舞いを比べる単純な方法や、rw のような基本的な読み書きのワークロードが、問題の切れ味を増している。これは「高度な異常検出が必要だった」というより、「基礎動作の整合性がかなり危うかった」ことを示しているように見える。
ここで面白いのは、Jepsen が派手な障害注入だけでなく、かなり地味な比較実験で成果を出している点だ。データベースは大規模障害時の話ばかり注目されがちだが、実際の事故はもっと日常的なズレから始まることが多い。読み取った値が直前の書き込みと合わない、削除したはずの行が残る、条件式がおかしい。こうした小さなほころびは、アプリケーション層では見逃されやすい。Jepsen の価値は、そこを機械的に追い詰めていくところにあると思う。ParticleDB のように新しく、しかも宣伝文句が強い製品ほど、この手の検証で現実を突きつけられる。
ParticleDB は AI 向けの多機能データベースとして作られた。そこには、単なる RDBMS ではなく、ワークフロー基盤やベクトル検索、分析、UDF まで一体化したいという意図がある。発想自体はよく分かる。AI 系のシステムは、状態があちこちに散らばりやすいからだ。だが、だからこそ土台のデータベースには、むしろ古典的な厳しさが必要になる。速さや機能の多さだけでは足りない。ACID のどこが本当に守られているのか、どのモードが何を犠牲にするのか、例外時に何が起こるのかを、最初からかなり丁寧に説明しないといけない。
今回の報告は、AI 向けという看板が品質保証の免罪符にはならないことを示しているように見える。むしろ逆で、AI システムは誤った結果を平然と積み上げることがあるぶん、下の層でデータが狂ってはいけない。オーケストレーション基盤を手がける Orkes が自前の DB に進んだ経緯も理解できるが、自前実装に踏み切るなら、その分だけ説明と検証の責任も重くなる。今回 Jepsen がそこを丁寧に暴いたのは、製品を叩くためというより、利用者が誤解しないための作業だったと受け取っている。
報告の最後で印象的なのは、1.1.18.11.rc-22 までに 10 件を残して大半が直り、さらに 1.1.19-rc.13 で残りも直したと Orkes が述べている点だ。ここには、壊れていた製品が少しずつ改善されている気配がある。これは素直に評価してよいと思う。ただし、その評価は「直ったらしい」ではなく、「外部から再現して確認できる形で直った」と言えるところまで行って初めて意味を持つ。データベースは一度信頼を落とすと戻すのが難しい。だから、修正そのものより、修正の説明が追えることが重要だ。
私がこの件で感じたのは、強い宣伝と強い検証はセットでないといけない、ということだ。大胆な性能主張をするなら、同じくらい大胆に整合性の説明もしなければならない。今回のような Jepsen の報告が出たあとで本当に信頼を回復したいなら、バージョン番号の更新だけでは足りない。どのモードで何が保証され、どこまでが未定義なのかを、読み手が迷わない形で書き直す必要があるはずだと思う。
