RustでPostgresを作る — データベースのLLVMを活用するアプローチ

 (turso.tech)
1 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • TursoはRustベースのデータベースコアにPostgres互換フロントエンドを接続し、1つの実行エンジンが複数のデータベース言語を処理するデータベースのLLVM構造へ拡張する
  • Postgres SQLを共通ASTにパースしてVDBEバイトコードへコンパイルし、可能性を検証したpgmicroをメインコードツリーにマージして公式の開発基盤とした
  • 既存コアはSQLiteファイル互換性、MVCCによる同時書き込み、非同期実行、豊富な型システム、自動更新されるマテリアライズドビューをサポートし、複数のテスト手法で信頼性を検証する
  • ブラウザ・モバイル・各種デバイスで組み込みまたは単一ファイルとして実行しつつ、既存アプリケーション、ORM、psqlがPostgresワイヤプロトコルで接続できるよう設計する
  • 100%一致よりも広く使われる中核機能によって既存アプリケーションの大半を変更なしで実行することに集中し、拡張機能とPL/pgSQLにはWASMおよび互換レイヤの適用を検討し、MITライセンスで開発する

Turso上にPostgresを構築する理由

  • TursoはRustで書かれたモダンなデータベースコアであり、その上にPostgres互換データベースをゼロから構築する
  • 長期目標は既存のPostgresを単にRustへ移植することではなく、モダンなアーキテクチャを備えた新しいデータベースを作ること
    • 接続ごとに別プロセスを使わない
    • ブラウザ内で組み込み方式により実行できる
    • 1つのデータベースを単一ファイルとして扱える
    • マテリアライズドビューが追加作業なしに自動更新される
  • 1つの安定したコアに複数のフロントエンドを接続する交換可能なコンパイル構造を目指す
    • SQLiteが最初のフロントエンド
    • Postgresが次の公式フロントエンド
    • 将来的にはMySQL、Redis、実験的データベースのようなフロントエンドも追加できる
  • 現在の成果物は完成した製品ではなく、実際に実行できる開発基盤段階である

SQLite再実装から共通データベースコアへ

  • TursoはもともとSQLiteをRustとモダンなアーキテクチャで完全に再実装したプロジェクトであり、SQLiteファイルを開いて作成できるファイル互換性を維持する
  • SQLiteの範囲を超える機能もすでに備えている
    • PostgresのようにMVCCを利用した同時書き込みをサポートする
    • Postgresに似た豊富な型システムを提供する
    • 完全非同期方式で動作し、ブラウザのような制約のある環境でもネイティブ実行に適している
    • マテリアライズドビューがリアルタイムで自動更新されるため、REFRESH MATERIALIZED VIEWのcronジョブやトリガーの組み合わせは不要
  • Postgresフロントエンドが追加されても、既存のTursoとSQLiteの目標は変わらない
    • SQLite完全互換性と将来のワークロードに向けた機能拡張を引き続き追求する
    • 必要な機能を実装する際にPostgresのテストも活用でき、開発速度を高められる

信頼性と公開コントリビューションモデル

  • SQLiteの堅牢性を再現するため、信頼性を製品機能として扱う
    • 決定論的シミュレーションテストを使用する
    • Antithesisテストを実施する
    • Oracleテスト、ファジング、形式手法も併用する
  • Tursoには現在260人以上のコントリビューターがおり、外部の人もプロジェクトの方向性に参加できる**公開コントリビューション（Open Contribution）**方式を運営している
  • コードと高い品質基準を中心に置き、継続的に作業したコントリビューターがプロジェクトの意思決定にも参加する、Linuxカーネル式の環境を目指す
  • AIが書いたコントリビューションも受け入れるが十分な品質が必要であり、人間がコードを綿密にレビューし、アーキテクチャを理解しなければならない

