ハクソク

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

LumoSQL

2025年5月27日原文(lumosql.org)

概要

  • LumoSQL はSQLiteにセキュリティやプライバシー機能を追加するプロジェクト
  • Not-forking手法 で複数のアップストリームを追従しつつ独自機能を実装
  • プラガブルバックエンド や行単位暗号化・チェックサムなど先進的機能を提供
  • ベンチマーク機能 で多様な構成・ストレージエンジンの比較が可能
  • MITライセンス で配布、NLNet Foundationによる支援あり

LumoSQLとは

  • SQLite をベースにした 組み込みデータストレージライブラリ改良版
  • セキュリティ、プライバシー、性能、計測機能 の追加
  • Not-forkingツール でアップストリームを半自動追従
  • MITライセンス での配布、 NLNet Foundation による支援
  • x86、ARM-32、RISC-V など多様なアーキテクチャ対応

プラガブルバックエンドと主な機能

  • バックエンドの入替え が可能（例： SQLite Btree, LMDB, Berkeley DB）
  • 複数バージョンのLMDBやSQLite を組み合わせたビルドが可能
  • 行単位暗号化 （Attribute-Based Encryption対応）と 行単位チェックサム
  • チェックサム でエラー検出や検索・比較性能向上
  • 今後も新しいKVSエンジン追加・評価予定

ベンチマークとNot-forking

  • ベンチマーク機能 で多様なシステム・構成間の性能比較
  • Not-forking はアップストリームを分岐せず追従する独自ツール
  • LumoSQL Build and Benchmark System により構成変更も容易
  • 他プロジェクトでもNot-forkingツール利用可能性

SQLiteとの関係性

  • SQLite本体とは協調的な関係
  • 大規模ユーザー基盤 （Android, Firefox, iOS等）で慎重な本家方針
  • LumoSQLは実験的改良案のデモンストレーション
  • SQLiteのアーキテクチャ変更検討には膨大な準備が必要

LumoSQLの制限事項（v0.4時点）

  • ベンチマークテスト は古いSQLiteのspeedtest.tclベース
  • LMDB/BDBバックエンド は最新版SQLiteビルドに未同梱
  • KVSごとのキーサイズ差異 対応が未解決
  • 一部テストはLMDBやBDBで失敗する場合あり
  • BDBはSQLiteよりユーザー管理機能が豊富で追加テストが必要

ビルド環境と依存関係

  • 必須ツール ：git、unix系開発ツール、Tcl、Perlベースのnot-forkingツール
  • 推奨ツール ：Fossil（SQLiteと相互依存関係）
  • Debian/Ubuntu系 ：deb-src有効化、aptで依存関係一括導入
  • Fedora系 ：dnfで必要パッケージ導入
  • 全Linux共通 ：not-forkingは手動インストールが必要
  • Fossilのビルド ：公式手順または簡易手順で対応可能
  • 他ツール ：curl/wget、file、gzip、GNU tar（BDBターゲット用）

クイックスタート：ビルドとベンチマーク

  • リポジトリ取得 ：fossil clone https://lumosql.org/src/lumosql
  • ビルド・ベンチマーク ：make what で設定確認、make benchmark で実行
  • 例 ：make benchmark USE_LMDB=no USE_BDB=no SQLITE_VERSIONS='3.35.5'
  • 結果保存 ：benchmarks.sqliteに結果格納、run_data/test_dataテーブルで管理
  • 結果解析 ：tool/benchmark-filter.tclでRUN_IDやDURATIONなどを抽出
  • DATASIZEパラメータ でベンチマークデータ量を調整可能

まとめ

  • LumoSQL はSQLiteの実用性を保ちつつ、先進的な機能や構成柔軟性を実証
  • Not-forking によるアップストリーム追従と独自拡張の両立
  • ベンチマークと多様なバックエンド で研究・実用双方の価値を提供

Hackerたちの意見

あのサイトで一番面白いのはNot-Forkingのアイデアだと思う。

└

PikChrの図は初めて見たけど、めっちゃ面白いね。

└

それ言おうと思ってた！ソースコードレベルでソフトウェアをフォークせずにカスタマイズできる方法が本当に必要だよね。

