web-dev-qa-db-ja.com

何百万もの画像を管理するのに最適なファイルシステムは何ですか？

私は100kから10mbまでの1,500万（そして拡大）の画像ファイルを処理できるシステムを設計しています。 （やや）奇妙な要件をサポートするのに最適なファイルシステムは何かについての意見を探しています：

追加情報/要件：

  • ディレクトリ構造は特定の非オプション[1]ですが、このデータをプルするアプリケーションの設計により、比較的不変です。
  • ランダム読み取り、順次読み取り、ディレクトリリスト（一部のディレクトリには30,000のディレクトリまたは1,000のイメージがある場合があります）などを含むが、これらに限定されないデータを最適化して読み取る必要があります。
  • 追加データは、半定期的にファイル構造（新しいサブディレクトリ、既存のサブディレクトリ内の追加ファイルなど）に書き込まれますが、書き込みパフォーマンスはそれほど重要ではありません。データはSMBまたはNFS経由で書き込まれます。
  • かなりの数の同一ファイルがあります（控えめな見積もりは20％です）。ただし、このデータを取得するアプリケーションの設計により、重複するファイル名を削除することはできません。理想的には、ある種の重複排除が必要です（確かにハードリンクはできますが、何百万ものハードリンクがどのようにスケールするかはわかりません）。
  • SSDは、このプロジェクトのストレージの主要な形式になります（スピナーの代わりに議論を行うことができる場合を除く）。したがって、可能な場合は、システムへの書き込みを制限します。

このプロジェクトに割り当てたハードウェアは次のとおりです。

Dell R720xd w/ 24x 2.5” bays
RAM: 128GB RAM (more can be allocated if needed)
CPU: 2x E5-2620 @ 2.20GHz
Storage:
    8x2TB SSDs local storage
    1x500GB SSD for OS
RAID: H310 (IT Mode)

私たちは当初、これについてZFSを検討していましたが、追加の調査の結果、次のように表示されます。

  • ZFSは、メタデータ更新を書き込むときにSSDをスラッシュする可能性があります。
  • ZFSには、重複排除のための高いRAM要件（5GB RAM 1TBのデータあたり）があります。これは、現在のハードウェアで実行できるはずですが、たくさんのオーバーヘッド。
  • RiserFSは、小さなファイルのランダムルックアップに適している可能性があります（「小さな」ファイルに適したものを見つけることができないようです）。

このユースケースに最適なファイルシステムに関する意見や、ハードウェアの調整については、大歓迎です。

[1]

ディレクトリ構造の例（どのディレクトリやファイル名も正規化されていない（順次など））

+ root directory 1
    - sub directory 1
        - image 1
        - image 2
        - image 3
        - ...
        - image n (where n is between 1 and 1,000+)
    - sub directory 2
        - image 1
        - image 2
        - image 3
        - ...
        - image n
    ....
    - sub directory n (where n is between 1,000 and 30,000)
        - image 1
        - image 2
        - image 3
        - ...
        - image n
+ root directory 2
+ ...
+ root directory 15
filesystemsstoragezfsimagesreiserfs
4
Josh

すべてのファイルシステム（ext4が低く、XFSがわずかに低い）は、リストした要件を満たすことができます。これは、基本的には、さまざまなユースケースで大量のファイルを格納できる機能と適切なパフォーマンスです。私の知識（およびこの回答の興味深いトレードオフ）は主にZFSに関するものなので、私はそれに焦点を当てます。

ZFSから得られる追加の機能は次のとおりです。

  1. 重複排除。あなたが言ったように、これは重いRAM要件があるため、ZFSではそれほど素晴らしいものではありませんが、動作します。非ZFSで同様のものを取得するには、ファイルをハッシュして、ファイル名/ディレクトリ名としてハッシュするか、ハッシュのデータベースを保持する->ファイル名を使用して、ハードリンクを作成できます（これらのいずれの場合でも、完全にだけでなく、同じファイルが必要です。同じように見える画像）。
  2. 圧縮。ほとんどの画像はすでに圧縮されているため、あまり購入しない可能性がありますが、JPEGではなくRAWの場合は、大幅に節約できます。そうでなければ、これはあなたをあまり買わないでしょう。
  3. スナップショット/バックアップする機能。 ZFSには、このための優れた組み込みツールがあります。データの一貫したスナップショットを取得するのは難しい場合がありますが、非ZFSもバックアップできます。 LVMはこれのいくつかを実行できますが、間違いなくそうではありません。
  4. ボリューム管理はZFSの一部です。非常に柔軟なRAID構成のセットから選択して、特定のアプリケーションに最適な[データの冗長性、スペースの使用、パフォーマンス]の構成を取得できます。 LVMやその他のソフトウェアRAIDからこれを得ることができますが、ZFSには、障害管理と障害検出のための適切に設計されたシステムと組み合わせた、ボリューム管理に最適なソリューションの1つがあると思います。

あなたが言及した他の2つのこと：

  • スラッシングメタデータ。私はZFSが他のファイルシステムよりも悪いとは思わない：書き込み中にかなりの量のメタデータを更新しますが、書き込み時にコピーし、5〜10秒ごとにバッチでこれらの更新を行います。つまり、大規模な連続書き込みが発生していますNANDブロックを何度も消去して再書き込みする必要がある小さなインプレース書き込みの代わりに。従来のファイルシステムではインプレース更新を行うため、逆になってしまいます。とにかく、最近のSSDには、摩耗がある場合にドライブの寿命を延ばすために予約されている多くの追加ブロックが内部にあります。通常のドライブの寿命は、ディスクの寿命と同等と見なされます。それは問題ではないと言っているわけではありません。この側面はかなりマイナーなので、あまり注意を払わなくてはいけないと思います。
  • ハードリンクのスケーラビリティ。通常のファイルと同じかそれ以上にスケーリングする必要があります（ZFSかどうかに関係なく）。どちらの方法でも、ハードリンクは他のファイルと同じiノードへのポインタにすぎず、リンクの1つからそのファイルを読み取ると、他のリンクを介したアクセスのためにキャッシュされるため、おそらくキャッシュ効率は非常に小さくなります。あまりにも。
3
Dan