新ストレージエンジン Falcon のアーキテクチャ詳細技術解説 - MySQLカンファレンス2007


MySQLアーキテクチャの解説

  • ストレージエンジンがプラガブル
  • 5.1では共有ライブラリ化して動的に組み込めるようになる
  • InnoDBのかわりにfalconを使う

Falconとは

  • MySQL ABにより現在開発中の、トランザクション対応のストレージエンジン
  • 開発中で完成してない。alpha版
  • Jim Starkey氏を中心に開発
  • InnoDBをほぼ全ての点で上回ることを目指している
  • まもなくベータ版が登場。
  • MySQL 6.0で安定版を搭載予定
  • 思想：現代的なハードウェア環境をフル活用できるRDBMSを目指す
    • マルチコアCPU
    • 大容量メモリ
    • 低速なディスク、RAID

InnoDBとの主な差異

ほかのストレージエンジンとの比較

図

Falconのアーキテクチャ概略

  • 4つのメモリ領域に分けて開設 Record Cache, Page Cache, Log Cache, System Cache
  • できるだけ多くのレコードをRecord Cacheに乗るようにしてある
  • Record CacheはPage Cacheよりもオーバーヘッドが少ない

プロセス/スレッド

  • MySQLはマルチスレッド型アーキテクチャ
    • 接続1個に対してスレッドを1個割り当てて動作
  • Falcon専属の、バックグラウンドで動作するスレッドがある
    • チェックポイントの実行
    • キャッシュ管理（古いレコードの退避など）
  • mutexをラッピングして排他制御 (SyncObjects)
    • Read/Writeロックを導入
    • Readは他のReadをブロックしない（※行レベルロックとは別物）
    • 同時実効性を大きく高める効果がある
    • マルチCPUコア環境で重要な技術

ファイルの読み書き

シリアルログファイル、データファイル

  • シリアルログファイルはREDOログに相当。ただし、サイズは固定ではない
  • 未コミットの情報はデータファイルに書かれない
  • コミットした情報は最終的にデータファイルに反映される
  • Falconの「グループコミット」機能はきわめて高性能

表領域（テーブルスペース）

  • Oracleの秤量域と類似
  • 任意のファイルを割り当てられるため、I/O分散が可能
  • Falconのほかに、T.1以降でMySQL Clusterが...

インデックス構成

  • ルート -> ブランチ -> Leaf
  • クラスタ索引/セカンダリ索引という区別はない。全部この形
  • RecordNumberは現在4バイト固定（安定版までに変更予定）
  • ゆえにインデックスサイズは（クラスタ索引に比べて）さほど大きくならない
  • ページはI/Oの最小単位。サイズは可変（2KB-32KBとなっているが安定版までにどうなるかはわからない）

インデックス値の圧縮

  • 接尾辞の圧縮
    • 数値型：末尾のゼロを圧縮
    • 文字列型：末尾の空白を圧縮
  • 接頭辞の圧縮
    • 各ページの先頭のインデックス値は圧縮しない
    • 2番目以降のインデックス値は、開始何倍とが先頭のインデックス値と一致するかを調べ、その分を圧縮する
  • うまくいくと60%ぐらい圧縮できる
  • 圧縮処理をするので当然CPUは使っちゃう。on/off切り替え可能にするか検討中

インデックスアクセラレータ

  • commit時にインデックスを反映する
  • rollbackのオーバーヘッドが減る
  • 多少検索処理がオーバーヘッドになる
  • 以前ベンチマークしたときはボトルネックになっていたが今は大分改善された

レコードの取得

  • インデックスを検索し、レコード番号を取得
  • レコード番号から実際のレコードを取得
  • メインのレコードの取得はキャッシュから行われる

データ型と消費サイズ

  • GIS型を含む全MySQLデータ型をサポート
  • 整数型を含む全データ型が可変長として扱われる
  • 消費サイズはデータ型ではなく、実際の値に応じて変わる
  • どのデータ型であろうと値に応じて圧縮する

FalconはTEXT/BLOB型を別メモリ領域に管理する

AUTO_INCREMENTの動作の違い

  • FalconはInnoDBと違う。
  • FalconはMyISAMと同じ。
  • FalconとMyISAMは最後にInsertされた値をもとにする
  • InnoDBはmax関数でとれた値をもとにする

トランザクション、ロック、MVCC

  • 行レベルロッキング
  • SELECTはロックをかけない。更新系処理と競合しない。InnoDBも同じ
    • ブロックするSELECT FOR UPDATEもサポート
  • AUTO_INCREMENTの割り当てにテーブルロックをかけない
    • 重くなるので。5.1で改善される
  • 分離レベルとしてRead Commited, Repeatable Readをサポート
    • Serializableもサポート予定
  • ロックエスカレーションは発生しない。InnoDBも同じ
  • デッドロックの検知は自動で行う
  • ロックをかけないカラム、インデックスの追加/削除
  • ロストアップデートの自動検知
  • Next Keyロッキングは発生しない

ロストアップデートの自動検知

  • ロストアップデートとは
  • Falconの動作を、設定でInnoDBと同じにすることもできる（デフォルトで同一にする方向）

Next-Key Lockingとは (InnoDBのロック制御)

  • InnoDBログファイルとバイナリログの不整合をっふせぐために必要な実装
  • Insert INTO t1 .. SELECT .. FROM t2
    • t2に対して共有ロックをかける
  • UPDATE t1 SET xx WHERE non_index_column=x;
    • フルテーブルスキャンになる。スキャンしたレコード全体に対して排他ロックをかける
  • UPDATE t1 SET xx WHERE non_unique_index_column=x;
    • 当該インデックスと、その前後に対して排他ロックをかける
  • セッション１:INSERT INTO t1 SELECT * FROM t2
  • セッション２:INSERT INTO t2 VALUES(...)
    • セッション2がセッション1よりも前に終わったとする
    • バイナリログの中身は、順番が逆転する
  • Next-Key Lockingはこれを防ぐための実装

FalconではNext Key Lockingは発生しない

  • 同時実効性の低下は5.1で回避される

参考資料