ファイルシステムに百万の画像を保存する

膨大な数の画像を生成するプロジェクトがあります。開始には約1,000,000。これらは大きな画像ではないため、開始時にすべて1台のマシンに保存します。

これらの画像を効率的に保存するにはどのようにお勧めですか？（現在NTFSファイルシステム）

私は命名スキームを検討しています...最初はすべての画像に1から1までの増分名が付けられますが、これが必要に応じて後でソートし、別のフォルダに入れるのに役立つことを願っています。

より良い命名スキームは何でしょうか：

a / b / c / 0 ... z / z / z / 999

または

a / b / c / 000 ... z / z / z / 999

これに関する任意のアイデア？

データベースの代わりに通常のファイルシステムを使用することをお勧めします。ファイルシステムの使用はデータベースよりも簡単です。通常のツールを使用してファイルにアクセスできます。ファイルシステムはこのような用途向けに設計されています。NTFSはストレージシステムと同じように機能します。

データベースへの実際のパスを保存しないでください。画像のシーケンス番号をデータベースに保存し、シーケンス番号からパスを生成できる機能を備えた方が良いでしょう。例えば：

 File path = generatePathFromSequenceNumber(sequenceNumber);

何らかの方法でディレクトリ構造を変更する必要がある場合は、処理が簡単です。画像を別の場所に移動する必要があるかもしれません。スペースが足りなくなり、画像の一部をディスクAとディスクBなどに保存し始めるかもしれません。 。

この種のアルゴリズムを使用して、ディレクトリ構造を生成します。

1. 最初に、少なくとも12桁の文字列ができるまで、先頭にゼロを付けてシーケンス番号を埋め込みます。これはファイルの名前です。サフィックスを追加することもできます。
   • 12345 -> 000000012345.jpg
2. 次に、文字列を2または3文字のブロックに分割します。各ブロックはディレクトリレベルを示します。ディレクトリレベルの数を固定します（たとえば3）。
   • 000000012345 -> 000/000/012
3. 生成されたディレクトリの下にファイルを保存します。
   • したがって、シーケンスIDを持つファイルのフルパスとファイルファイル名123は 000/000/012/00000000012345.jpg
   • シーケンスIDを持つファイルの場合12345678901234、パスは123/456/789/12345678901234.jpg

ディレクトリ構造とファイルストレージについて考慮すべき事項：

• 上記のアルゴリズムは、すべてのリーフディレクトリに最大1000ファイルがあるシステムを提供します（合計ファイル数が1 000 000 000 000ファイルより少ない場合）。
• ディレクトリに含めることができるファイルとサブディレクトリの数には制限がある場合があります。たとえば、Linuxのext3ファイルシステムには、1つのディレクトリにつき31998サブディレクトリの制限があります。
• ディレクトリごとに多数のファイル（> 1000）がある場合、通常のツール（WinZip、Windowsエクスプローラー、コマンドライン、bashシェルなど）がうまく機能しないことがあります。
• ディレクトリ構造自体はある程度のディスク容量を必要とするため、あまり多くのディレクトリは必要ありません。
• 上記の構造を使用すると、ディレクトリ構造が乱れた場合に、ファイル名を調べるだけで、画像ファイルの正しいパスを常に見つけることができます。
• 複数のマシンからファイルにアクセスする必要がある場合は、ネットワークファイルシステムを介してファイルを共有することを検討してください。
• 多くのファイルを削除すると、上記のディレクトリ構造は機能しません。ディレクトリ構造に「穴」を残します。しかし、ファイルを削除していないので大丈夫です。

私は2セントの価値を否定的なアドバイスに費やすつもりです。データベースを使用しないでください。

私は長年、画像保存データベースを扱ってきました。大規模（1メガ-> 1ギガ）のファイルで、しばしば変更され、ファイルの複数のバージョンが適度に頻繁にアクセスされます。大きなファイルが保存されているときに遭遇するデータベースの問題は非常に退屈で、書き込みやトランザクションの問題は厄介であり、主要な列車の残骸を引き起こす可能性のあるロックの問題に遭遇します。私は、DBCCスクリプトを書くにはもっと練習があり、任意の普通の人よりも、バックアップからテーブルを復元する必要があり、これまで持っています。

私が使用した新しいシステムのほとんどは、ファイルストレージをファイルシステムにプッシュし、インデックス作成以外の目的でデータベースに依存していませんでした。ファイルシステムは、そのような不正使用を行うように設計されており、拡張がはるかに容易であり、1つのエントリが破損してもファイルシステム全体が失われることはほとんどありません。