└

これを読んでも、何を解決しているのか、何をするのか、どうするのかがよくわからなかった。 変更された上流のファイルをローカルでどう扱うの？フォークせずに？変更は、ビルド時に遅延適用される別の設定フォーマットに保持するの？フォークを維持するのに問題があったことはないけど。

└

ちょっと混乱してるんだけど、これはただパッチを当てて適用するだけのこと？

└

記事には、なぜこれがgitのサブツリー統合より優れているのか書いてないね。

└

これってアウトオブツリーのパッチって呼ぶんじゃない？Linuxにはそういうのがたくさんあるし、新しいアイデアってわけでもないよね。違いは、複数のアップストリームがあるから、実際には以下の要素からなる新しいプロジェクトって感じかな。 - 一連のsqliteパッチ、 - 他のアップストリームやパッチ？ - それらをまとめて一つのアーティファクトにするためのカスタムツールチェーン

ここで聞くのは違うかもしれないけど、以前ブラウザで使えるSQLiteを触ったことがあって、あれはゲームチェンジャーになる手前だったと思う。もしブラウザでまだサポートされていて、ピアツーピアでレプリケーションができたら、もっと便利な世界になってたと思う。素晴らしい技術だけど、真剣に何かを作ったことはないんだ。今のところ、フロントエンドのウェブ技術としては消えちゃったみたい。NodeJSサーバーのバックエンドに使うことはできるけど、データをメモリやローカルファイルに保持するだけで、あんまり良い使い道が見えないんだ。SQLiteを使える小さなプロジェクトはたくさんあるけど、テスト用に一発で立ち上げられるMySQL DBの周りにスキャフォールドすることが多いから、どんなメリットがあるのか分からない。Litestreamみたいなものには完全に魅了されてるけど、試す理由を見つけたいと思ってる。けど、SQLiteがクライアントサイドのストアとして機能しなくなった時点で、思いつく良い使い道は全部消えちゃった。要するに、みんなSQLiteを何に使ってるの？クラウドのどこかに小さなMySQLインスタンスを立ち上げるのと比べて、レプリケーションやフェイルオーバーを自分で管理しなくて済むっていう利点は何？

└

SQLiteのほとんどの使い方はクライアントサイドのアプリだよ。基本的にウェブ以外のすべて、モバイルアプリやデスクトップアプリ、車やテレビ、キオスクなどの組み込みソフトウェアまで。こういうアプリではSQLiteを使ってるアプリの方が多いと思う。

└

クライアントでもまだ使えるよ、ただ実行方法を工夫しないとね。例えば、https://github.com/orbitinghail/sqlsyncは、Web Worker内でコンパイルされたrusqliteを使ってる。

└

今、あなたのポケットの中にインストールされてるか、いくつか動いてる可能性が高いよ。これは存在するソフトウェアの中で最も広く展開されているものの一つだから。多くのユーザー向けのウェブアプリを実行するための「伝統的な」DBではないけど（それもできるけど）、データストアやクエリツールが必要なクライアントベースのソフトウェアを支えるためのものなんだ。

└

ほとんどのPythonプロジェクトではSQLiteを使ってるけど、1つだけ例外があって、マルチプロセッシングでデータベースにアクセスする必要があるから、ロックの問題や速度を考慮して、DB全体をメモリ上で動かさなきゃいけないんだ。 https://docs.python.org/3/library/sqlite3.html 組み込みライブラリのおかげで、すごく簡単に使えるよね。MySQLや、僕の場合はPostgreSQLを使う必要があるときもあるけど。サードパーティのライブラリを探してるの？前にPsycopgを使ったことがあるけど、特に必要じゃなかったな。SQLiteのロックされたデータベースのパフォーマンスの問題には直面したことがあるし、マルチユーザー機能がちゃんと動かなかったこともあった。でも、もっと根本的に問題にアプローチし直す必要があったんだ。僕の新しいスタートアップ、http://mapleintel.caはdb.sqlite3ベースで、今までに何千行も書いてて、毎日増えてるよ。

Hacker Newsで議論の続きを見る