データが増えると Immich の検索やクエリ結果が遅くなる原因は何ですか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

What Causes Immich Search or Query Results to Slow as Data Grows?

Immichの検索は、写真が存在するだけで遅くなるのではなく、インデックスやワーキングセットが大きくなって効率的なキャッシュ、フィルタリング、ストレージの処理能力を超えると遅くなります。

ライブラリが大きくなると、行数、埋め込み、メタデータ、サムネイル、フィルターの組み合わせ候補など、複数の量が同時に増加します。どの段階で遅くなっているのかを診断してください。高速なファイルストレージでも不適切なクエリ経路は改善できず、データベースのチューニングでもリモートのサムネイルマウントを高速化することはできません。

増加するのは元のライブラリだけではない

追加された各アセットは、データベースの行、抽出されたメタデータ、検索用表現、顔情報、サムネイル、エンコード済みメディアを増やす可能性があります。これらの構造は異なる速度で増加し、アクセス方法もそれぞれ異なります。そのため、どれだけの検索可能なエンティティや派生オブジェクトをリクエストがたどるのかを把握しなければ、元のライブラリのテラバイト数だけで検索レイテンシーを予測することはできません。

ZimaSpaceのImmichデータパス分析では、バックグラウンド処理、検索可能な表現、データベースによる選択、配信されるメディアを分けて考えています。クエリ診断における実践的な教訓は、ライブラリの増加によって検索対象のカタログだけでなく、結果の後に提示されるファイルも変化し、複数の遅延要因が生じるということです。

各マイルストーンで、アセット数、データベースサイズ、ベクトルインデックスのサイズ、サムネイルの使用容量、頻繁に使うフィルターのカーディナリティを記録してください。時系列で確認すれば、どの構造がレイテンシーとともに増加しているかが分かり、元の動画バイト数の無関係な増加をデータベースによる選択時間の原因と誤認せずに済みます。

ベクトルインデックスはメモリへの収まり具合の影響を受けやすくなる

セマンティック検索では、元の画像をすべて読み取るのではなく、表現用のインデックスをたどります。インデックスが大きくなると、アクティブなグラフやページがメモリ上に常駐し続けられなくなる可能性があります。するとランダムなキャッシュミスによって、メモリ速度で処理できていた作業がストレージ読み取りに変わり、平均CPU使用率から想定される以上にテールレイテンシーが上昇することがあります。

PostgreSQLのベクトル検索に関する技術分析では、アクティブなグラフがメモリ容量を超えると、ランダムアクセスによる走査がキャッシュミスの影響を受けやすくなり、HNSWの性能が低下する可能性が説明されています。Immichのバージョンやインデックス実装は変わり得るため、これは設定の処方箋ではなく、検証すべきメカニズムとして利用してください。

再起動直後、ウォームアップを1回行った後、無関係なライブラリ領域にアクセスした後で、同じセマンティッククエリを測定してください。データベースの読み取り、キャッシュヒットの挙動、デバイスのレイテンシーを比較します。ウォームアップによる大きな改善がワーキングセットの拡大とともに失われるなら、メモリへの収まり具合が原因である可能性が高くなります。一様に遅い場合は、別の原因を疑ってください。

カーディナリティによってフィルターとクエリプランが変わることがある

日付、人物、所有者、アルバムなどの条件は、ランキングの前または途中で残る候補数を変えます。データ分布が変わると、同じ見た目のフィルターでもライブラリのはるかに大きな割合を選択することがあります。そのため、検索語自体が変わっていなくても、データベースの統計情報やプランの選択が重要になる場合があります。

pgvectorの制限に関するレビューでは、ベクトル検索とメタデータフィルターの組み合わせが難しい場合があり、ベクトル処理がトランザクション処理とPostgreSQLのCPU、メモリ、I/Oを共有することが説明されています。これは一般的なPostgreSQLに関する根拠であり、Immichの特定のクエリプランを証明するものではなく、あくまでメカニズムを裏付けるものです。

既知の結果セットを使い、1つのフィルターを付けた検索と付けない検索を作成してください。ブラウザーでの完了時間だけでなく、サーバー側のクエリ時間とデータベースのアクティビティも記録します。選択時間が増えている一方で、返されたサムネイルの表示が速いなら、メディアストレージではなく、プラン、統計情報、インデックスの適合性、競合に注目してください。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

結果の選択と結果の描画を分けて考える

データベースが一致するアセットIDをすでに選択した後でも、インターフェースが遅く感じられることがあります。描画には、サムネイルの検索、ストレージからの読み取り、レスポンスの転送、クライアント側でのデコードが必要です。派生ファイルのツリーやリモートマウントが大きくなると、この第2段階が遅くなる一方で、実際の検索クエリは正常なままということがあります。

大量インポートの報告では、数十万件のメタデータおよびサムネイルのジョブがキューに残っている間、Immich全体の動作が広範囲に遅くなった事例が説明されています。これはバックグラウンド処理による負荷が重なった例であり、普遍的なスケール上限を示すものではありません。また、増加のテストをキューがアクティブな状態と、処理が完了した後の両方で行う必要があることも示しています。

ブラウザーのタイミング情報やAPIの観測結果を使い、結果レスポンスの完了と最後に表示されるサムネイルを別々に記録してください。キューを停止した状態とアクティブな状態で、既知の検索を繰り返します。IDの取得が遅いなら、データベースとインデックスの経路を調査してください。画像だけが遅いなら、サムネイルストレージ、ネットワーク配信、クライアント側のデコード、競合するバックグラウンドI/Oを確認します。