1,500 万の単純なキー/値レコードがあります。キーのサイズはすべて単一の単語であり、含まれる値のサイズはそれぞれ数バイトから 10MB の範囲です。
ランダム キーは頻繁にアクセスする必要があります。
これらをデータベースではなくディレクトリにファイルとして保存する方がはるかに効率的だと思います。したがって、これらすべてのエントリを含む大規模なテーブルを作成する代わりに、ファイル名をキーとしてファイル内の値を含むディレクトリが必要です。
これは、キーの値が必要な場合は、そのようなリクエストで MySQL を悩ませる代わりに、PHP でazpdk行う必要があることを意味します。file_get_contents('/my/directory/azpdk')
私の頭ではこれは理にかなっており、データベースの代わりにファイルシステムを使用する方が効率的であると期待しています。私はこの仮定で正しいですか？1 つのディレクトリに 1,500 万個のファイルがある場合でも、これは高速で効率的ですか?
参考までに、ファイルシステムは xfs です。
この種のことについて、ファイル システムではなくデータベース (必ずしも MySQL ではない) を見たいと思う理由がいくつかあります。
1 つのディレクトリにファイルが増えると速度が低下します
XFS はリソースの割り当てに関して非常に巧妙であると考えられていますが、ほとんどのファイルシステムでは、1 つのディレクトリに多くのファイルがあるほどパフォーマンスが低下します。また、コマンド ラインでそれらを処理することも頭痛の種になります。これ ( http://oss.sgi.com/projects/xfs/datasheet.pdf ) を見ると、ルックアップに関するグラフがあり、ディレクトリごとに 50k までしか上がらず、減少傾向にあります。
オーバーヘッド
ファイルごとに一定量のファイルシステム オーバーヘッドがあります。小さなファイルが多数ある場合、この結果、最終的なストアが肥大化することがあります。
キークリーニング
すべての単語をファイル名に入れても安全ですか? 本気ですか？そこにスラッシュが1つか2つあると、本当にあなたの一日が台無しになります。
NoSQLは良い選択肢かもしれません
これには、MongoDB/Redis のようなものが適しているかもしれません。MongoDB は、最大 16 MB の単一のドキュメントを格納でき、ファイル システムに物を配置することはそれほど難しくありません。15 MB のドキュメントを保存している場合、その制限を快適にするには少し近すぎるかもしれませんが、他のオプションがあります。
これの良いところは、ルックアップのパフォーマンスがすぐにかなり良くなる可能性が高く、後でそうでないことがわかった場合は、クラスターなどを作成してパフォーマンスをスケーリングできることです。このようなシステムはどれも良い仕事をします.ディスク上のファイルをインテリジェントに管理して、優れたパフォーマンスを実現します。
ディスクを使用する場合
保存したい単語の MD5 ハッシュを取得し、これに基づいてファイル名を作成することを検討してください。たとえば、の MD5azpdkは次のとおりです。
1c58fb66d5a4d6a1ebe5ec9e217fbbf9
これを使用してファイル名を作成できます。
my_directory/1c5/8fb/66d5a4d6a1ebe5ec9e217fbbf9
これにはいくつかの優れた機能があります。
それが役立つことを願っています。