家族写真のバックアップ中にImmichのメタデータが増えるのはなぜですか？

家族写真のバックアップ中にImmichのメタデータが増えるのは、各オリジナル画像によってアプリケーションのレコードが作成され、さらにサムネイル、検索ベクトル、顔データなどの派生状態も作成される場合があるためです。

この増加量は、元のライブラリ容量に対する一律の割合ではありません。小さな画像が多い家庭、長時間の動画を多く保存している家庭、顔データが多数ある家庭、または大規模な検索処理を実行している家庭では、同じ容量の元データでも、別のオーバーヘッド構成になる可能性があります。増加が想定内か判断する前に、データベースの状態と生成ファイルを分けて考えてください。

すべてのアセットが永続的なアプリケーションレコードを追加する

データベースには、アセットと所有者、パス、タイムスタンプ、アルバム、権限、その他アプリケーション上で表示されるプロパティを関連付けるレコードが必要です。アセット数や関連付けが増えると、元ファイルを別の場所に保存している場合でも、この永続的な状態は増加します。

データベースのオーバーヘッドをサムネイルやオリジナルファイルと分けて説明するストレージ容量の概要は役立ちます。ただし、掲載されている例の数値は、別の家庭のライブラリにも保証される比率ではなく、導入時の観測値として扱うべきです。

そのため、一部のメタデータに関する問題では、元データのギガバイト数よりもアセット数を出発点にする方が適切です。大容量の動画1万本と小さな写真1万枚では、元データに必要な容量は大きく異なる可能性がありますが、どちらもアプリケーションデータベースにアセット単位のレコードと関連付けが必要です。

生成された閲覧用ファイルが別のストレージ曲線を加える

タイムラインの閲覧では、すべてのオリジナルを開くよりも高速に表示できる小さな表現データが使われます。これらの生成ファイルは厳密な意味でのデータベースメタデータではありませんが、ライブラリとともに増加し、アプリケーションによって管理されるため、「Immichのオーバーヘッド」と認識されることがよくあります。

ホームラボでの導入例にある4サービスのストレージ構成では、写真、生成メディア、データベースの配置が区別されています。この分離は運用上重要です。頻繁に生成・変更される派生ファイルと重要なデータベースの状態では、バックアップやパフォーマンスにおける役割が異なるためです。

この増加曲線を元データのバイト数だけから推定しないでください。サムネイル数はアセット数と有効にしたサイズに左右され、エンコード済み動画の出力は動画の互換性やトランスコード設定に左右されます。同じグループの処理が完了した後、生成された各ディレクトリを個別に測定してください。

検索機能と顔認識機能がインデックスの状態を追加する

セマンティック検索や顔認識機能では、元の画像を書き換えることなくビジュアルコンテンツを検索できるように、数値表現や関連付けが作成されます。そのため、処理済みアセット、検出された顔、有効にした分析機能が増えるほど、データベースやモデル関連の状態も時間とともに増加します。

セマンティック埋め込みの説明からは、ファイル名やフォルダーが変わらなくてもビジュアル検索インデックスが増加する理由が分かります。モデルは対象となる各画像を再利用可能な表現に変換し、その後、テキストクエリとの比較に利用できるようにします。

この状態を、フル解像度のコピーがもう1つ作成されたものと混同しないでください。アセット数、機能設定、モデルの構成が安定しているのに検索関連のデータベースが急速に増え続ける場合は、通常のインデックス処理で説明できると決めつけず、メンテナンス、重複処理、その他のデータベースの仕組みを調査してください。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

家族による整理では、ファイルだけでなく関連付けも増える

アルバム、人物名、共有関係、お気に入り、編集内容、その他のユーザー操作によって、元データを追加しなくてもアプリケーションのメタデータは増加します。そのため、メディアの内容が同じ2つの家庭でも、一方がより多くの整理機能や共有機能を使っていれば、データベースの使用量は異なる可能性があります。

ZimaSpaceによる写真整理レイヤーの概要では、一元管理されたオリジナルと、その上に構築される検索可能な人物、場所、イベント、アルバムとの違いが示されています。これらの関連付けはユーザー体験の一部であり、復旧計画でも考慮する必要があります。

ログ、コンテナの書き込み可能レイヤー、一時ファイル、重複した元データの増加を、この仕組みだけで説明することはできません。これらのカテゴリーにはそれぞれ異なる原因があるため、単一の「メタデータ」数値にまとめず、データベースと派生ファイルのモデルとは別に測定してください。

ストレージの役割ごとに増加量を測定する

代表的なインポートを行う前に、基準値を記録してください。対象は、元メディアの容量と個数、データベースのサイズ、サムネイルまたはプレビューのストレージ、エンコード済み動画のストレージ、モデルキャッシュ、バックアップ、一時ファイルやログ用の領域です。同じグループで有効にしたバックグラウンドジョブが完了した後、さらに通常の家庭利用を行った後にも測定を繰り返してください。

ZimaSpaceの家族向けバックアップワークフローからも、再生成可能な出力は別の扱いにできる一方で、オリジナルと重要なアプリケーション状態を一緒に保護する必要があることが分かります。ストレージの計上では、バイト数だけでなく復旧時の価値も基準にするべきです。

増加分が新しいアセット、派生ファイル、データベースレコード、有効にした機能に対応している場合、その増加は想定内と考えられます。いずれかの役割だけが、対応するアセット数や機能の利用状況なしに増加している場合、または測定した合計が既知のストレージ役割の合計から大きく外れている場合は、さらに調査してください。