Immichは元データに加えてどれくらいのストレージ容量を消費しますか？

エヴァ・ウォン

IceWhale author

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

How Much Storage Overhead Does Immich Add Beyond Source Data?

Immichはストレージ使用率を一律に定めていません。オーバーヘッドは主に、アセット数、動画の構成、派生データの設定、データベースの増加、保持するバックアップによって変わります。

写真が中心の1テラバイトの家族ライブラリは、長時間のスマートフォン動画が中心のライブラリとは異なります。代表的なインポート後に生成される各データ種別の容量を測定し、増加分、一時作業領域、復旧用コピーのための容量を別途確保して、ストレージを計画してください。

派生メディアが目に見えるオーバーヘッドの大部分を占めることが多い

Immichは、タイムラインやビューアー用に小さい画像を生成し、互換性のある再生のために動画のエンコード版を作成することがあります。これらの出力容量は、アセット数、解像度の選択、品質設定、動画の長さやコーデックの構成に応じて増加します。ユーザーが直接ダウンロードすることがなくても、元ファイルとは別に追加されます。

772 GiBの外部ライブラリを測定したコミュニティの測定結果では、サムネイルが約18 GiB、エンコード済み動画が65 GiBでした。この約83 GiBという結果は具体例としては有用ですが、計画用の比率として扱うべきではありません。別のライブラリでは、写真と動画の構成や設定によって、両方の容量が大きく変わる可能性があるためです。

家庭内の実際の写真、RAWファイル、短い動画、長い動画を含む代表的な範囲をインポートした後、サムネイルとエンコード済み動画のディレクトリ容量を記録してください。各派生データの種類について、アセット数あたりと元データ容量あたりの比率を別々に算出します。アセット基準と容量基準の比率は、それぞれ異なる増加予測に役立ちます。

データベースと検索状態は関連関係に応じて増加する

データベースのオーバーヘッドには、アセット情報、ユーザー、アルバム、メタデータ、顔認識情報、検索用データ、インデックス、ジョブ状態が含まれます。小さな画像と大きな動画では元データの容量が大きく異なっていても、一部のレコード数は同程度になることがあります。そのため、データベースの増加は元データのテラバイト数よりも、エンティティ数や有効化した機能との関係が強くなります。

ZimaSpaceのImmichバックアップ記事では、不可欠な元データとデータベース状態を、再生成できる派生データのパスから分けて説明しています。この区別は容量を予測する際に重要です。派生データを削除すれば一時的に容量を回復できますが、データベースを失うと、サムネイルだけでは復元できない関連関係も失われるためです。

既知の件数のデータをインポートする前後でデータベース容量を記録し、どの処理機能が完了したかを確認してください。顔認識と検索処理が完了した後にも再度測定します。処理キューが未完了の状態から外挿しないでください。追加の表現データや関連関係が書き込まれるにつれて、アセットあたりの見かけ上のオーバーヘッドは増加するからです。

バックアップと一時作業が必要容量の下限を変える

累計容量だけでは、バックアップの作成、データベースのダンプ、インポートの準備、派生データの置き換えに必要な容量を考慮できません。アップグレードや再生成の際には、古いデータと新しいデータが同時に存在することがあります。そのため、定常状態の使用量ぴったりに合わせたディスクは、年間のメディア増加がわずかでも、通常のメンテナンス中に容量不足になる可能性があります。

ストレージ計画に関する記事では、元データ、サムネイル、メタデータ、機械学習処理によって、空いていたSSDがImmichで満杯になった事例が紹介されています。より広い観点での教訓は、アプリケーションの増加分と復旧用コピーが運用上の余裕を奪い合うということです。したがって、空き容量は現在のアイドル状態ではなく、最も負荷の高いメンテナンス状態をカバーできなければなりません。

オフホストのコピーは別の障害から保護するものなので、バックアップの保持容量は別項目として管理してください。また、最大規模のインポート、再エンコード、アップグレードのテストで確認した作業用の余裕も確保します。空き容量は多ければ必ずよいというわけではありませんが、ピーク時の余裕を測定していない状態では、容量不足が予測可能な問題になります。

-15% OFF

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

Single board computer zimaboard2

ライブラリ固有のオーバーヘッド計算表を作成する

元データ、サムネイルとプレビュー、エンコード済み動画、データベース、機械学習データ、ローカルバックアップのダンプ、一時的なピーク容量の行を作成します。空の状態の基準値を測定してから、代表的な範囲のデータをインポートします。キューの処理が完了するまで待ち、差分を計算する前に各項目を再度記録してください。

SSDとHDDの配置に関する実践的な議論では、遅延の影響を受けやすい生成データと、大容量の元データが区別されています。容量を検討する際、この区別によって、元データを別の場所に保存している場合でも、高速ストレージ層のオーバーヘッドを把握できます。そうしないと、大容量NAS全体の容量に隠れて、アプリケーション用SSDがほぼ満杯になっていることを見落とす可能性があります。

1回だけの比率ではなく範囲を得るため、同じ代表データの測定をもう一度行います。各項目を、それぞれ適切な指標で予測してください。指標には、アセット数、動画の容量または長さ、ユーザー数と関連関係の増加、保持数、メンテナンス時のピーク作業容量などがあります。元データの増加分は、派生データと復旧に必要な容量を別々に把握した後で加算します。