LatticeDB: ベクトル検索と全文検索を統合した埋め込み型単一ファイルグラフデータベース

LatticeDB は、単一マシン上で関係性が豊富なワークロードに最適化された埋め込み型、単一ファイルのプロパティグラフデータベースです。グラフ走査、HNSW ベクトル類似度検索、BM25 全文検索を一つのクエリエンジンに統合し、意味的・テキスト的・関係的データを別々のデータベースで管理する必要を排除します。

グラフ、ベクトル、テキストの統合クエリレイヤー

LatticeDB は、関係性、意味、テキストのいずれかでデータを単一のクエリ言語で検索できます。これは、クエリが意味的マッチを検索し、関連エンティティに走査し、特定のテキストでフィルタリングする必要がある Graph RAG やエージェントメモリシステムにおいて特に有用です。

Cypher クエリ言語のサポート

LatticeDB は Cypher クエリ言語のサブセットを実装しており、以下の主要な操作をサポートしています：

• 走査: MATCH、WHERE、RETURN、および可変長パス（例：*1..3）。
• 修正: CREATE、DELETE、SET、REMOVE、MERGE。
• 検索演算子: ベクトル距離用の <=> 演算子と全文検索用の @@ 演算子。
• データ処理: WITH、UNWIND、および count、sum、avg、min、max、collect などの集計関数。

統合された検索機能

• ベクトル検索: 可変パラメータ M と ef を設定可能な Hierarchical Navigable Small World (HNSW) 近似最近傍検索を使用。組み込みのハッシュ埋め込みをサポートし、Ollama および OpenAI 用の HTTP クライアントを提供。
• 全文検索: トークン化、ステミング、および可変 Levenshtein 距離によるファジー検索を備えた BM25 ランキング逆インデックスを使用。

パフォーマンスベンチマーク

LatticeDB は Zig で記述され、低レイテンシのローカル操作に最適化されています。Apple M1（シングルスレッド）上で実施されたベンチマークでは、以下のパフォーマンス特性が得られました。

コア操作のレイテンシ

操作	レイテンシ	スループット
ノード検索	0.13 µs	7.9M ops/sec
ノード作成	0.65 µs	1.5M ops/sec
エッジ走査	9 µs	111K ops/sec
全文検索（100ドキュメント）	19 µs	53K ops/sec
10-NN ベクトル検索（100万ベクトル）	0.83 ms	1.2K ops/sec

ベクトル検索のスケーラビリティ

100万ベクトル（128次元のコサインベクトル）のスケールで、LatticeDB は平均レイテンシ 0.83 ms、100% の recall@10 を達成。検索レイテンシは非線形にスケーリング（O(log N)）します。

グラフ走査 vs. SQLite

LatticeDB は SQLite の再帰的 CTE に対して顕著に優れています。10万ノード、50万エッジのソーシャルネットワークグラフにおいて、2ホップ走査は LatticeDB で 38.7 µs、SQLite で 548.3 µs（14倍の高速化）でした。より深い走査（深さ50）では、高速化は 2,819倍に達します。

アーキテクチャと運用モデル

LatticeDB は "ローカルファースト" の哲学に従っており、SQLite の運用のシンプルさを模倣しています。

• ストレージ: データベース全体が単一のポータブルファイルに格納されます。

• 並行処理: 埋め込み型の単一書き込みモデルを使用。1つのプロセスがファイルを所有するため、複数アプリケーションによる同時書き込みには不向きです。

• 耐久性: クラッシュ回復と ACID トランザクション（コミット/ロールバック）を実現するため、先行書き込みログ（WAL）を使用。

• イベントストリーミング: 永続的な名前付きストリームと、グラフ変更通知（changefeed）を備え、グラフ書き込みと同じトランザクション/WALパスを共有。

• バインディング: コアは Zig で記述されていますが、Python、TypeScript/Node.js、Go 用の公式バインディングを提供。

用途分析

理想的な用途

• ローカル知識ツール: サーバーを別途用意する必要のないグラフ構造を必要とするアプリケーション。
• エージェントメモリと RAG: 意味検索と関係走査を組み合わせたパイプライン。
• 接続されたローカルデータ: 引用グラフ、エンティティグラフ、個人ノートの管理。
• ローカル開発: Neo4j や Weaviate のプロトタイピングを単一マシンで行う場合。

LatticeDB を避けるべき状況

• 複数書き込み要件: 複数アプリケーションが同じデータベースに同時に書き込む必要がある場合、PostgreSQL や Neo4j などのクライアント・サーバー型データベースが必要です。
• 表形式データ: 行と列に自然に適合するデータ（例：販売記録）には、リレーショナルデータベースがより効率的です。
• 分散スケーリング: LatticeDB は単一マシンに限定されており、クラスタ間のシャーディングやレプリケーションをサポートしていません。
• 完全な Cypher 対応: OPTIONAL MATCH や CALL プロシージャはまだサポートしていません。

コミュニティの意見

Hacker News 上のユーザーは、本プロジェクトの印象的なパフォーマンスと「使わないべき状況」のドキュメントの有用性を指摘しています。ただし、ベンチマーク結果に若干の相違が報告されています。あるユーザー（@adsharma）は M4 Mac Mini で異なる結果を得たと述べ、LatticeDB が走査において SQLite を上回ることは確認できたものの、公式ベンチマークの高速化係数（例：1ホップ走査で 36倍ではなく 2.8倍）は低かったと指摘しています。

他のコミュニティの議論では、LadybugDB、SparrowDB、DuckPGQ などの新たな「ローカルファースト」グラフツールとの比較や代替案が議論されています。