これに対処しなければならないほとんどのサイトは、何らかのハッシュを使用して、ファイルがフォルダーに均等に分散されるようにします。

このようなファイルのハッシュがあるとします。515d7eab9c29349e0cde90381ee8f810
これを次の場所に保存し、各フォルダーのファイル数を低く抑えるために必要なレベルの深さを使用できます。
\51\5d\7e\ab\9c\29\349e0cde90381ee8f810.jpg

このアプローチは何度も見ました。これらのファイルハッシュを人間が読める名前と、他に保存する必要があるメタデータにマッピングするためのデータベースが必要です。しかし、このアプローチは、複数のコンピューター間またはストレージプール間などでハッシュアドレススペースの分散を開始できるため、非常にうまくスケーリングできます。

理想的には、特定のハードドライブのセットアップ、キャッシュ、使用可能なメモリなどがこれらの結果を変更する可能性があるため、さまざまな構造のランダムアクセス時間でいくつかのテストを実行する必要があります。

ファイル名を制御できると仮定して、ディレクトリごとに1000のレベルでファイルを分割します。追加するディレクトリレベルが増えると、書き込むiノードも増えるため、ここにプッシュプルがあります。

例えば、

/ root / [0-99] / [0-99] / filename

注：http://technet.microsoft.com/en-us/library/cc781134(WS.10).aspxにはNTFSセットアップの詳細が記載されています。特に、「NTFSフォルダーで多数のファイル（300,000以上）を使用する場合、パフォーマンスを向上させるために、特に長いファイル名の最初の6文字が類似している場合は、短いファイル名の生成を無効にします。」

また、不要なファイルシステム機能（たとえば、最終アクセス時刻）を無効にすることも検討する必要があります。 http://www.pctools.com/guides/registry/detail/50/

何をするにしても、すべてを1つのディレクトリに保存しないでください。

これらの画像の名前の分布に応じて、画像の2文字目などの別のサブフォルダーセットがある単一文字のトップレベルフォルダーがあるディレクトリ構造を作成できます。

そう：

フォルダimg\a\b\c\d\e\f\g\には、「abcdefg」などで始まる画像が含まれます。

必要な独自の適切な深さを導入できます。

このソリューションの素晴らしい点は、ディレクトリ構造がハッシュテーブル/辞書のように効果的に機能することです。イメージファイル名を指定すると、そのディレクトリがわかり、ディレクトリを指定すると、そこに移動するイメージのサブセットがわかります。

これらをファイルシステムに保存しますが、ファイルの数がどれだけ速くなるかによって異なります。これらのファイルはウェブ上でホストされていますか？何人のユーザーがこれらのファイルにアクセスしますか？これらは、より良い推奨事項を提供する前に回答する必要がある質問です。FacebookのHaystackもご覧ください。画像を保存して提供するための非常に優れたソリューションがあります。

また、ファイルシステムを選択した場合は、これらのファイルをディレクトリでパーティション化する必要があります。私はこの問題を見て、解決策を提案しましたが、それは決して完璧なものではありません。ハッシュテーブルとユーザー別にパーティション分割しています。ブログで詳細を確認できます。

400万枚の画像を保存するフォトストアシステムがあります。データベースはメタデータのみに使用され、すべての画像は、ファイルの最後の桁、last-1などからフォルダー名が生成される逆命名システムを使用してファイルシステムに保存されます。例：000001234.jpgは、4 \ 3 \ 2 \ 1 \ 000001234.jpgのようなディレクトリ構造に保存されます。

このスキームは、ディレクトリ構造全体を均等に埋めるため、データベースのIDインデックスと非常にうまく機能します。

簡単に言えば、DBにファイルパスを保存する必要はありません。記述したとおりにファイルに名前が付けられている場合は、数値のみを保存できます。次に、既に説明した明確に定義されたストレージスキームの1つを使用して、インデックスを数値として取得し、ディレクトリ構造を走査して非常に迅速にファイルを見つけることができます。

新しいMS SQL 2008には、このような場合を処理する新しい機能があり、FILESTREAMと呼ばれます。ご覧ください：

Microsoft TechNet FILESTREAMの概要

画像に一意の名前を付ける必要がありますか？ これらの画像を生成するプロセスは、同じファイル名を複数回作成できますか？どのデバイスがファイル名を作成しているのか知らずに言うのは難しいですが、デバイスが「リセット」され、再起動すると、最後に「リセット」されたときと同じようにイメージに名前を付け始めます-そのような懸念がある場合。

