sql - ファイルまたはデータベースサーバーからデータにアクセスする方が高速ですか？

Question

フォルダとファイルで構成される静的データベースがある場合、これがCGIスクリプトで使用されることを考えると、アクセスと操作はSQLサーバータイプのデータベースよりも高速ですか？

ファイルやフォルダを操作する場合、パフォーマンスを向上させるための秘訣は何ですか？

score 67 · Accepted Answer

群衆に依存することに追加します。

これは、一般的な答えがない種類の質問ですが、目の前の状況に大きく依存します。DB のオーバーヘッドと DB 接続の信頼性の問題が相まって、フラットファイルを使用する方が良い選択になったため、最近、一部のデータを SQL データベースからフラットファイルシステムに移動しました。

選択する際に自問する質問には次のようなものがあります。

データをどのように消費していますか? たとえば、入力された順序で最初から最後の行まで読み取るだけですか? それとも、複数の条件に一致する行を検索するのでしょうか?
1 回のプログラム実行中にデータにアクセスする頻度は? サリンジャーが著者であるすべての本を入手するために 1 回行くか、それとも複数の異なる著者を入手するために数回行くか? いくつかの異なる基準で複数回行くことはありますか?
どのようにデータを追加しますか? 最後に行を追加することはできますか?それは私の検索に最適ですか?それとも再ソートする必要がありますか?
コードは 6 か月でどの程度論理的に見えるでしょうか? 私がこれを強調するのは、これが物事を設計する際に忘れられがちだからです (コードだけでなく、この趣味の馬は、実際には海軍の整備士として機械技術者をののしっていた時代のものです)。私があなたのコードを保守しなければならない 6 か月後 (または、別のプロジェクトに取り組んだ後に保守する必要がある場合)、どの方法でデータを保存および取得するのがより理にかなっているでしょうか。フラットファイルから DB に移行すると、効率が 1% 向上しますが、コードを更新する必要がある場合は、実際に改善されたかどうかを把握するのに 1 週間追加されます。

score 29 · Accepted Answer

原則として、データベースはファイルよりも低速です。

ファイルの索引付けが必要な場合、カスタマイズされた索引付け構造にハードコーディングされたアクセスパスは、正しく行うと常に高速になる可能性があります。

しかし、ファイルベースのソリューションではなくデータベースを選択する場合、「パフォーマンス」は目標ではありません。

データベースが提供する利点のいずれかがシステムに必要かどうかを自問する必要があります。その場合、わずかなパフォーマンスオーバーヘッドはまったく問題ありません。

そう：

複数のユーザーと同時更新に対処する必要がありますか? （まあ、あなたはそれが静的だと言いました。）
さまざまな角度からデータを簡単にクエリするための柔軟性が必要ですか?
複数のユーザーがいて、既存のセキュリティモデルを利用することでメリットが得られますか?

基本的に、問題はどちらが開発しやすいかということです。2 つのパフォーマンスの違いは、開発時間を無駄にする価値はありません。

score 24 · Accepted Answer

情報が何であるか、およびアクセスのパターンと規模がどのようなものであるかによって異なります。リレーショナルデータベースの最大の利点は次の 2 つです。

キャッシング。非常に賢くない限り、DB サーバーのキャッシュほど良いキャッシュを作成することはできません。
オプティマイザ。

ただし、特定の特殊なアプリケーションでは、ファイルとフォルダーのデータストアと比較して、これら 2 つの利点のいずれも現れません。

ファイル/フォルダーに関しては、トリックは次のとおりです。

頻繁に要求されるファイルの内容をキャッシュする
小さなディレクトリを用意します (深くネストされた小さなディレクトリ内のファイルは、大きなディレクトリの内容を読み取るのに時間がかかるため、フラットな構造のファイルよりもはるかに高速にアクセスできます)。
他にもより高度な最適化があります (ディスク全体のスライス、ディスク内の別の場所または別のパーティションへの配置など) - しかし、そのレベルが必要な場合は、最初にデータベースを使用する方がよいでしょう。

score 14 · Accepted Answer

私の少しの経験から、サーバーベースのデータベース (ローカルマシンで提供されているものであっても) は、ローカルファイルシステムに比べてスループットが非常に遅い傾向があります。ただし、これはいくつかの要因に依存し、そのうちの 1 つは漸近的な複雑さです。ファイルの大きなリストをスキャンすることと、インデックス付きのデータベースを使用してアイテムを検索することを比較すると、データベースが勝っています。

私の少しの経験は PostgreSQL です。300 万行のテーブルがあり、わずか 8,000 レコードを更新しました。8秒かかりました。

「時期尚早の最適化は諸悪の根源である」という引用については、私はそれを一粒の塩で受け止めます。データベースを使用してアプリケーションを作成し、それが遅いことがわかった場合、ファイルシステムベースのアプローチまたは他の何か (SQLite など) に切り替えるのに非常に長い時間がかかる場合があります。最善の策は、ワークロードの非常に単純なプロトタイプを作成し、両方のアプローチでテストすることです。この場合、どちらが速いかを知ることが重要だと思います。

score 7 · Accepted Answer

他の人が指摘したように：それは依存します！

目的に対してどちらがよりパフォーマンスが高いかを本当に調べる必要がある場合は、サンプルデータを生成して各形式で保存し、いくつかのベンチマークを実行することをお勧めします。Benchmark.pm モジュールは Perl に付属しており、次のようなものと並べて比較するのがかなり簡単になります。

