InnoDBのオプティマイザとロックの範囲の関係
MySQLのInnoDBのロックの挙動を色々調べていたのですが、レコードの数によってロックの範囲が変わる現象に頭を悩まされたので、メモがてら少しまとめてみます。
どこまでロックする？
以下のようなテーブルがあるとします。 id列に1〜6までの数値が入っています。
CREATE TABLE t ( `id` int unsigned NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB; INSERT INTO t VALUES (1),(2),(3),(4),(5),(6);
ではidが3より小さなレコードを取得するクエリを投げると、どのレコードをロックするでしょうか。
BEGIN; SELECT id FROM t WHERE id < 3 LOCK IN SHARE MODE;
1〜2のレコードでしょうか。それとも1〜3までロックするでしょうか。
実際にInnoDBロックモニタで確認してみると、実は1〜6全て(supremumレコード含む)に共有ロック(レコードのロック+ギャップロック)がかかっていることがわかります。
(cf. InnoDBロックモニタhttp://dev.mysql.com/doc/refman/5.1-olh/ja/innodb-general-monitor.html
BEGIN; SELECT id FROM t WHERE id < 3 LOCK IN SHARE MODE; SHOW ENGINE INNODB STATUS\G RECORD LOCKS space id 0 page no 45 n bits 80 index `PRIMARY` of table `D`.`t` trx id 0 63305 lock mode S Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0 0: len 8; hex 73757072656d756d; asc supremum;; Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0 0: len 4; hex 00000001; asc ;; 1: len 6; hex 00000000f748; asc H;; 2: len 7; hex 80000000340110; asc 4 ;; Record lock, heap no 3 PHYSICAL RECORD: n_fields 3; compact format; info bits 0 0: len 4; hex 00000002; asc ;; 1: len 6; hex 00000000f748; asc H;; 2: len 7; hex 8000000034011d; asc 4 ;; Record lock, heap no 4 PHYSICAL RECORD: n_fields 3; compact format; info bits 0 0: len 4; hex 00000003; asc ;; 1: len 6; hex 00000000f748; asc H;; 2: len 7; hex 8000000034012a; asc 4 *;; Record lock, heap no 5 PHYSICAL RECORD: n_fields 3; compact format; info bits 0 0: len 4; hex 00000004; asc ;; 1: len 6; hex 00000000f748; asc H;; 2: len 7; hex 80000000340137; asc 4 7;; Record lock, heap no 6 PHYSICAL RECORD: n_fields 3; compact format; info bits 0 0: len 4; hex 00000005; asc ;; 1: len 6; hex 00000000f748; asc H;; 2: len 7; hex 80000000340144; asc 4 D;; Record lock, heap no 7 PHYSICAL RECORD: n_fields 3; compact format; info bits 0 0: len 4; hex 00000006; asc ;; 1: len 6; hex 00000000f748; asc H;; 2: len 7; hex 80000000340151; asc 4 Q;;
なぜ全レコードにロックが掛かってしまうか
感覚的には1,2,3のみロックが掛かるように思えるので、不思議な挙動です。 自分も小一時間悩んだんですが、クエリの実行計画を見ると理由が推測できました。
EXPLAIN SELECT id FROM t WHERE id < 3 LOCK IN SHARE MODE\G > *************************** 1. row *************************** > id: 1 > select_type: SIMPLE > table: t > type: index > possible_keys: PRIMARY > key: PRIMARY > key_len: 4 > ref: NULL > rows: 4 > Extra: Using where; Using index
type = index なのでインデックスのフルスキャンです。 つまりInnoDBは全てのレコードをフルスキャンしMySQLサーバに渡し、MySQLサーバ側がWHERE句のフィルタ(id < 3)を処理します。 結果、InnoDBは全てのレコードにロックを掛けてしまったということです。
データ件数が多い場合には？
次にデータを1000件投入して同じことをやってみます。
データの投入には、ダミーデータを自動生成する拙作のdatagen_from_ddl(1) 参照 を使いました。
$ echo 'CREATE TABLE t ~~~;' | datagen_from_ddl -n 1000 | mysql -u root testdb
同様にSELECT文を実行すると、今度は予想通り1〜3までのレコードをロックしました。
BEGIN; SELECT id FROM t WHERE id < 3 LOCK IN SHARE MODE; SHOW ENGINE INNODB STATUS\G RECORD LOCKS space id 0 page no 7424 n bits 744 index `PRIMARY` of table `D`.`t` trx id 0 63312 lock mode S Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0 0: len 4; hex 00000001; asc ;; 1: len 6; hex 00000000f74f; asc O;; 2: len 7; hex 80000000340110; asc 4 ;; Record lock, heap no 3 PHYSICAL RECORD: n_fields 3; compact format; info bits 0 0: len 4; hex 00000002; asc ;; 1: len 6; hex 00000000f74f; asc O;; 2: len 7; hex 8000000034011d; asc 4 ;; Record lock, heap no 4 PHYSICAL RECORD: n_fields 3; compact format; info bits 0 0: len 4; hex 00000003; asc ;; 1: len 6; hex 00000000f74f; asc O;; 2: len 7; hex 8000000034012a; asc 4 *;;
EXPLAINを見てみます。
EXPLAIN SELECT id FROM t WHERE id < 3 LOCK IN SHARE MODE\G > *************************** 1. row *************************** > id: 1 > select_type: SIMPLE > table: t > type: range > possible_keys: PRIMARY > key: PRIMARY > key_len: 4 > ref: NULL > rows: 2 > Extra: Using where; Using index
type = range なのでインデックスを用いた範囲検索です。 つまり、id < 3がfalseになるまでInnoDBはレコードを取得 & ロックをかけていき、最終的に3のレコードを読み終了します。 よってロックされるのは1〜3のレコードのみで済みました。
まとめ
結局の所、ロックされる範囲はInnoDBがどこまでレコードを読んだかが決め手になります。 つまりロックの挙動を見る時は、オプティマイザがどうクエリを処理するかも同時に確認する必要があるという話でした。
DDLからダミーデータを自動生成するData::Generator::FromDDLを作りました
開発時に、ダミーデータを大量にDBに入れたい場面がありますが(SQLの実行計画やスケーラビリティを確認したい時など)、 DBのDDLを変更する度にデータ生成のスクリプトを書き直すのはめんどくさいですよね。
そこで、CREATE TABLE文やALTER TABLE文などのDDLから、適切なダミーデータを自動生成するData::Generator::FromDDLというCPANモジュールを作りました。
https://metacpan.org/pod/Data::Generator::FromDDL https://github.com/addsict/Data-Generator-FromDDL
インストール
$ cpanm Data::Generator::FromDDL
インストールすると datagen_from_ddl(1) というCLIのコマンドもインストールされるので、その使い方を説明したいと思います。
使い方
datagen_from_ddl(1) はDDLの書かれたファイル(もしくは標準入力)を受け取って、ダミーデータを作成するINSERT文を標準出力に出力します。
$ echo 'CREATE TABLE T (a int PRIMARY KEY);' | datagen_from_ddl -n 3 --pretty INSERT INTO `T` (`a`) VALUES (1), (2), (3);
標準出力に出力されるので、そのままMySQLクライアントなどにパイプで渡せます。
$ datagen_from_ddl -n 3 ddl.sql | mysql -u user -p mydb
また、外部キー制約がある場合には制約を満たす順番でデータを生成します。
-- ddl.sql CREATE TABLE A ( a int, FOREIGN KEY (a) REFERENCES B (b) ); CREATE TABLE B ( b int PRIMARY KEY );
このようにAテーブルのaカラムがBテーブルのbカラムを参照する場合、B→Aの順番にデータが生成され、aカラムはbカラムの値からランダムなものが選ばれます。
$ datagen_from_ddl -n 3 ddl.sql INSERT INTO `B` (`b`) VALUES (1), (2), (3); INSERT INTO `A` (`a`) VALUES (3), (2), (3);
その他、テーブルごとに異なるレコード数を生成するオプションなどがありますが、詳しくは datagen_from_ddl -h を見てみてください。
現状の制限
ツールをシンプルに保つためにいくつか制限があります。
- 制約(主キー制約など)は全て数値型のみ
- 複合主キーや複合外部キーには未対応
- 使用できるデータ型は以下の通り
- (unsigned) BIGINT
- (unsigned) INT
- (unsigned) MEDIUMINT
- (unsigned) SMALLINT
- (unsigned) TINYINT
- TIMESTAMP
- CHAR
- VARCHAR
- TINYTEXT
- TEXT
- MEDIUMTEXT
- ENUM
終わりに
アプリケーションの開発時にはDDLは都度変化していくものです。 そんな場面に是非一度使ってもらえたらなと思います。
バグ報告・機能要望などありましたらこちらまで！ https://github.com/addsict/Data-Generator-FromDDL
perldocのレンダリング結果をキャッシュして高速に表示するモジュールを作りました
perldocコマンドはPerlを書く人にとっては手放せないツールですが、 割と大きいPodファイル(DBI, perltoc, perlfunc, ...)を表示したり、Pod::Text::Color::Delightを使ってカラーリング表示しようとすると、表示するまで少し待たされるのが気になっていました。
そこで、 perldocで出力したフォーマット結果をキャッシュしておき、次回以降素早く表示するPod::Perldoc::CacheというCPANモジュールを作ってリリースしました。
https://metacpan.org/pod/Pod::Perldoc::Cache
インストール
$ cpanm Pod::Perldoc::Cache
使い方
perldocには-MオプションでPodファイルのフォーマッターを指定することができるので、そこに本モジュールを指定します。
一度目は通常通りの時間がかかりますが、二度目以降はキャッシュを読むようになります。
$ perldoc -MPod::Perldoc::Cache DBI # doesn't use cache $ perldoc -MPod::Perldoc::Cache DBI # use cache!
また、Pod::Text::Color::Delightなどの他のフォーマッターを同時に使いたい場合は-w parserオプションを使います。
$ perldoc -MPod::Perldoc::Cache -w parser=Pod::Text::Color::Delight DBI
一々こんな長ったらしいコマンド書いていられないので、alias もしくは PERLDOC環境変数でオプションを設定するといいと思います。
$ alias perldoc='perldoc -MPod::Perldoc::Cache -w parser=Pod::Text::Color::Delight' $ export PERLDOC='-MPod::Perldoc::Cache -w parser=Pod::Text::Color::Delight'
キャッシュ先
キャッシュの保存先はデフォルトで~/.pod_perldoc_cacheというディレクトリになっています。
そんな所に保存したくない！って方はPOD_PERLDOC_CACHE_DIR環境変数に保存先をセットしておけばそこを使ってくれます。
またキャッシュした際のPodの内容はハッシュ値を計算してあるので、元のPodが更新された場合に古いキャッシュは参照しないようになっています。
パフォーマンス
では実際にどれくらいPodの表示速度が速くなるか、実験してみました。 横軸がPodの行数、縦軸が表示までの秒数(小さいほうがベター)です。
赤が標準のperldocコマンドで実行した結果、青が本モジュールを使用した結果ですが、 赤がPodの行数に比例して遅くなってる一方、青は行数に関係なく常に高速に表示できていることがわかります。
終わりに
perldocのレンダリング結果をキャッシュするなんて相当ニッチな機能ですが、 体感的にも表示が少し速くなるので、とりあえず設定しておくといいと思います！
機能追加やバグ報告はgithubまでお願いします！
【iOS】ソースコードの編集内容を起動中のアプリにリアルタイムに反映させるiOS Runtime Previewを作りました
ソースコードで編集した内容を起動中のアプリにリアルタイムに反映させるiOS Runtime Previewというツールを作りました。
まるでインタプリタで実行しているかのように動的にアプリの挙動を書き換えることができます。
iOS Runtime Preview from Yuuki Furuyama on Vimeo.
使い方
iOS Runtime PreviewをGitHubからダウンロードします。
$ git clone https://github.com/addsict/iOSRuntimePreview.gitXcodeでiOSアプリを実行します。シミュレータでも実機でもokです。
デバッグエリアのポーズボタンを押して実行を一時停止します。
本ツールのスクリプト
preview.pyをLLDBのセッションにロードします。
previewコマンドを使用して、リアルタイムに編集したいコードを指定します。これで準備完了です。コマンド:
preview <プロジェクトディレクトリからのファイルパス>
上記で指定したコードを編集すると、起動中のアプリにリアルタイムに反映されます。
仕組み
LLDBのデバッグセッションの裏で対象ファイルの監視スレッドを動かし、アプリ起動以降にファイルに変更があれば前後のdiffを取ります。
diff情報を元に
- コードが追加された場合
- 追加されたラインにブレークポイントを張り、そこにヒットしたら追加されたコードをLLDBで評価して実行します。
- コードが削除された場合
- 削除されたラインにブレークポイントを張り、そこにヒットしたらPC(プログラムカウンタ)を次の命令のアドレスにセットし、削除されたコードは実行しないようにスキップします。
- 同一ラインのコードが変更された場合
- コードの削除とコードの追加が同時に行われたと判断し、上記の2つの処理を行います。
現状の制限
現状リアルタイムに反映できるソースファイルの変更には以下の制限があります。
- 新しいif文やfor文などの制御構文は実行できません
- 新しいメソッドを書き足すことはできません
- 新しい変数宣言は行えません
まとめ
LLDBでコードを評価したりプログラムカウンタを直接いじったりと、けっこう強引な作りとなっています(そのため場合によってはメモリアクセス違反が容易に起こり得ます)が、 UIの微妙な変更や、少しコードをいじって様子を見たい、といった場面で手軽に使えるかなと思います。
不具合報告や機能追加などはこちらまで！
XcodeでiOSアプリの実行時に任意のコードを挿入する
よりアップデートしたツールを作りました
→ http://addsict.hatenablog.com/entry/2014/02/21/214500
-----------------------------------------------------------------------------
「あのコードを追加するの忘れてた！」
「ここに変数のインクリメントが必要だ！」
など、実行後に必要なコードが足りてないことに気付くことありませんか？
そこで、アプリの実行時に任意のObjective-Cコードを実行バイナリに擬似的に追加できるツールを作りました。
iOS Runtime Preview from Yuuki Furuyama on Vimeo.
使い方
ツールをダウンロードします。
$ git clone https://github.com/addsict/inscode.gitXcodeでiOSアプリを実行します。シミュレータでも実機でもokです。
任意のタイミングでデバッグエリアのポーズボタンを押して実行を一時停止します。
本ツールのスクリプト
inscode.pyをデバッグエリアからLLDBのセッションにロードします。これで準備完了です。
inscodeコマンドをデバッグエリアで実行し、挿入したいコードを指定します。挿入されたコードはすぐに有効になります。コマンドのフォーマット:
inscode <ファイル名>:<行番号> '<挿入したいObjective-Cコード>'
このツールはアプリ自体にプラグインとして組み込む必要がないので、手軽に使えると思います。 是非試してみてください。
アプリのランキングをリアルタイムにGoogle Spreadsheetにレポートする
AppStoreのアプリのランキングをGoogle SpreadsheetにリアルタイムにレポートするGoogle Apps Scriptを書きました。
グラフも設定しておけば随時更新されるので、アプリリリース直後におすすめです。 Google Spreadsheetは簡単にメンバーと共有できるので便利ですね。
Mac OS X上でのv8のビルド時のリンクエラー
どのバージョンからかわかりませんが、v8をOS X上でドキュメントに書いてあるようにビルドするとコケます。 具体的には以下のようにビルドすると、
g++ -Iinclude hello_world.cc -o hello_world out/{architecture}/libv8_{base,snapshot}.a -lpthread
リンクで失敗します。
ld: symbol(s) not found for architecture x86_64
これはlibv8_base.aやlibv8_snapshot.a以外にもlibicudata.a, libicui18n.a, libicuuc.aなどのライブラリが必要だからです。
なのでそれらも全て一緒にビルドすればokです。
g++ -Iinclude hello_world.cc -o hello_world out/{architecture}/*.a -lpthread
もしくはスタティックライブラリのビルド時にi18nsupport=offにしておけば、libv8_base.aとlibv8_snapshot.aだけで問題なくビルドできます。
make x64.debug -j4 console=readline i18nsupport=off
ハマってしまったので共有。
