DBMS(Data Base Management System : データベース管理システム)
- データベースの機能を提供するソフトウェア
- データベースの抽象的な概念を実装レベルに落とした
- Oracle
- SQL Server
- DB2
- MySQL
- PostgreSQL
- Firebird
持続性とパフォーマンス
ログ先行書き込み(WAL : Write Ahead Log)
- 実データを書き込む前に、更新前レコードならびに、更新後レコードの情報を先にログに書き込むことで、障害発生時に実データに反映されているかどうかの確認ができる
- MySQL では
InnoDB ログ
と呼ぶ - 利点
- ディスクに対して連続的に書き込むため、ランダムに書き込むよりもパフォーマンスが良い
- ディスクへの書き込み容量・回数を減らすことができる
- データベースバッファを利用して、データベースのデータファイルへの変更を効率よく行える
データベースバッファ
- データファイルへの入出力をデータベースバッファ経由に一本化して単純化している
- MySQL の WAL
- クラッシュリカバリ
- クラッシュした際の状態
- WAL : 最後にコミットしたトランザクションの更新情報を持つ
- データベースバッファ : クラッシュにより内容はすべて失われる
- データベースファイル : 最後のチェックポイントまでの更新情報を持つ
- クラッシュ後、MySQL を再起動すると 3 と 1 のチェックポイント後の更新情報を用いて、データベースファイルをクラッシュ時までにコミットされた最新の状態まで戻す
- =>
ロールフォワード
- =>
- クラッシュした際の状態
PITR(Point-In-Time Recovery)
- ある時点からのデータ変更を含めたリカバリ
- Oracle
- REDO ログ
- MySQL
- バイナリログ
- PostgreSQL
- WAL ログ
バックアップ
- ホットバックアップとコールドバックアップ
- 論理バックアップと物理バックアップ
- 論理バックアップ
- SQL ベースのバックアップで、テキスト形式に準じるフォーマット
- mysqldump
- 物理バックアップ
- データ領域をそのままダンプ、バイナリ形式に準じるフォーマット
- 論理バックアップ
- フルバックアップと部分(増分・差分) バックアップ
SQL 処理フロー
- アプリケーションから SQL を送信
- 構文解析(Parse)
- SQL が文法的に間違っていないかチェックを行う
- ライブラリキャッシュを検索してみつかれば利用(
ソフトパース
) - 見つからなければ生成(
ハードパース
)- CPU 負荷がかかる
- 文法解析
- SELECT される列
- FROM 句の内容
- WHERE 条件
- etc...
- オブジェクト解析
- 列は存在するのか
- FROM 句はの対象はビュー、それとも表なのか
- 索引はついているのか
- 権限はどうか
- etc...
- このときディクショナリキャッシュに読み込まれた権限やオブジェクトを参照される
- 解析後ライブラリリキャッシュに保持
- 最適な
実行計画
の生成- 必要とするデータにどういう風にアクセスするか決める
- 実行計画を決める内部プログラムを
オプティマイザ
と呼ぶ- 最も早く SQL を実行できるためには内部的にどうように検索するのが良いかを推定する
- どのインデックスを使うか
- 抽出と結合をどちらが先にやったほうが早いか
- フルテーブルスキャンを行なうべきか
- クエリオプティマイザがインデックスを検索しないほうが早いと判断した場合に、インデックスは無視される
- オプティマイザは実行計画を立てるときに
統計情報
を利用している- テーブルの行数・列数
- 各列の列長とデータ型
- テーブルのサイズ
- 列に対する主キーや NOT NULL 制約の情報
- 列の値の分散や偏り
- etc...
- 最も早く SQL を実行できるためには内部的にどうように検索するのが良いかを推定する
- 実行計画による文の実行(Execute)
- 行データの取りだし返却(Fetch) ※ SELECT 文実行時のみ
- 処理対象のデータがデータベースバッファキャッシュ上にある場合はデータベースバッファキャッシュから返却
- データベースバッファキャッシュ上にない場合はデータファイルからデータベースバッファキャッシュ上に読み込まれ返却
- 結果セットを転送
- 実行計画の表示