Show HN: SirixDB 1.0 Beta – Git風バージョン管理、差分、タイムトラベルクエリ

HNの皆さん、こんにちは！SirixDBについては、2019年（https://news.ycombinator.com/item?id=19834681）と2023年（https://news.ycombinator.com/item?id=38252963）にも投稿しました。 SirixDBの核となるアイデアは、履歴がファーストクラス市民であるということです。各コミットは軽量でクエリ可能なリビジョンを格納します。任意の時点、さらには個々のノード（例えばJSON値）をクエリしたり、任意の2つのリビジョンを比較したり、イベントを再生することなくデータの進化を効率的に追跡したりできます。 従来のイベントストアとは異なり、過去の状態をイベントを再生して再構築する必要も、プロジェクションについて考える必要もありません。リビジョンは直接クエリ可能です。 簡単な例です。 1月1日: "価格 = 100ドル、1月1日から有効"を記録。1月1日（トランザクション時間）に格納。 1月20日: 1月1日の価格が実際には95ドルだったことを発見。修正をコミット。 修正後、両方の軸で質問できます。 - "1月16日時点での価格をどう考えていたか？" -> 100ドル（トランザクション時間） - "1月1日時点での実際の価格はいくらだったか？" -> 95ドル（有効時間） 私は2013年からこのプロジェクトに個人的に取り組んでおり、コンスタンツ大学の学術的前身（Idefix/Treetank）に続いています。アーキテクチャは、アペンドオンリーの物理ログと永続的なコピーオンライトページトライブに基づいています。 アーキテクチャの概要です。 物理ログ（アペンドオンリー、シーケンシャル書き込み） ``` ┌────────────────────────────────────────────────────────────────────────┐ │ [R1:Root] [R1:P1] [R1:P2] [R2:Root] [R2:P1'] [R3:Root] [R3:P2'] ... │ └────────────────────────────────────────────────────────────────────────┘ t=0 t=1 t=2 t=3 t=4 t=5 t=6 → time ``` 各リビジョンはインデックス化され、変更されていないページは共有されます。 ``` [Rev 1] [Rev 2] [Rev 3] │ │ │ ▼ ▼ ▼ [Root₁] [Root₂] [Root₃] │ │ │ │ │ │ │ └─────────┐ │ └────────┐ │ └─────────┐ ▼ ▼ ▼ ▼ ▼ ▼ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │ P1 │ │ P2 │ │ P1' │ │ P2' │ └──────┘ └──────┘ └──────┘ └──────┘ Rev 1 Rev 1+2 Rev 2+3 Rev 3 (shared) (shared) ``` ルートページの下には、ノードインデックスとセカンダリインデックスがあり、読み書きパフォーマンスのバランスを取るための新しいスライディングスナップショットアルゴリズムを使用しています。すべてJSONiqをBrackitコンパイラ経由でクエリできます。 2019年、そして2023年でさえ、SirixDBはGCの負荷により非常に遅かったです。他のほとんどのドキュメントストアとは異なり、SirixDBはきめ細かいノードを格納しており、多数の小さなオブジェクトで構成されるオンヒープ（JVM）表現は意味がないことに気づきました。async-profilerを使って測定したところ（Andrei Pangin氏自身の助けを借りて）、スループットが低い原因は、オープンなトランザクション数にほぼ線形にスケールする膨大な数のアロケーションにあることが判明しました。 フルタイムのソフトウェアエンジニアリングの仕事をしているため、余暇で大規模な書き換えを行うエネルギーがありませんでした。約1年前にAIの実験を始めました。それは、ストレージレイヤーをJavaのForeign Function & Memory APIに移行する際の、ページ全体をオフヒープに格納するという、退屈で反復的な部分を自動化するのに理想的であることがわかりました。 さらに将来を見据えると、アペンドオンリーでイミュータブルなページ設計は、クラウドバージョン向けにS3のようなオブジェクトストレージやKafkaのような分散ログに自然にマッピングされます。初期のプロトタイプはすでに存在します。いつか商用サービスになるかもしれませんが、今のところ、これらのコア設計原則がついに証明されたことを見るだけで興奮しています。インタラクティブデモ、ドキュメントがあり、コードはGitHubにあります。フィードバックを歓迎し、質問に喜んでお答えします。 よろしくお願いいたします。 Johannes [1] https://sirix.io | https://github.com/sirixdb/sirix [2] https://sirix.io/docs/architecture.html [3] https://demo.sirix.io [4] https://sirix.io/docs/ [5] http://brackit.io