読書ノート(リレーショナル理論とかは飛ばして、まず内部構造の部分からノート。現代のRDBMSは与えられたSQLからアクセスするデータ量、データの分布、インデックスやパーティショニングの有無などから自動的にデータ取得アルゴリズムを決定する。(SQLは宣言的な言語。「こういうデータを取得」は含まれているが、「こうやってデータを取得」は含まれていない。)DBMSは次のように処理をすすめる。表示SQLの解析〜動作まずはSQLの実行計画をみてみよう。句をつけると表示できる。注目したいのはインデックススキャン/テーブルスキャンどちらをつかっているか結合に使う手法として何を使っているか(ネステッドループ、ソート/マージ、ハッシュ)インデックス(本書には書いてないけど、調べたので補足)インデックスはテーブルから高速にデータを取り出すための仕組み。インデックスが存在しない場合、毎回すべてのレコードを走査する必要がある。インデックスは1つのカラムだけで作ることもできるが、複数のカラムを組み合わせた複合インデックスも定義可能。複合インデックスを使うときは、その複合インデックス定義に使った順番でカラムを検索に使う必要がある。順番さえ守っていれば、すべてのカラムを使わずに途中まででもインデックスは使われる。(飛ばすのはNG)よく使われるインデックスには次のようなものがある。B-TreeインデックスB-Treeを使ったインデックス。構造上、カーディナリティの高い(=特定のキーが偏って現れたりせず、「バランス良く」現れている)場合に有効である。(Balancedだけに?)ハッシュインデックスハッシュ関数を使い、キーの値とレコードを含むページを直接結びつける。範囲検索には使うことができない。ハッシュ関数を自前で定義することで、性能のチューニングが行いやすい。ビットマップインデックスキーのとりうる値が限られている(=カーディナリティが低い)場合、各値に対して「n番目のレコードがその値を取るのであれば1,そうでなければ0」というビット列を作る。操作時は、このビット列を読み、1が現れた位置のレコードを取得する。どの場合も、インデックスの作成・更新にはコストがかかる。このため、使わないインデックスを定義するのは挿入更新を遅くするだけである。実現するアルゴリズムは3種類。ネステッドループ結合T1とT2、2つのテーブルがあった場合、T1の各レコードに対してT2の全レコードとの比較を行う。結合項目の値が一致しているものを探す。コストはT1、T2それぞれのレコード数の積に比例する。T1がインデックスのない件数の少ないテーブル、T2がインデックスの定義されている件数の多いテーブルである場合に有効。ハッシュ結合ネステッドループ結合のようにT1のレコード一件ごとにT2のレコードと比較を行う。このとき、結合する項目の値をキーとしてT2に対するハッシュテーブルを作成しておく。すると、全件を走査する必要がなくなり、高速になる。元のテーブルのサイズが大きいとハッシュテーブルがメモリ上に収まらないため、事前にパーティショニングを行う必要がある。ネステッドループ結合に比べたら時間計算量は減るが空間計算量が多い。結合キーによってあらかじめT1,T2をソートしておく方法。両方のテーブルのレコードに対してポインタを上から下へ動かすだけ。レコード操作はたった一回で済む。ソートされていない場合は、ソートのコストも考える必要がある。レコード数やインデックス定義の有無など個別のケースによっても速度は変わる。トランザクションいくつかの操作をひとまとめにした手続きの単位がトランザクション。トランザクションが途中まで実行されて、中途半端にデータが更新されることはあってはならない。トランザクションはコミットされる(トランザクションに含まれる更新がすべて反映される)かロールバックされる(トランザクションに含まれる更新がすべて破棄される)のどちらか。分断耐性この3つをすべて兼ね備えることはできない。RDBはCA、NOSQL系DBはCPまたはAPをもつ。(178)スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。