データベースは内部でどのように動いているのですか？[クローズド］

質問

私はここ数年、データベースを扱う仕事をしており、かなり使いこなせるようになったと思いたいところです。しかし、最近、Joelの リークする抽象化の法則 を読んでいて、データベースから欲しいものを得るためにクエリを書くことはできても、データベースが実際にそのクエリをどう解釈するのかが全く分からないことに気づきました。どなたか、データベースが内部でどのように動作しているかを説明する良い記事や本をご存じないでしょうか？

私が興味を持っているいくつかの具体的な事柄は、以下の通りです。

• データベースは、select 文にマッチするものを見つけるために、実際に何をするのでしょうか？
• データベースは、いくつかの "where key1 = key2" ステートメントを持つクエリとどのように結合を異なって解釈するのでしょうか？
• データベースは、どのようにすべてのメモリを保存しているのですか？
• インデックスはどのように保存されますか？

どのように解決するのですか？

データベースは実際に何をするのでしょうか？ 何がselect文にマッチするかを見つけるために 文にマッチするものを見つけるために、データベースは実際に何をするのでしょうか？

ぶっちゃけた話、ブルートフォースの問題です。単純に、データベース内の各候補レコードを読み込んで、フィールドに式をマッチングさせます。つまり、"select * from table where name = 'fred'" とすると、文字通り各レコードを実行し、"name" フィールドを取得して、それを 'fred' と比較するのです。

ここで、もし "table.name" フィールドがインデックスされていれば、データベースは（おそらく、しかし必ずしも）最初にインデックスを使用して、実際のフィルタを適用する候補レコードを見つけます。

これにより、式を適用する候補レコードの数が減ります。そうでない場合は、いわゆる "テーブル スキャン"、つまり、すべての行を読み取ることになります。

しかし、基本的に、候補となるレコードをどのように見つけるかは、実際のフィルター式をどのように適用するかとは別であり、明らかに、いくつかの巧妙な最適化が可能です。

データベースは結合をどのように解釈するのでしょうか。 を持つクエリに対して、データベースはどのように異なる解釈をするのでしょうか？ ステートメントを含むクエリとはどのように解釈されますか？

結合は新しいquot;擬似テーブルを作成するために使用され、そのテーブルに対してフィルタが適用されます。つまり、フィルタ条件と結合条件があります。結合条件はこの擬似テーブルの作成に使用され、それに対してフィルタが適用されます。ここで、結合を解釈する際にも、フィルタと同じ問題が発生します。ブルートフォース比較とインデックス読み取りを行い、擬似テーブルのサブセットを構築します。

データベースはどのようにそのすべての メモリをどのように保存するのでしょうか?

優れたデータベースの鍵の1つは、I/Oバッファをどのように管理するかということです。しかし、基本的には RAM ブロックをディスク ブロックに一致させます。最近の仮想メモリ マネージャーでは、よりシンプルなデータベースでは、メモリ バッファー マネージャーとして VM にほぼ依存することができます。ハイエンドのDBは、これらすべてを自分自身で行います。

インデックスはどのように保存されるのですか？

B+Treesが一般的で、それを調べる必要があります。これは、何年も前からある、わかりやすい手法です。ノードへの一貫したアクセスに加え、すべてのリーフ ノードがリンクされているため、キー順にノードからノードへ簡単にたどることができるのです。つまり、インデックスがあれば、データベース内の特定のフィールドに対して行が「ソート」されていると考えることができ、データベースはその情報を活用して最適化を図ることができるのです。これは、例えばインデックスにハッシュテーブルを使用した場合、特定のレコードに素早くアクセスできるようになるだけで、それとは異なるものです。B-Treeでは、特定のレコードだけでなく、ソートされたリスト内のあるポイントに素早くアクセスすることができる。

データベース内の行の保存とインデックスの実際の仕組みは、本当にとてもわかりやすく、よく理解されています。ゲームは、バッファを管理し、これらの基本的なストレージ イディオムを活用するために SQL を効率的なクエリ パスに変換することです。

そして、ストレージイディオムの上に、マルチユーザー、ロック、ロギング、トランザクションの複雑さがあります。