すべてのデータを大きな MySQL データベースに保存するのではなく、プレーン テキスト ファイルを使用してサーバーにデータを保存しようとしています。問題は、数千のフォルダーと数十万のファイルを生成する可能性が高いことです (スケーリングする必要がある場合)。これを行う際の問題は何ですか？本当に遅くなりますか？データベースを使用するのと同じくらいのパフォーマンスですか?
つまり、ブログテーブルを格納するデータベースを作成する代わりに、「作成者」、「メッセージ」、および「日付」を含む行を作成する代わりに、特定の投稿用のフォルダー、内部の *.txt ファイルを作成します。そのフォルダーには、「作成者」、「メッセージ」、および「日付」が保存されています。
これは、データベースよりも読み取りが非常に遅くなります (ファイルの書き込みはすべてほぼ同じ速度で発生します。書き込みをメモリに保存することはできません)。
データベースは最適化されており、このような大量の構造化データを処理することを目的としています。ファイルシステムはそうではありません。ファイル システムを使用してデータベースを複製しようとするのは間違いです。結局のところ、データベースの列にインデックスを付けることができますが、別のツールなしでファイル システムにインデックスを付けるのは困難です。
データベースは、データへの迅速なアクセスと検索のために構築されています。ファイル システムは、データ ストレージ用に構築されています。仕事に適したツールを使用してください。この場合、それは完全にデータベースです。
そうは言っても、投稿用の HTML ファイルを作成し、それらのロケールを DB に保存して簡単にアクセスできるようにしたい場合、それは間違いなく良い解決策です (Movable Type のように)。
しかし、これらの情報をファイル システムに保存した場合、最新の投稿をどのように見つけることができるでしょうか? 最も多作な作家？最も物議を醸す著者は？これらはすべて、データベースでは些細なことですが、ファイル システムでは非常に困難です。データベースに固執してください。そうしてよかったと思います。
それは本当に依存しています：
MySQL の方が高速であることは明らかではありません。
CppCMSのセッションストレージとして使用するために、小さなオブジェクトに対してそのような比較を一度行いました。1 つのインデックス (キーのみ) と 2 つのインデックス (プライマリ キーとセカンダリ タイムアウト)。
File System: XFS ext3
-----------------------------
Writes/s: 322 20,000
Data Base \ Indexes: Key Only Key+Timeout
-----------------------------------------------
Berkeley DB 34,400 1,450
Sqlite No Sync 4,600 3,400
Sqlite Delayed Commit 20,800 11,700
ご覧のとおり、単純な Ext3 ファイル システムを使用すると、ACID の (D) が得られないため、データの保存に関して Sqlite3 と同じか、または Sqlite3 と同じくらい高速でした。
一方... DB は、おそらく必要となる多くの重要な機能を提供するため、本当に必要でない限り、ファイルをストレージとして使用することはお勧めしません。
DB が常にシステムのボトルネックであるとは限らないことを覚えておいてください
ここで重要なのは、データにインデックスが作成されないことです。たとえば、検索で何かを取得するのは、インデックス付きデータベースと比較して途方もなく遅くなります。また、IO 操作はコストがかかります。データベースは (部分的に) メモリ内にある可能性があり、データをより高速に利用できるようになります。
なぜ自分でデータベースを使用しないのか、あなたは本当に言いません...しかし、あなたが説明しているシナリオでは、いくつかの理由で、いつでもDB over folderを使用することは間違いありません。まず第一に、ブログのシナリオは非常に単純に見えますが、いつか、検索、投稿の詳細、カテゴリなどの機能を拡張して拡張したいと考えるのは非常に簡単です。
モデルの成長は、DB よりもフォルダー構造の方が難しいと思います。
また、データベースは通常、インデックス作成とメモリ キャッシュにより、ファイル アクセスよりもはるかに高速です。
IIRC Fudforum は、速度の理由からファイル ストレージを使用しました。DB インデックスを検索し、DB からデータを取得してユーザーに送信するよりも、ファイルを取得する方がはるかに高速です。ファイルシステム インターフェイスを DB および DB ライブラリ インターフェイスと交換しています。
ただし、それはそれが速くなったり遅くなったりするという意味ではありません。ファイルシステムでの書き込みは高速ですが、一般的な問題については DB での読み取りが高速であることがわかると思います。fudforum のように、複数の投稿をまとめて表示したい比較的不変のデータがある場合は、ファイルベースのアプローチの方がはるかに高速です。たとえば、関連するすべての投稿を検索する必要はなく、すべての投稿を貼り付けます。 1 つのテキスト ファイルを作成し、1 回表示します。この種の最適化を採用できれば、ファイルベースのアプローチが機能します。
また、メール サーバーもファイル ベースのアプローチで動作します。Maildir 形式では、各電子メール メッセージがデータベースではなくディレクトリにファイルとして保存されます。
ただし、1 つ言えることは、すべてを 3 つではなく 1 つのファイルに保存する方がよいということです。ファイルシステムは、複数のファイルよりも 1 つのファイルを読み取る (およびキャッシュする) 方が優れています。したがって、各メッセージを 3 つの部分として保存する場合は、それらをすべて 1 つのファイルに保存し、それを読み取って任意の部分を取得し、表示したい部分だけを表示します。
...そして、著者によるすべての投稿を検索したい場合、単純な SQL クエリの代わりに 100 万のファイルを読み取る必要があります...
データベースは高速ではありません。考えてみてください。最終的に、データはファイルシステムにも保存されます。したがって、データベースが高速かどうかは、アクセス パスに大きく依存します。
ファイル構造に関連するアクセス パスが 1 つしかない場合、ファイル システムはデータベースよりも高速である可能性があります。ファイルシステムで利用可能なキャッシュがあることを確認してください。
もちろん、データベースの優れた点はすべて失われます。 - トランザクション - データにインデックスを付ける柔軟な方法。したがって、柔軟な方法でかなり高速にデータにアクセスできます。- 柔軟な (醜い) クエリ言語 - 高い回復性。
スケーリングは、使用するファイルシステムに大きく依存します。私の知る限り、ほとんどのファイルシステムには、ファイル数 (合計またはディレクトリごと) に何らかの上限がありますが、新しいファイルシステムでは、これはしばしば非常に高くなります。ディレクトリを適切なサイズに保つために、ディレクトリ構造を持つ何百、何千ものファイルの場合、適切に機能するファイルシステムを見つけることができるはずです。
@Eric のコメント: 必要なものによって異なります。クエリごとに正確なファイルのコンテンツのみが必要であり、決定論的な方法でファイルの場所と名前を決定できる場合、直接アクセスはデータベースよりも高速です。これはおおよそ次のとおりです。
それを見ると、メモリ内にインデックスと追加の行があり、キャッシュが非効率的になっています。データベースの高速化はどこから来るのでしょうか?
データベースは、一般的なケースに最適です。しかし、特殊なケースがある場合は、ほとんどの場合、ある意味でより優れた特別なソリューションがあります。
RDBMS を使用しない方がよい場合は、他のオープン ソースのキー値またはドキュメント DB (非リレーショナル DB) を試してみませんか。
あなたの投稿から、私はあなたがリレーショナル データベースの ACID プロパティに従わないことを理解しています..独自のファイル システム実装の代わりに、他のキー値データベース (mongodb、coutchdb、またはハイパーテーブル) を適応させる方が良いでしょう.. パフォーマンスが向上します既存のアプローチより..
注:私もこれの専門家ではありません.. MongoDB の作業を開始したばかりで、同様のシナリオで役立つことがわかりました。これらのアプローチを認識していない場合に備えて共有したかっただけです