Linux Webサーバーで1,000,000以上の小さなgzip圧縮されたファイルを最も効率的に保存して提供するにはどうすればよいですか？

LinuxベースのWebサーバーを介して配信する必要のある大きな静的コンテンツがあります。これは、100万を超える小さなgzipファイルのセットです。ファイルの90％は1K未満で、残りのファイルは最大で50Kです。将来的には、1,000万を超えるgzipファイルに成長する可能性があります。

このコンテンツをファイル構造に入れる必要がありますか、それともすべてのコンテンツをデータベースに入れることを検討すべきですか？ファイル構造の場合、大きなディレクトリを使用できますか、それとも小さなディレクトリを検討する必要がありますか？

ファイル構造の方が配信が速いと言われましたが、反対に、ファイルのブロックが1Kを超えるため、ファイルがディスク上で多くのスペースを占めることになります。

配信パフォーマンスに関する最良の戦略は何ですか？

更新

記録として、Windows 7で50万ファイルのテストを実行しました。

FS構造の方が高速だと思いますが、非常に多数のファイルを含むディレクトリが作成されないように、適切なディレクトリ構造が必要になります。

ディスク容量の損失についてはあまり心配しません。例として、16Kのブロックサイズでは、1つのファイルごとに1つの追加ブロックが必要な最悪の場合、15GBのスペースが失われます。今日のディスクサイズでは、それは何もありません。特定のニーズに合わせてファイルシステムのパラメーターを調整できます。

ファイル構造オプションを選択した場合、ディスクI / Oパフォーマンスを少なくともある程度向上させるためにできることの1つは、必要な場合を除き、noatime + nodiratimeでパーティションをマウントすることです。それほど重要ではないので、そうすることをお勧めします。ソリッドステートドライブを使用することもできます。

ここでの正しい答えは、ファイルのインデックス作成方法に依存すると思います。特定のファイルが配信用に選択されるタイミングを決定するものは何ですか。

ファイル名を特定するためのデータベースクエリを既に作成している場合は、dbレコード内のファイルをそのままにしておく方がよい場合がよくあります。選択してから、ファイルをdbに保存します（例：すべてのblobレコードを説明するための大きなページ）。または、ファイルシステムを使用したほうがよい場合があります。

100万件のレコードがある場合、各ファイルがクエリされる可能性が等しくない可能性が高いため、データベースオプションの方がうまくいく可能性が少しあります。1つのファイルが連続して数回、またはほぼ連続してクエリされる可能性がある状況では、データベースは最近取得されたファイルの事実上のキャッシュとして機能することができます。この場合、ファイルの結果がよくなります。すでにメモリにロードされています。必要な動作を得るために、データベースエンジンの内部を注意深く調整する必要がある場合があります。

しかし、私の答えから取り除くべき主なことは、いくつかの代表的なテストデータで試して結果を測定するまで、何が最もうまくいくかを実際には知らないということです。

最近のファイルシステムでは、それほど問題にはなりません。同じディレクトリに10億個のファイルがあるXFSをテストしましたが、ext4も問題なく動作するはずです（ファイルシステム自体が大きすぎない限り）。ディレクトリエントリをキャッシュするのに十分なメモリがある。大きなプロセッサキャッシュは、多くの場合にも役立ちます。