SQLite内部のVDBE仮想マシン

  • SQLiteはSQLを直接実行する単一レイヤではなく、SQLite方言のSQLをVDBEバイトコードへコンパイルして実行する仮想マシン構造を持つ
  • VDBEはJVM、.NET、WASMのような汎用バイトコードではなく、B-treeで項目を探すのようにデータベースに特化した高水準の演算を提供する
  • このバイトコード言語には外部公開された仕様やモジュール式インターフェースはないが、SQLite内部には実際に存在し、Tursoも同じ設計を採用する
  • Turso VDBEの汎用性を検証するため、小さなC-to-VDBEコンパイラでDoomを変換した
    • 実際のTursoエンジンをWASMへコンパイルし、ブラウザタブでDoomのVDBEバイトコードを実行する
    • データベースがSELECTを処理するのと同じ方式でDoomを実行する
    • 各フレームを1つの結果行として処理する
    • メモリ領域は読み書き可能なblobとして表す
    • 実装はturso-vdbe-doom-exampleリポジトリで確認できる

Postgresフロントエンドのコンパイル構造

  • 既存のSQLiteとPostgresの結合の試みは、SQLiteのモノリシック構造のため、PostgresクエリをSQLiteクエリに変換するクエリレイヤの翻訳に主に依存しており、2つのデータベースの外部動作の違いによるインピーダンスミスマッチが大きかった
  • 内部的には、ほとんどのSQLデータベースがB-treeとインデックス集合を中心に似た基本演算を実行する
  • PostgresとSQLiteのストレージ構造には明確な違いがある
    • Postgresは行をヒープファイルに置き、別個のB-treeインデックス、タプルバージョン、TID、vacuumを使用する
    • SQLiteはデータをB-treeにクラスタリングする
  • こうした違いは主にディスク上にバイトを配置する方法から生じるもので、Postgresに必要な演算は既存のVDBEで表現するか、VDBE命令を拡張してサポートできる
  • 新しい構造ではデータベースフロントエンドを交換できる
    1. Postgres言語を共通ASTにパースする
    2. ASTをTursoバイトコードへコンパイルする
    3. 共通のTursoコアがバイトコードを実行する
  • 可能性を検証した初期実験はpgmicroで行い、その結果をTursoのメインコードツリーにマージして公式プロジェクトへ移行した

実行形態と活用シナリオ

  • 同じPostgres SQLとデータベース動作を、サーバーなしで複数の形で提供することが目標
    • ブラウザタブで実際のPostgres互換データベースを実行する
    • エージェントがユーザーごとに新しいデータベースを作り、それぞれを1つのファイルとして管理する
    • ローカルファーストアプリケーションがPostgresデータを単一ファイルとしてダウンロードした後、再び同期する
    • モバイルフォンと各種デバイスでSQLiteのように組み込み方式で動作する
  • 既存のTursoデータベースをローカルファイルへ同期する機能もTurso/Postgresでサポートする計画
  • 単一ファイル・組み込み実行だけでなく、ワイヤプロトコルとサーバー実装も含むため、既存アプリケーション、ORM、psqlが接続できる
  • 近い時期にTursoチームが直接開発する公式フロントエンドはSQLiteとPostgresであり、他のフロントエンドは外部コントリビューターが作れるよう構造を開放する

現在の実行方法と参加

  • まだ配布パッケージはないが、ソースから直接ビルドして実行できる 
    cd postgres/cli && cargo run
  • Postgresフロントエンドは別リポジトリではなく、Tursoコードツリー内で初日から公式フロントエンドとして開発されている
  • 開発とコントリビューションはTurso GitHubリポジトリで行う

互換性の目標と境界

  • SQLiteよりはるかに複雑なPostgresの特性上、100%互換性を必須目標とはしない
  • 中核機能と広く使われる機能を十分にサポートし、大多数のユーザーがアプリケーションを変更せずに実行できるようにすることに集中する
  • モダンな機能と完全な1:1互換性が衝突する場合は、機能ごとに判断する
    • Tursoのマテリアライズドビューはリアルタイム自動更新方式
    • 完全な互換性だけのために、自動更新されない従来方式まで別途実装するかは確定していない
  • 機能範囲が広がるほど、Turso/PostgresはPostgresの複製品というより独自のデータベースに近づく可能性がある

