何が良い/速いですか?MySqlまたはFileSystem?


9

人のディレクトリであるWebサイトを想像してみましょう。それぞれの人にプロフィール写真と伝記があるかもしれません。

私はSQLクエリの方が優れていることを認めますが、一般的には何がより速く、より少ない処理能力を使用します。

ファイルが存在するかどうかを確認してから開くには、または

MySqlをチェックして、略歴が存在するかどうかを確認し、表示します。

上記の場合、ファイルシステムはmysqlデータベースをスモークします。

データベースを読み取り専用の区切りテキストファイルにするとどうなりますか?

この場合、何が速くなりますか?

txtファイルにレコードが多すぎる場合、MySqlを使用する方がよい特定のポイントはありますか?


4
あなたのディレクトリに10万人がいて、1978年に生まれた人々の経歴が欲しいとしましょう。煙はどこから来ると思いますか?ファイルシステムで100Kファイルを開くか、SQLで単一のクエリを開きますか?
ypercubeᵀᴹ

1
@ypercube-私はあなたに同意しますが、Linux OSの場合、各プロセッサで同時に開くことができるファイルには制限があります。
Satish Pandey 2012

回答:


17

ファイルシステムは、オペレーティングシステムが一種のインデックスを保持しているため、特定のファイルを探している場合に役立ちます。ただし、txtファイルの内容はインデックスに登録されません。これは、データベースの主な利点の1つです。もう1つは、リレーショナルモデルを理解することです。これにより、データを何度も繰り返す必要がなくなります。もう1つはタイプの理解です。txtファイルがある場合は、数値、日付などを解析する必要があります。

したがって、ファイルシステムは一部の状況では機能する場合がありますが、すべてが機能するわけではありません。


+1。また、ファイルシステムは、ファイル名やその他の属性の部分的な検索には適していません。ファイルの数が非常に多い場合、この方法でファイルを検索するときに問題が発生する可能性があります。本質的にトランザクションではなく、ドキュメントの添付ファイルや画像ファイルなど、コンテンツが常に1つの単位としてアクセスされるデータには、ファイルシステムを使用するのが一般的だと述べました。
NoChance 2012

12

それは本当にあなたが何をしているかに依存します。一般に、ファイルを読み取り用に開くことができる速度は、ネットワーク接続を確立できる速度よりも優れています。したがって、非常に単純な操作の場合、ファイルシステムは明らかに高速です。オーバーヘッドが少ないので、ファイルシステムはおそらく生の読み取りスループットでもRDBMSよりも優れています。実際、考えてみると、データベースは、生のスループットの点で、それが置かれているファイルシステムよりも速くなることはありません。

非常に複雑な操作の場合、ファイルシステムは非常に遅くなる可能性があります。例えば:

この10億行のファイルから10行を読み取り、この他のファイルで一致する行を検索します。あなたがこれをしなければならないなら、私はあなたに同情します。ただし、優れたデータベースサーバーには、これを迅速かつ適切に行うための戦略があり、車輪を再発明する必要はありません。

さらに、あなたは本当に自分がをしているを理解する必要があります。どのデータを保存していますか?どのように変換しますか?100kの画像ファイルの場合、ソリューションは100k人のディレクトリの場合とは非常に異なります。(LDAPかもしれませんか、それともSQLデータベースですか?おそらくあなたが何をしているのかに依存します。)ここで重要なのは、あなたがしていることに一致し、いくつかの最も速いと思われるものではなく、用途を追加する余地を与えるツールを選択することです。むしろ抽象的なユースケース。データベースは素晴らしいツールですが、このような質問に対して適切な答えを得ることができません。

最後に、時期尚早の最適化はすべての悪の根源です。ここで有用なツールを選択し、残りを後で理解してください。


もちろん、2つの仮想インスタンスが仮想NICを介して通信している場合、またはアプリケーションサーバーと同じインスタンスで実行されているDBの場合、妥当な量のメモリがあれば、データベースの読み取りがfsの読み取りよりも高速であることを確認できます。ファイルシステムに依存している場合、fsドライバーのキャッシング/ページ置換アルゴリズムに翻弄されるため、データベースはメモリのセグメントをスワップアウトしないように予約できるため、アプリのレイテンシが最初に必要になるためです。 。スワッピングが有効になっていると仮定します。
パルティアンショット

あなたの最後の行は私を後押しします... @Chris Travers
Biswadeep Sarkar '19 / 12/19

5

ファイルシステムは最初はもっと速いかもしれませんが、私はそれを疑っています。ただし、データサイズが増加すると、パフォーマンスを維持するためにファイルシステムを再構築する必要が生じる可能性があります。複数の属性にインデックスを付ける明らかな機能に加えて、データベースは拡張性が向上する傾向があります。

検討しているものと同様に機能するWebキャッシュは、ディレクトリツリーを使用してパフォーマンスを維持します。また、規模が比較的固定されている傾向があるため、規模の拡大に対応する必要はありません。

この種のアプリケーションの場合は、データベースがユーザーのニーズにより適合するため、データベースから始めます。長い目で見れば、より適切にスケーリングされます。ほとんどのファイルシステムと比較して、データベースはスペース効率も高くなります。


4
まあ、それは問題ではありません。値をリストしてオフセットを求める別のファイルを作成してみましょう。実際、これをbtreeで検索するために最適化できます。そうすれば、ファイルを読み取る場所がわかります。次に、異なる区切りファイル間で結果を結合できる小さなプログラムに宣言型クエリ言語を追加し、次にACIDコンプライアンスを追加する必要があると思います。;-)
Chris Travers、

@ChrisTraversそこに行って、それをやった、そして私はデータベースを使用してはるかに幸せです。
BillThor

5
この考えは「UNIXから学ばない人は、それをひどく再発明する運命にある」という流れに沿ったものでした。
Chris Travers、2012

1

私はいつもこれらのフォーラムにアクセスして、ファイルシステムがデータベースほど速く実行できないという重いデータベースの教祖をすべて読むことが好きです。まったく逆に、適切にレイアウトされたツリー、適切に設計されたハッシュテーブル、およびオブジェクトとしてファイルに保存すると、データベースと同じ速度でテストできます。適切に設計されたハッシュテーブルとディレクトリツリーが常に勝ちます。オーバーヘッドがはるかに少なくなります。最近、私はデータベース駆動型プログラミングから離れて、単純さとプログラムの移植性のためにファイルツリーにもっと取り組んでいます。DBがないということは、ツリーを圧縮して移動するだけの簡単なバックアップを意味します。小規模なアプリケーションを使用する1回限りのクライアント向けに、この方法でプログラムすることは非常に便利です。大きな写真を見て、自分で設計する時間があるのか​​、それともdbのようにすでにそこにあるものを活用するだけの時間があるのか​​。私は個人的にオブジェクトをファイルに保存し、後でそれらを使用するのが好きです。テーブルのサイズに注意し、RandomAccessFileを使用してデータベースのようにすばやくレイアウトしてハッシュテーブルオブジェクトに分割できるようにすることを検討してください。 。楽しい。コードによっては、ファイルに格納するデータがメモリ使用量を2倍に消費することを覚えておいてください。ハッシュテーブル自体と、通常は表示するために消費する場所。


3
これに対して私が考えることができる唯一の適切な対応はこれです。
Mark Storey-Smith

3
@ MarkStorey-Smith、これは興味深いリンクですが、このソリューションがどこかでDunning-Krugerスペクトルにあると示唆するのはおかしいですか?:)
David Mann
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.