また、1か月で100万枚の画像をヒットすると言います。その後はどうですか？ これらの画像はどれくらいの速さでファイルシステムを満たし続けますか？ ある時点で終了し、合計で約100万枚の画像で横ばいになりますか、それとも月ごとに成長し続けますか？

あなたがファイルシステムを月ごとに、そしてイメージごとに設計し始めることができるからです。このようなディレクトリ構造で画像を保存することをお勧めします。

imgs\yyyy\mm\filename.ext

where: yyyy = 4 digit year
         mm = 2 digit month

example:  D:\imgs\2009\12\aaa0001.jpg
          D:\imgs\2009\12\aaa0002.jpg
          D:\imgs\2009\12\aaa0003.jpg
          D:\imgs\2009\12\aaa0004.jpg
                   |
          D:\imgs\2009\12\zzz9982.jpg
          D:\imgs\2010\01\aaa0001.jpg (this is why I ask about uniqueness)
          D:\imgs\2010\01\aab0001.jpg

月、年、日でもセキュリティタイプの画像に適しています。これがあなたが何をしているのかわかりませんが、10秒ごとに写真を撮るホームセキュリティカメラでそれをしました...このようにして、アプリケーションは特定の時間または画像が生成されたと思われる範囲までドリルダウンできます。または、年、月の代わりに、画像ファイル自体から派生できる他の「意味」がありますか？私が与えた日付の例以外のいくつかの他の記述子？

バイナリデータをDBに保存しません。そのようなことで良いパフォーマンス/運がなかった。100万枚の画像でうまく機能すると想像してください。ファイル名を保存して、それで終わりです。それらがすべてJPGになる場合は、拡張機能を保存することもしないでください。ファイルのサーバー、ドライブ、パスなどへのポインターを格納するコントロールテーブルを作成します。この方法で、これらの画像を別のボックスに移動し、それらを見つけることができます。 画像にキーワードタグを付ける必要がありますか？ その場合、その種のタグ付けを許可する適切なテーブルを作成する必要があります。

あなた/他の人が私が返信している間にこれらのアイデアに取り組んでいたかもしれません。

私は、さまざまなデバイスのステータスを文書化するために、年間840万枚の画像を保存するプロジェクトに関与しています。最近の画像はより頻繁にアクセスされ、アーカイブを掘り下げるように促す条件が発見されない限り、古い画像はめったに検索されません。

この使用法に基づいた私のソリューションは、イメージを圧縮ファイルに段階的に圧縮することでした。画像はそれぞれ約20kBのJPGであり、あまり圧縮しないため、ZIP圧縮方式はありません。これは単に、それらを1つのファイルシステムエントリに連結するために行われます。これは、ドライブからドライブへの移動、またはファイルリストの検索に関して、NTFSの速度の面で非常に役立ちます。

1日より古い画像は、「毎日」のzipに結合されます。1か月以上前のzipは、それぞれの「月間」zipに結合されます。最後に、1年以上何も不要になり、結果として削除されます。

ユーザーは（オペレーティングシステムまたは多数のクライアントアプリケーションを介して）ファイルを閲覧でき、すべてがデバイス名とタイムスタンプに基づいて命名されているため、このシステムはうまく機能します。通常、ユーザーはこれらの2つの情報を知っており、数百万の画像のいずれかをすばやく見つけることができます。

これはおそらくあなたの特定の詳細に関連していないことを理解していますが、共有すると思いました。

おそらく、作成日ベースの命名スキーム-ファイル名にすべての情報を含めるか、（後で参照するために）ディレクトリに分割します。画像を生成する頻度に応じて、次のことを考えることができます。

• 毎日生成されるいくつかの画像： Year/Month/Day/Hour_Minute_Second.png
• 数ヶ月： Year/Month/Day_Hour_Minute_Second.png

など。私のポイントを取得します... =）

\ year \ month \ dayなどの日付ベースのフォルダー構造を作成し、ファイル名にタイムスタンプを使用する傾向があります。必要に応じて、ミリ秒以内に複数のイメージが作成される可能性があるため、タイムスタンプに追加のカウンターコンポーネントを含めることができます。命名の並べ替えに最も重要なシーケンスから最も重要でないシーケンスを使用することにより、検索と保守が簡単になります。例：hhmmssmm [seq] .jpg

災害復旧を検討していますか？