use Benchmark qw(:all) ;

my $count = 1000;  # Some large-ish number of trials is recommended.

cmpthese($count, {
    'File System' => sub { ...your filesystem code... },
    'Database'    => sub { ...your database code... }
});

入力perldoc Benchmarkして、より完全なドキュメントを取得できます。

score 4 · Accepted Answer

サイト構造が適切であれば、画像に関しては db の代わりにファイルを使用すると非常に便利です。一致するデータを表すフォルダーを作成し、その中に画像を配置します。たとえば、記事サイトがあり、記事を db に保存します。画像パスを db に配置したり、1,2,3.. のような主キーでフォルダーに名前を付けたり、画像を内部に配置したりする必要はありません。電子書籍、音楽ファイル、ビデオ、このアプローチはすべてのメディアファイルで使用できます。何かを検索しない場合、同じロジックがxmlファイルで機能します。

score 2 · Accepted Answer

何をしているかによっては、ファイルにすばやくアクセスするには、mmap が非常に便利です。これについては、 Effective Perlブログで、丸呑みではなくメモリマップファイルとして書きました。

ただし、データベースサーバーの方がはるかに高速であると期待しています。何をしているのか、どのような種類のデータにアクセスする必要があるのかなどがわからない場合、何が高速になるかを言うのは困難です.

score 2 · Accepted Answer

これは、データのプロファイルと、データにアクセスするために使用するロジックによって異なります。名前付きノードを単に保存して取得する必要がある場合は、ファイルシステムベースのデータベースの方が高速で効率的です。(その目的で Berkeley DB を参照することもできます。) インデックスベースの検索を行う必要がある場合、特にキーに基づいて異なるデータセットを結合する必要がある場合は、SQL データベースが最適です。

あなたのアプリケーションにとって最も自然と思われるソリューションなら何でも構いません。

score 2 · Accepted Answer

他の人が言ったように、データのサイズと性質、およびデータに対して実行する予定の操作によって異なります。

特にCGI スクリプトの場合、すべてのページビューでデータベースサーバーに接続するためのパフォーマンスヒットが発生します。ただし、素朴なファイルベースのアプローチを作成すると、パフォーマンスの問題が簡単に悪化する可能性があります;-)

Berkeley DB File ソリューションだけでなく、 SQLiteの使用も検討できます。これにより、ローカルファイルに保存されているデータベースへの SQL インターフェイスが作成されます。DBI と SQL でアクセスできますが、サーバー、構成、またはネットワークプロトコルはありません。これにより、将来データベースサーバーが必要になった場合 (例: 複数のフロントエンドサーバーを持つことに決めたが、状態を共有する必要がある場合) に移行が容易になります。

詳細を知らなくても、SQLite/DBI ソリューションを使用してパフォーマンスを確認することをお勧めします。これにより、かなり簡単な起動と適切なパフォーマンスで柔軟性が得られます。

score 2 · Accepted Answer

他の人が言ったように、DBはツールであり、オーバーヘッドが発生しますが、データが静的で読み取り専用のデータである場合、ファイルからディレクトリを読み取る方が高速になります:ファイルの名前は .csv データベースでは、データベース内の同じレコードを見つけるために、列に「日付」としてインデックスを付けました。毎日、30,000 ～ 50,000 のレコード/行と、100 列のさまざまなタイプのデータ (90% フロート) があります。

DB 情報: PostgreSQL 11.5、16 GB の RAM

  Table:
    335,162,867 records
    Table size: 110GB
    Index size: 7GB
    Total size: 117GB
  Files:
    Number of files: 8033
    Total Files size: 158GB
    Number of records/lines per file/date: 30K - 50K

ファイルからランダムな日付 (1986 ～ 2019 年) のデータを読み取ると、PostgreSQL で同じ日付のデータを読み取るよりも常に 4 ～ 5 倍高速でした。

score 2 · Accepted Answer

データベースは確かに高速になる可能性があり、

SQLite テストを引用すると、

SQLite は、fread() または fwrite() を使用してディスク上の個々のファイルから同じ BLOB を読み書きするよりも、小さな BLOB (サムネイル画像など) の読み取りと書き込みを 35% 高速¹ に実行します。

さらに、10 キロバイトの BLOB を保持する単一の SQLite データベースは、BLOB を個々のファイルに格納するよりも約 20% 少ないディスク容量を使用します。

SQLite データベースから作業する場合、open() および close() システムコールは 1 回だけ呼び出されるのに対し、open() および close() は blob ごとに 1 回呼び出されるため、パフォーマンスの違いが生じます (私たちは信じています)。個々のファイル。open() と close() を呼び出すオーバーヘッドは、データベースを使用するオーバーヘッドよりも大きいようです。サイズの縮小は、個々のファイルがファイルシステムブロックサイズの次の倍数にパディングされるのに対し、ブロブは SQLite データベースにより密にパックされるという事実から生じます。

この記事の測定は、2017 年 6 月 5 日の週に 3.19.2 から 3.20.0 の間のバージョンの SQLite を使用して行われました。SQLite の将来のバージョンでは、さらに優れたパフォーマンスが期待される場合があります。

sql - ファイルまたはデータベースサーバーからデータにアクセスする方が高速ですか？

13 に答える 13

Related

Reference