AI活用と開発速度

  • AIツールを積極的に使う一方で、コードレビューとアーキテクチャ理解は省略しない
  • データベースのような重要な構成要素では、AIツールが検証責任を代替する水準にはまだ達していないと判断する
  • Fableを24時間実行する方式よりコミット単位の速度は遅い可能性があるが、すでに動作し広範にテストされたデータベースコアから出発する
  • 速く変更してシステムを壊すより、遅くても正しく実装する方式を選ぶ
  • すべての機能を完成させるには時間が必要であり、一部の機能は適切なアーキテクチャが定着するまで長い開発過程を経る必要がある

PL/pgSQLと拡張機能

  • PL/pgSQLは実装不可能な要素ではない手続き型言語だが、そのまま再実装するより、別の手続き型言語と互換レイヤを提供する可能性が高い
  • 一部のPostgres拡張機能をWASMコンテナで読み込む概念実証を確保した
    • WASMコンテナが提供するシンボルのみを使用する拡張機能は任意に読み込める
    • WASM実行に伴う性能低下がある
    • まだ最終設計として確定した方式ではない
  • 任意コードを制限なく実行させる拡張システムは望ましくないと判断している
  • 一部の拡張機能はサポートできない可能性があるが、多くの拡張機能はWASMへコンパイルすれば読み込めると見ている

想定スケジュールとオープンソース戦略

  • ゼロから新しいデータベースを作るのではなく、すでに動作しテストされており、Postgresと内部構造の多くを共有するコアから始める
  • すべてのPostgres機能を実装するには長い時間がかかる可能性があるが、実務に有用な十分に大きな機能サブセットは数か月以内に提供できると見込む
  • 2人の主要開発者は現在約44歳で、今後少なくとも20年は開発できるため、全機能の完成を急がない
  • 実際の開発速度と範囲はコミュニティのコントリビューションに大きく左右される
    • SQLite方言のマルチプロセスサポート時、チームにWindows機がなかったためWindows実装を除外した
    • Tursoを多用していた外部開発者1人が関心を持ち、1週間以内にWindowsサポートを完成させた
  • 実験的フロントエンドはコードツリー外で開発される可能性があるが、公式Postgresフロントエンドには既存のTursoと同じMITライセンスを適用する

関連記事

1件のコメント

 
GN⁺ 4 시간 전
Lobste.rs の意見

  • ほぼすべての SQL データベースはクエリを 仮想マシン(VM) 向けにコンパイルしているのではと思う
    その点で SQLite だけを特別に取り上げるのはやや奇妙に見える

    • ほとんどのデータベースは 関係演算ツリー を作り、各演算に push または pull インターフェースを持たせている
      一方 SQLite は、変数とループを持つ 命令型バイトコード にクエリをコンパイルする

  • pgwire の開発者として、Turso が PostgreSQL 互換データベース に pgwire を再び使うのはうれしい

  • 会社がなぜ 方向転換 が必要だと判断したのか気になる

  • SQLite の再実装 を完了したのか、それとも断念したのか気になる
    https://lobste.rs/s/rxdnnq/introducing_first_alpha_turso_next

  • とても興味深い記事なのに、不当な 通報処理 をされたのは情けないことだ

    • いつか自分の業務プロジェクトの勢力図を変えるかもしれないほど インパクトの大きい技術 だ
      決して「off-topic」でも「spam」でもないのに、なぜそんな通報をしたのかまったく理解できない
      記事にダッシュが1つ入っていたから AI のゴミだと決めつけたのかもしれないが、人々は本当に正気を失いつつある気がする
      このサイトの通報文化はひどくなってしまったので、運営が対処してほしい。悪意のある通報をする数人を締め出せば、ほかの人たちも自制するかもしれない
    • もはや 不当な通報 そのものがここの文化になっているレベルだ

  • 以前から、Turso が SQLite の後継者を気取る ような姿勢に反感を持っていて、そのせいで数年前からこのソフトウェアは絶対に使うまいと決めていた
    だが、SQL Server 以外でも高速で安価な 自動更新マテリアライズドビュー を提供してくれるなら、結局は使うことになるかもしれない