デザインテーマに関する多くの情報を保存・管理しなければなりません。すべてを論理的に整理するには、次の 2 つの方法が考えられます。
各 Web サイト ユーザーごとのディレクトリ。テーマ関連のファイルがこのディレクトリに格納されます。(ディレクトリあたりのファイル数は多くありません)。
関連するすべてのユーザーのファイルを含む、テーマごとのディレクトリ。(多くのテーマと多くのユーザー)。
ユーザーがログインするたびに、関連ファイルを取得する必要があります。私のサイトは PHP で開発され、CentOS でホストされています。この質問は重要な設計上の質問ですか? どちらを選択しても、ストレージとパフォーマンスに違いはありますか? 個人的には、最初の選択肢の方が従いやすいと思います。
古典的な答えは常に次のとおりでした。大きなディレクトリはパフォーマンスを低下させます。
ただし、2012年があります。80年代または90年代の答えは、必ずしも良いものではありません。
これは、LevelDBシステムのコンテキストで実行された優れたマイクロベンチマークです。ext3を使用したそのベンチマークでは、1000ファイルのディレクトリでファイルを開くのに9ミリ秒、10,000ファイルの場合は10ミリ秒、100,000ファイルの場合は16ミリ秒かかりました。ただし、追加のディレクトリを読み取って開くには時間がかかることも覚えておいてください。
一般に、ディレクトリ内のファイル数が増えると、対数が増えることを期待する必要があります。FAT32などの非常に脳死したファイルシステムを使用していない限り、または構成が台無しになっています。ただし、大量のディレクトリまたはディレクトリ階層を使用する場合は、漸近的に同じ成長が期待できます。
比較として、一般的なプロセスは次のとおりです。
多数のファイルがあるディレクトリでファイルを開く：
少数のファイルがあるが、ディレクトリの別の層があるディレクトリでファイルを開く：
漸近的に、データを多数のディレクトリに分割するためにデータを読み書きするために何も購入することはありません。
[編集：]単語の文字ごとにディレクトリ階層を構築するという提案を作成します。これは、分岐係数が最大52であり、ファイル配布に大きな偏りがあることを意味します。いくつかの文字はより一般的であり、ディレクトリにははるかに多くのファイルが含まれています。ファイルシステムの暗黙的なツリー構造を使用する場合の分岐係数は、たとえば高くなり、分布が歪むことはありません。これにより、IOが大幅に削減されます。これは、パフォーマンスを目指す場合には単に悪い考えです。誰かが本当にディレクトリを使用したい場合は、少なくとも良好なデータ分散を確保するために、データをディレクトリにハッシュすることを検討してください。
大きなディレクトリは、含まれるファイルが多すぎるとオーバーヘッドが大きくなります (「多すぎる」の定義は OS とファイルシステムに依存します。したがって、一般的には、より多くのディレクトリ (サブディレクトリでネストされている場合でも) を使用し、ファイルを少なくする方がはるかに優れています)。それぞれ...私は通常、上限として100ファイル/ディレクトリを使用しようとします