データベースの実装について

Question

データベースの実装について疑問点がうまれたので質問いたします.
例えばMySQLServerでは保存データをファイルとして保存していると思います.しかしこの場合高速な読み書きを繰り返し行おうとする場合、ファイル入出力部分がかなりのボトルネックになると思います。

この部分の実行時間がロスとなることについては許容しているのでしょうか？それとも何らかの工夫が凝らされているのでしょうか？初歩的な質問ですいません。

Answer 1

DBMS では当然工夫がされています。実装技法として教科書に載ってます。ディスクI/Oに関係するものでしたら、キャッシュ、グループコミット、チェックポイント、メモリマップドI/Oくらいでしょうか。DBMSはディスク I/O だけでなく、いろいろな技法のデパートです。本屋さんでデータベースの教科書を立ち読みして、読みやすいと思われるものを探されることをおすすめします。

Answer 2

データの入出力部分ではデータ検索およびデータの送受信処理が行われて
いるので当然、ボトルネックになる可能性があります。

MYSQL側でなんらかの配慮が行われているわけではなく、全体のシステム設計の
上で状況に応じて対策を打つ必要があります。

アプリケーションロジック, クエリ, MySQL, OS, CPU, Memory, Disk, Network
などボトルネックになる可能性のある箇所は色々とございます。
ご参考まで

Answer 3

ファイル入出力部分がかなりのボトルネックになると思います。

なります。一般的にIOが処理速度のボトルネックになります。
（科学計算や機械学習など、純粋に計算量が多いジャンルでは違いますが）

ロスとなることについては許容しているのでしょうか？
それとも何らかの工夫が凝らされているのでしょうか？

小規模ならたんに許容するかもしれませんが、
大規模なサービスでは工夫されています。

データベースエンジニア（インフラエンジニアという区分も多い）
というDB関連の専門職がありますから、それだけ工夫の余地が大きいです。

大きい会社だと「DB一筋20年、インフラの源さん」みたいな人がいて、
職人的なDBのチューニングをするわけです。これはたとえ話ですが。

そこまでいかなくても、単純にIOの回数を減らすとか、
初歩的な工夫でも速度が劇的に違ってくる場合があります。

---

そもそも、なぜデータベースを使うのかといえば、たんに高性能だからです。

DBは検索などが最適化されているので、一定以上データ量が多ければ、
テキストファイルやCSVファイルより、DBの方が処理速度が圧倒的に速いです。

もし、そんなに高性能には思えないとしたら、共用レンタルサーバのイメージでしょう。
「DBが遅いせいで、ワードプレスが重くて重くて……」とか年中言われてますよね。

これは価格を安くするためサーバにアカウントを詰め込んいて、
たとえば100人で使ってたら、本来の性能を発揮できないわけです。

Answer 4

ファイル入出力部分がかなりのボトルネックになると思います。

ファイルの読み書き自体の速度は意外にも速いものです。
Apacheではアクセス履歴を常にログファイルとして書き出していますが、よほど高性能なサーバーでない限り気にする必要なく使えます。

この部分の実行時間がロスとなることについては許容しているのでしょうか？

どのようなデータベースに保存するにしても、基本的にはファイルの入出力がボトルネックです。
キャッシュとしてメモリを利用する機能や、ファイルの代わりにインメモリで全て動かすというテクニックはありますが、
実運用では大量のデータをバックアップする必要があり、必ずファイル入出力の問題にぶつかります。

キャッシュにメモリを使う：「memcached mysql 連携」等でぐぐってみてください。
インメモリで動かす：「sqlite inmemory」等でぐぐってみてください。

それとも何らかの工夫が凝らされているのでしょうか？

その通り。
結局はファイルで管理していますが、必要最小限な読み書きを行う実装が至る所にあります。
なので素人がテキストファイル等を作って管理することと比較すると、信じられない程キビキビと動作します。
興味がある場合、私もそんなに詳しくは解説出来ないので個々の実装を読み進めてみてください。

Answer 5

質問の回答としては少しズレますが、私の知っている情報だけ書き残します。

I/Oのオーバーヘッドのボトルネックを解決するため、
メモリ上にデータを保存する方法があります。

CREATE TABLE テーブル名(カラム名 型) ENGINE=MEMORY;

MySQL :: MySQL 5.6 リファレンスマニュアル :: 15.3 MEMORY ストレージエンジン
https://dev.mysql.com/doc/refman/5.6/ja/memory-storage-engine.html

Answer 6

保存データをファイルとして保存していると思います

中にはパーティションまるごとをDBMS専用とする場合もありますね。
その際、ファイルにする場合とどれくらいの性能差があるかは
知りませんが、そっちが主流になっていないところをみると
労力のわりに大差ないのかもしれません。

黎明期には「リレーショナルデータベースは遅い」などと
いわれていましたが、それを克服するための工夫が
ファイルI/Oくらいは問題にならないくらいに
こらされているのかもしれません。

あと、ハードウェアがいろんな面で高性能になってきて
多少のソフトウェア的な性能は関係ない(というとアレですが)
くらいなのかなあ、って気もしてます。

Answer 7

一昔前まではrawデバイスと言って、ファイルシステムを介さずにディスクI/OをするDBが多かったように思います。
DB側の性能向上や様々な進化があっても、直接ディスクのI/Oを制御する速度的優位や遅延書き込みが発生しないという利点はまだあると思うのですが。
ハードウェア全体の性能が上がってその辺のメリットが小さくなったのでしょうか。

Answer 8

わたしはOracleのパフォーマンスチューニングを担当する^n^n^n^n押し付けられることが多いです。笑い
ハードウェアは進化しているのに，なぜパフォーマンスチューニングを続けるのか 5年前の資料
MySQLパフォーマンスチューニング
など、パフォーマンスチューニング をキーワードにググると興味深い情報が得られますよ。