ここで提案されているソリューションのいくつかは、ファイル名をマングルすることになります（物理ファイルが移動された場合、実際にどのファイルであるかを追跡できなくなります）。ファイルの場所のマスターリストが破損した場合に、小さなシェル、er、powershell、スクリプトで再生成できるように、一意の物理ファイル名を維持することをお勧めします;）

私がここで読んだことから、これらのファイルはすべて1つのファイルシステムに保存されるように思えます。複数のマシン上の複数のファイルシステムに保存することを検討してください。リソースがある場合は、電源を失い、交換が2日間使用できない場合に備えて、2つの異なるマシンに各ファイルを保存するシステムを決定します。

マシンまたはファイルシステム間でファイルを移行するために作成する必要がある手順を検討してください。お使いのシステムでこれを行う機能はライブであり、オンラインは将来の頭痛の種を大幅に軽減します。

増分番号カウンター（データベースID列？）が台無しになった場合に備えて、増分番号の代わりにGUIDを物理ファイル名として使用することを検討してください。

必要に応じて、Amazon S3などのCDNの使用を検討してください。

私はその規模の写真を提供していませんが、以前は400MHzのマシンで〜25kの写真を提供する小さなギャラリーアプリを作成しました。512 MB程度のRAM。いくつかの経験。

• リレーショナルデータベースはすべてのコストを避けてください。データベースは間違いなくデータの処理に優れていますが、そのような用途向けには設計されていません（ファイルシステムと呼ばれる専用の階層的なキー値データベースがあります）。私は単なる予感しかありませんが、本当に大きなblobを投げると、DBキャッシュがウィンドウの外に出てしまうことを望んでいます。私の利用可能なハードウェアは小さな端にありましたが、画像検索でDBにまったく触れなかったため、桁違いに高速になりました。

• ファイルシステムの動作を調査します。ext3（または、当時ext2だった-思い出せない）では、サブディレクトリとファイルを効率的に検索できる限界は256マーク前後でした。そのため、任意のフォルダにその数のファイルとフォルダのみが含まれます。繰り返しますが、顕著な高速化。NTFSについては知りませんが、XFS（私の知る限りではBツリーを使用します）のようなものは非常に高速です。単に検索が非常に高速だからです。

• データを均等に配布します。上記を試したとき、すべてのディレクトリにデータを均等に分散しようとしました（URLのMD5を実行し、それをディレクトリに使用しました; /1a/2b/1a2b...f.jpg）。そのようにすると、パフォーマンスの制限が何であれ、ヒットするのに時間がかかります（とにかくこのような大きなデータセットではファイルシステムキャッシュが無効になります）。（反対に、制限がどこにあるかを早い段階で確認したい場合は、最初に使用可能なディレクトリにすべてをスローする必要があります。

これでゲームに遅れる場合があります。しかし、1つの解決策（ユースケースに適合する場合）は、ファイル名のハッシュです。これは、ファイル名を使用して簡単に再現可能なファイルパスを作成し、適切に分散されたディレクトリ構造を作成する方法です。たとえば、ファイル名のハッシュコードのバイトをパスとして使用できます。

String fileName = "cat.gif";
int hash = fileName.hashCode();
int mask = 255;
int firstDir = hash & mask;
int secondDir = (hash >> 8) & mask;

これにより、パスは次のようになります。

/172/029/cat.gif

その後cat.gif、アルゴリズムを再現することにより、ディレクトリ構造を見つけることができます。

ディレクトリ名としてHEXを使用すると、int値を変換するのと同じくらい簡単になります。

