Linux Webサーバーに1,000,000以上の小さなgzipファイルを最も効率的に保存して提供するにはどうすればよいですか？
LinuxベースのWebサーバーを介して配信する必要のある大きな静的コンテンツがあります。これは、100万を超える小さなgzipファイルのセットです。ファイルの90％は1K未満で、残りのファイルは最大で50Kです。将来的には、これは1,000万を超えるgzipファイルに拡大する可能性があります。
このコンテンツをファイル構造に配置する必要がありますか、それともこのすべてのコンテンツをデータベースに配置することを検討する必要がありますか？ファイル構造にある場合、大きなディレクトリを使用できますか、それとも小さなディレクトリを検討する必要がありますか？
ファイル構造の方が配信が速いと言われましたが、ファイルブロックが1Kを超えるため、ファイルがディスク上で多くのスペースを占めることはわかっています。
配信パフォーマンスに関する最善の戦略は何ですか？
[〜＃〜] update [〜＃〜]
記録のために、私はWindows 7で50万のファイルを使用してテストを実行しました：
FS構造の方が速いと思いますが、ファイル数が非常に多いディレクトリを避けるには、適切なディレクトリ構造が必要です。
ディスク容量の損失についてはあまり心配しません。たとえば、16Kのブロックサイズでは、ファイルごとに1つの追加ブロックが必要になる最悪の場合、15GBのスペースが失われます。今日のディスクサイズでは、それは何もありません。特定のニーズに合わせてファイルシステムのパラメータを調整できます。
ファイル構造オプションを選択した場合、ディスクI/Oパフォーマンスを少なくともある程度改善するためにできることの1つは、必要がない限り、noatime + nodiratimeを使用してパーティションをマウントすることです。それらはまったく重要ではないので、そうすることをお勧めします。ソリッドステートドライブを使用することもできます。
ここでの正解は、ファイルのインデックス作成方法によって異なると思います...特定のファイルが配信用に選択されるタイミングを決定するもの。
ファイル名を決定するためにすでにデータベースクエリを実行している場合は、ファイルをdbレコードにそのまま保持する方がよいことがよくわかります。データベースのページング設定を微調整すると、最良の結果が得られる場合があります。選択してからファイルをデータベースに保存します（例：すべてのblobレコードを説明するための大きなページ）。または、ファイルシステムを使用した方がよい場合があります。
データベースオプションは、100万件のレコードがあるため、各ファイルが同じようにクエリされる可能性が低いため、うまくいく可能性が少し高くなります。 1つのファイルが連続して複数回、またはほぼ連続してクエリされる可能性がある状況では、データベースは最近取得されたファイルの事実上のキャッシュとして機能できます。その場合、ファイルの結果が得られることがよくあります。すでにメモリにロードされています。必要な動作を実現するには、データベースエンジンの内部を注意深く調整する必要がある場合があります。
しかし、私の答えから取り除く主なことは、いくつかの代表的なテストデータで試して結果を測定するまで、何が最も効果的かはわかりません。
最新のファイルシステムでは、それほど問題にはならないはずです。同じディレクトリにある10億個のファイルでXFSをテストしましたが、ext4でも問題なく動作すると確信しています（ファイルシステム自体が大きすぎない限り）。ディレクトリエントリをキャッシュするのに十分なメモリがあります。より大きなプロセッサキャッシュも大いに役立ちます。