より高速なSQLiteを求めて

 (avi.im)
2 ポイント 投稿者 GN⁺ 2024-12-17 | 1件のコメント | WhatsAppで共有
  • SQLiteはすでに高速なデータベースシステムだが、研究者たちはこれをさらに高速化する方法を探っている
  • ヘルシンキ大学とケンブリッジ大学の研究者が「非同期I/Oによるサーバーレスランタイム／データベース共同設計」という論文を発表し、テールレイテンシを最大100倍削減できることを示した。この論文は、Rustで再実装されたSQLiteであるLimboの基礎となっている。

io_uring

  • io_uringの説明: Linuxカーネルのio_uringサブシステムは、非同期I/Oのためのインターフェースを提供する。これはユーザー空間とカーネル空間の間のリングバッファを通じてバッファコピーのオーバーヘッドを減らす。アプリケーションはI/Oリクエストを送信し、OSからI/O処理完了の通知を受けるまで他の作業を実行できる。

  • SQLiteのクエリ実行: SQLiteはデータ保存にファイルを使用し、sqlite3_open()関数でデータベースを開き、sqlite3_prepare()関数でSQL文をバイトコードに変換する。sqlite3_step()関数はバイトコード命令を実行してクエリを処理する。

前提

  • サーバーレスコンピューティングの台頭: サーバーレス環境ではデータベースのレイテンシが問題になりうる。データベースをエッジランタイムに直接組み込めばレイテンシはなく、SQLiteはこのような環境に適している。

  • SQLiteの問題点: 同期I/Oの利用によりリソース使用が最適化されず、並行性とマルチテナンシーの問題を引き起こす。

  • io_uringへの移行: POSIX I/O呼び出しをio_uringに置き換えるのは簡単ではなく、SQLiteを非同期I/Oモデルに合わせて再設計する必要がある。

Limbo

  • 非同期I/Oのサポート: VMとBTreeコンポーネントを修正して非同期I/Oをサポートし、同期バイトコード命令を非同期命令に置き換える。非同期I/Oはブロッキングをなくし、並行性を向上させる。

  • クエリエンジンとストレージエンジンの分離: リソース使用を最大化するため、クエリエンジンとストレージエンジンを分離することを提案している。

評価と結果

  • ベンチマーク: マルチテナントのサーバーレスランタイムをシミュレーションし、各テナントが独自の組み込みデータベースを持つようにした。SQLiteとLimboのクエリレイテンシを比較した結果、Limboはp999でテールレイテンシを100倍削減した。

  • 今後の作業: 複数のリーダーとライターを含む追加ベンチマークを計画しており、性能上の利点はp999以降でのみ顕著に現れる。

  • オープンソースコード: Limboのコードはオープンソースとして提供されている: Limbo GitHub

関連記事

1件のコメント

 
GN⁺ 2024-12-17
Hacker Newsの意見

  • AWS Lambda のようなサーバーレスコンピューティングの特定のユースケースは、中央データベースを持つサーバーレス構成のアプリとうまく噛み合わないことがある、という議論がある

    • 6〜7年前、複雑な階層ファイルを処理して特定の情報を抽出しなければならない問題に取り組んだ経験がある
    • FaaS は計算コストの高い処理では高価であり、大きな XML ファイルを毎回ロードしてパースするのは非効率だった
    • 解決策として、タイマーでファイルを読み込み・パースして SQLite データベースにロードし、インデックスを作成したうえで S3 にファイルを保存する中央機能を使った
    • Lambda 関数は、ローカルコピーより新しい場合、またはコールドスタート時に、S3 からファイルをダウンロードして検索を実行した
    • Lambda にはローカルの /tmp ディレクトリがあり、Python ランタイムに SQLite が含まれているため、関数以外のコードをアップロードする必要がないことに気づいた
    • こうしたソリューションをさらに高速化できる取り組みが進んでいるのは興味深い

  • 2人の研究者のうち1人が著者の上司であることは明記する価値があるかもしれない

    • 著者と研究者は無関係だと誤解していた

  • 「利点が目立つのは p999 以上だけで、p90 や p99 では性能は SQLite とほぼ同じ」という点に同意する

    • SQLite と最適化は好きだが、この点は事実だ

  • SQLite には広範なテストスイートがあり、非常に徹底してテストされている

    • リライト版が同等のテストを受けるのか、とくに io_uring のように高速だが実装が難しく、潜在的にバグを含みうる機能を使う場合はどうなのか、という疑問がある

  • ベンチマークのために、各テナントが独自の組み込みデータベースを持つマルチテナントのサーバーレスランタイムをシミュレーションした

    • SQLite はテナントごとに独自のスレッドを持ち、各スレッドでクエリを実行して計測した
    • サーバーレス SQLite の設定で、リクエストごとに SQLite プロセスを使うのかどうか疑問がある

  • 以前、Postgres に非同期 I/O を導入しようとする試みがあったが、中止された

    • 最近の提案では、コードベースをフォークせずにストレージマネージャをカスタム実装に置き換えられるようにするという
    • この新しい提案には強い関心があり、ストレージとコンピュートを分離する流れとも関係している

  • 非同期 I/O が動作している間に別の作業ができる、という考えに対する疑問がある

    • データベース処理では、結局トランザクションの完了を待つ必要があるのではないか、という疑問

  • ブログ記事の著者として、この投稿がトップページに載るとは予想していなかった

    • Turso で働いており、論文は 2024 年 4 月に公開され、その後多くの改善が行われた

  • SQLite はオープンソースだが、重要なテストハーネスはそうではない

    • 代替実装がどのように互換性を保証するのか、という疑問がある

  • SQLite ファイル形式の厳密なサブセットとして JSON ライクな形式を作る簡単な道を探したことがあるが、うまくいかなかった

    • ファイル形式にはかなり恣意的な部分が多く、興味を失ったが、ほかの誰かなら成功できるかもしれない