String path = new StringBuilder(File.separator)
        .append(String.format("%02x", firstDir))
        .append(File.separator)
        .append(String.format("%02x", secondDir)
        .toString();

その結果：

/AC/1D/cat.gif

私はこれについて数年前に記事を書き、最近中にそれを移動しました。いくつかの詳細とサンプルコードがあります：ファイル名ハッシュ：ハッシュディレクトリ構造の作成。お役に立てれば！

Windowsを使用している場合、exFatファイルシステムはどうですか

http://msdn.microsoft.com/en-us/library/aa914353.aspx

メディアファイルの保存を念頭に置いて設計され、現在利用可能です。

それらがすべてすぐに必要でなく、オンザフライで生成でき、これらが小さなイメージである場合、イメージジェネレーターの上にLRUメモリまたはディスクキャッシュを実装してみませんか？

これにより、ストレージからあなたを救い、memから提供されるホットイメージを保持できますか？

私はzfsが大好きなので、zfsでテストを実行しましたが、500gigのパーティションで圧縮を行っていました。50〜100kのファイルを生成し、ネストされたディレクトリ1/2/3/4/5/6/7/8（深さ5〜8レベル）に配置するスクリプトを作成して、1週間実行したと思います。（すばらしいスクリプトではありませんでした。）ディスクをいっぱいにして、最終的に約2,500万個のファイルを持つことになりました。既知のパスを持つ任意の1つのファイルへのアクセスは即時でした。既知のパスを持つディレクトリを一覧表示するのは簡単でした。

ただし、（findを介して）ファイルのリストのカウントを取得するには68時間かかりました。

また、多くのファイルを1つのディレクトリに入れてテストを実行しました。停止する前に、1つのディレクトリに最大約370万のファイルがありました。ディレクトリをリストしてカウントを取得するには、約5分かかりました。そのディレクトリ内のすべてのファイルを削除するには20時間かかりました。しかし、すべてのファイルの検索とアクセスは即座に行われました。

他のデータベースに関する言及はありますが、あなたの投稿にはそれに関する言及はありません。いずれにせよ、この特定の点に関する私の意見は、データベースまたはファイルシステムに固執することです。2つを混ぜる必要がある場合は、注意してください。事態はより複雑になります。しかし、あなたはしなければならないかもしれません。100万枚の写真をデータベースに保存することは、最良のアイデアではありません。

次の仕様に興味があるかもしれませんが、ほとんどのデジタルカメラはそれに従ってファイルストレージを管理します：https : //en.wikipedia.org/wiki/Camera_Image_File_Format

基本的に、などのフォルダーが作成され、000OLYMPUSそのフォルダーに写真が追加されます（例：）DSC0000.RAW。ファイル名カウンターがDSC9999.RAW新しいフォルダーに達する001OLYMPUSと（）、イメージが再び追加され、カウンターをリセットします（異なるプレフィックス（例：）でP_0000.RAW）。

または、ファイル名の一部に基づいてフォルダーを作成することもできます（既に何度も言及されています）。たとえば、写真の名前がの場合IMG_A83743.JPG、に保存しIMG_\A8\3\IMG_A83743.JPGます。実装はより複雑ですが、ファイルを見つけやすくなります。

ファイルシステムによっては（調査が必要です）、すべての画像を1つのフォルダーにダンプすることもできますが、私の経験では、これは通常パフォーマンスの問題を引き起こします。

ZFS（ファイルシステム、Sunのボリュームマネージャー）をご覧になることをお勧めします。

多数からパスを生成するクリーンな方法は、簡単に16進数に変換してから分割することです！

例えば1099496034834> 0xFFFF1212>FF/FF/12/12

public string GeneratePath(long val)
{  
    string hex = val.ToString("X");
    hex=hex.PadLeft(10, '0');
    string path="";
    for(int i=0; i<hex.Length; i+=2 )
    {
        path += hex.Substring(i,2);
        if(i+2<hex.Length)
            path+="/";
    }
    return path;
}

保存およびロード：

public long Store(Stream doc)
{
   var newId = getNewId();
   var fullpath = GeneratePath(newId)
   // store into fullpath 
   return newId;
}

public Stream Load(long id)
{
   var fullpath = GeneratePath(newId)
   var stream = ... 
   return stream;
}

完全なソースコード：https : //github.com/acrobit/AcroFS

残念ながら、ファイルシステムは多くの小さなファイルの管理が非常に悪い（ディレクトリごとの多くのファイルまたは深いディレクトリツリーでのパフォーマンス、再起動時のチェック、信頼性）ので、ファイルシステムを使用する場合は、ZIPファイルを含む上記のソリューションが最適です。

データベースマネージャを使用するのが最良のオプションです。たとえば、BDBやGDBMのような単純なもの。MySQLのようなリレーショナルDBMSでさえも良いでしょう。ファイルシステムとデータベースを理解していない怠zyな人（トランザクションを却下する人など）だけが、データベースとしてファイルシステムを使用する傾向があります（または、その逆）。

イメージを保存するためのIDとBLOBを含むテーブルを持つデータベースはどうですか？その後、写真にさらにデータ要素を関連付けたいときはいつでも、新しいテーブルを追加できます。

スケーリングを期待しているなら、なぜ今スケーリングしないのですか？現在と後のIMOの両方で時間を節約できます。最初にデータベースレイヤーを一度実装します。または、フォルダーとファイル名、およびなんとか何とかで何かを実装し、後でMAX_PATHを爆破し始めたときに別のものに切り替えます。