ハクソク

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

LumoSQL

363日前原文(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ベースで、今までに何千行も書いてて、毎日増えてるよ。

└

2つのことがあるよ：

  1. おそらく、ブラウザで動かすのに喜んで対応するWASMへのSqlite3のポートがあるはず。
  2. 「ブラウザからのレプリケーション、ピアツーピアがあれば、もっと便利な世界に住んでると思う」っていう状況に合うアプリケーションが何か知りたいな。何十年も前からブラウザで動くGunDBやIPFS、Urbitみたいなプロジェクトがあるのに、肝心のアプリが存在しないように思える。基本的なデモとしても役立つものがないのはどうして？誰か何か指摘できるものある？個人的には全然見当たらないんだけど。
└

この話題でいつも出てくることなんだけど、言う価値があるからね、macOSの画像編集ソフトAcornのファイルフォーマットについて。 https://flyingmeat.com/acorn/docs/technotes/ACTN002.html 個人的には、モバイルやデスクトップアプリで結構使ってるよ。

└

人々はSQLiteを何に使ってるの？ ソロゲームで、クラフトの結果がランダムで、限られたインベントリが嫌だから、プロフィールやインベントリを管理するのに使ってるよ。

└

テスト用のシングルショットMySQL DBで、簡単に立ち上げられて、特定のバックエンドインスタンスから簡単に切り離せる。SQLiteを使うよりもそれが簡単なら、何か間違ってるよ。 クラウドのどこかに小さなMySQLインスタンスを立ち上げるのと比べて、何が利点なの？ 一つの利点は、ネットワークアクセスなしで動作することだよ。

LMDBのミキシングのためだけに試してみたいな。

└

rocksdbやfoundationdbに対して動かせるか試してみたいな。mvsqliteはそれに近いことをやってるけど、foundationdbにはrocksdbが提供するような圧縮機能が欠けてるんだよね。

SQLite自体はオープンソースだけど、最後にチェックしたとき、テストスイートはプロプライエタリのままだった。 変更後にすべてが正常に動作し、上流と互換性が保たれるなら、こういう「フォーク」はどうやってテストされるの？

└

一般的なテストスイートは独自のものではなく、コードの標準的な部分です。make testを実行すればテストができます。TCLを使ってテストを実行していて、ほぼすべてをカバーしています。別にTH3テストスイートがあって、これは独自のものです。テストのCコードを生成するので、組み込み環境などでテストを実行できるし、あまり知られていないテストケースもカバーしています。 https://sqlite.org/th3.html

LumoSQLは、SQLiteにとって有用かもしれない変更を示すために存在していますが、SQLiteが世界の大多数に使われている独自の立場のため、何年も考慮できないかもしれません。 > SQLiteは何千ものソフトウェアプロジェクトで使われていて、GoogleのAndroid、MozillaのFirefox、AppleのiOSの3つだけでも数十億のユーザーがいます。これがSQLiteがすべての変更に対して慎重で保守的な理由の一つです。これは素晴らしい視点ですね。SQLiteチームは彼らとどれくらい協力しているのでしょうか？特にSQLiteの互換性が必要な場合、実際の運用ではどれくらい機能するのでしょうか？

ホームページには、実際に何なのか、何をするのかが書いてありません。

└

主なポイントはプラグイン可能なバックエンドのようです。

└

ホームページには、「LumoSQLはSQLiteのバックエンドのキー・バリュー・ストアエンジンを入れ替えることができます。LMDBは最も有名な（しかし唯一ではない）代替キー・バリュー・ストアの例で、LumoSQLはLMDBとSQLiteのソースコードの何十ものバージョンを組み合わせることができます(...)」とも書いてあります。また、「暗号化と破損検出、オプションで行ごとに」とも。

LumoSQLが追加しようとしている利点を最もよく説明している気がします: > LumoSQLは、世界で最も使用されているソフトウェアであるSQLiteの派生物です。私たちの焦点はプライバシー、静止状態の暗号化、再現性、そしてこれらの目標をサポートするために必要なことにあります。 [...] https://lumosql.org/src/lumosql/file?name=doc/project-announ... Phase 1が何だったのか、またPhase 3の計画があるのかは不明ですが、少なくとも現在の目標が示されているようです。

確か、LMDBは非常にバグが多いです。バグを多く修正したLMDBのフォークを維持している人がいましたが、彼は非常に意見が強く、ロシアの外の世界は「悪」と考えていて、自分のフォークを悪用することを禁じています... ああ、ライセンスがApache 2.0に変更されました！でも、GitHubアカウントにはヒトラーとソロスを同一視するメモがあります... なぜSQLiteのバックエンドをLMDBに置き換える必要があるのでしょうか？追記: おっと、LMDBはずっと前にフォークされていたので、もしかしたらLMDBはすでに修正されているかもしれません！

KVバックエンドの提案: BadgerDB https://github.com/hypermodeinc/badger

LumoSQLはロックをどう扱ってるの？もしロックレスなストレージエンジンとしてWildcatを提案したら、LumoSQLはアトミック性やマルチライターに最適化できるのかな？興味があったらCの共有ライブラリもあるよ。https://wildcatdb.com