Relevant source files

The following files were used as context for generating this wiki page: - [env.example](https://github.com/hkuds/lightrag/blob/main/env.example) - [requirements-offline.txt](https://github.com/hkuds/lightrag/blob/main/requirements-offline.txt) - [LICENSE](https://github.com/hkuds/lightrag/blob/main/LICENSE) - [uv.lock](https://github.com/hkuds/lightrag/blob/main/uv.lock)

# ストレージ ## 概要 LightRAGにおける「ストレージ」は、ドキュメントから抽出されたナレッジグラフ（エンティティ、リレーションシップ）、ベクトル化されたチャンク、およびその他のメタデータを永続化するための中核的なコンポーネントです。このシステムは、効率的なデータの挿入、検索、管理を可能にするために、複数のストレージバックエンドをサポートするように設計されています。ストレージ層は、ドキュメントの処理とクエリ応答の両方のパフォーマンスとスケーラビリティを直接左右する重要な役割を担います。このページでは、LightRAGのストレージアーキテクチャ、サポートされているストレージバックエンド、および関連する設定オプションについて詳述します。 ## サポートされているストレージバックエンド LightRAGは、様々なデプロイメントシナリオに対応するため、複数のストレージバックエンドをサポートしています。これらのバックエンドは、プロジェクトの依存関係ファイルにリストされています。`requirements-offline.txt` には、利用可能なストレージ関連のライブラリが含まれています [requirements-offline.txt](https://github.com/hkuds/lightrag/blob/main/requirements-offline.txt)。以下の表は、主なストレージバックエンドとその用途をまとめたものです。 | バックエンド | 依存関係 | 主な用途 | | :--- | :--- | :--- | | **Neo4j** | `neo4j>=5.0.0,<7.0.0` | ナレッジグラフ（エンティティ、リレーションシップ）の格納。グラフデータベースとして最適化。 | | **Milvus** | `pymilvus>=2.6.2,<3.0.0` | 大規模なベクトルデータの格納と類似性検索。 | | **Qdrant** | `qdrant-client>=1.11.0,<2.0.0` | 高性能なベクトル検索エンジン。 | | **MongoDB** | `pymongo>=4.0.0,<5.0.0` | ドキュメント指向のデータベース。グラフデータとベクトルデータの両方を格納可能。 | | **Redis** | `redis>=5.0.0,<8.0.0` | 高速なインメモリデータストア。キャッシュや軽量なデータ格納に利用。 | | **PostgreSQL** | `asyncpg>=0.29.0,<1.0.0` | リレーショナルデータベース。構造化データの格納に利用。 | これらのバックエンドは、`env.example` ファイル内の設定を通じて選択および構成されます。 ## ストレージアーキテクチャ LightRAGのストレージアーキテクチャは、主に2つのタイプのデータを扱います。 1. **ナレッジグラフ (KG) データ**: ドキュメントから抽出されたエンティティ（人、組織、場所など）とそれらの間のリレーションシップ。 2. **ベクトルデータ**: ドキュメントをチャンクに分割し、それぞれをベクトル化したもの。セマンティック検索に使用されます。これらのデータは、選択されたバックエンドに格納されます。`env.example` には、これらのデータを管理するためのいくつかの重要な設定が含まれています。 ### データフロードキュメントが処理される際のデータフローは、以下の図のようになります。 ```mermaid flowchart TB A[入力ドキュメント] --> B[ドキュメント処理] B --> C{データ分割} C --> D[ナレッジグラフ#60;br/#62;エンティティ/リレーション] C --> E[ベクトルチャンク] D --> F[ストレージバックエンド#60;br/#62;Neo4j, MongoDB等] E --> F F --> G[永続化] ``` ### 設定オプション `env.example` ファイルは、ストレージの動作を制御するための多くの設定を提供します [env.example](https://github.com/hkuds/lightrag/blob/main/env.example)。 #### ディレクトリ設定ストレージのデフォルトの場所は、プロジェクトの作業ディレクトリ内の `./rag_storage` です。この場所はカスタマイズ可能です。 ```bash # ドキュメント入力ディレクトリ (デフォルト: ./inputs) # INPUT_DIR= # 作業ディレクトリ (デフォルト: カレントディレクトリ) # WORKING_DIR= ``` #### データ保持とパフォーマンスのチューニングストレージのパフォーマンスとディスク使用量を最適化するための設定がいくつか用意されています。 - **`MAX_SOURCE_IDS_PER_ENTITY` / `MAX_SOURCE_IDS_PER_RELATION`**: エンティティやリレーションが関連付けることができるソースチャンクIDの最大数を制限します。デフォルトは300です。 - **`SOURCE_IDS_LIMIT_METHOD`**: 上記の最大数に達した場合の動作を制御します。 - `FIFO`: 最初に追加されたものから削除します（First-In, First-Out）。 - `KEEP`: 最も古いものを保持し、マージ操作を減らして速度を向上させます。 - **`MAX_FILE_PATHS`**: エンティティやリレーションに表示用として格納されるファイルパスの最大数です。クエリのパフォーマンスには影響しません。これらの設定は、以下の図のように、ストレージ内のデータ構造に直接影響を与えます。 ```mermaid erDiagram ENTITY { string id PK string name string description string source_chunk_ids string file_paths } RELATION { string id PK string source_entity_id FK string target_entity_id FK string description string source_chunk_ids string file_paths } CHUNK { string id PK vector content_vector text content } ENTITY ||--o{ RELATION : "source" ENTITY ||--o{ RELATION : "target" ENTITY ||--o{ CHUNK : "source" RELATION ||--o{ CHUNK : "source" ``` ## まとめ LightRAGのストレージシステムは、柔軟性とスケーラビリティを考慮して設計されています。Neo4j、Milvus、MongoDBといった複数のバックエンドをサポートすることで、ユーザーは自身のニーズに最適なインフラを選択できます。`env.example` で提供される詳細な設定オプションにより、データの保持方法やパフォーマンス特性を細かくチューニングすることが可能です。この堅牢なストレージ層は、LightRAGが大規模なドキュメントセットから効率的にナレッジを抽出し、高精度なクエリ応答を生成するための基盤となっています。