きのこる庭

最近Win機を購入して 仮想環境どうしようかなーと思っていたのだが、「せっかくだし使い慣れたVagrantではなく思い切ってDockerでつくってみるか」と思い立ったので 勉強がてらDockerでサーバを立ててみた。

前提となる環境

* Windows 10 Home Edition
* Docker Toolbox

やったこと

1. Angular+Node用のDockerfile及びimageの作成
2. 1で作成したimageをもとにコンテナを作成しつつ、ホストマシン上でコードをいじれるようマウント
3. 実際にサーバを立ち上げてみる
4. ホスト上からコードに修正を加えてみる
(続きを読む…)

最近個人的にアプリケーションのみならず ミドルのあたりを触る機会が増えて、サーバのパフォーマンスを意識するようになってきた。
とはいえそのあたりの負荷テストに対する認識等、割とざっくりとやってしまっていたので ここらで一度しっかり落とし込んでおこうと考え、色々調べてみた。

特に「秒間にさばけるリクエスト数って、何をもって秒間●リクエストって言えるのか」 とか、
「秒間リクエストを測る際に、ユーザごとの端末の違いは考えなくて良いの？例えば有線のPCと3Gのスマホだと全然速度違うから、サーバ-クライアント間のコネクションが続く時間も変わってきてしまうんじゃないの？」
とか色々考えていたけど、調べているうちに自分なりに何となくハッキリしてきたので 情報の整理がてら共有。
もしかしたら認識誤りで 間違った事を言っているかもしれないので、その場合はご指摘いただければ本当に嬉しいです。
(続きを読む…)

久々の更新。
土曜日は これまで何となく使っていたVagrantを本格的にいじっていたけど、知れば知る程便利だなあ。
Vagrantfileって Gruntfileみたいに何となくいじるのが面倒くさそうな印象があったんだけど、実は全くそんな事がなくて 寧ろちょろっとやれば誰でも簡単にいじれるようになるくらい学習コストが低かった(まだChefと絡めていないので Chefと連携させると若干話が変わってくるかもしれないけど)。
というわけで今回は Vagrantを使ってUbuntuサーバを2台立てて MySQLでレプリケーションを構成してみた話を。
今回に関してはどちらかというとVagrantよりMySQL寄りの話になります。
Vagrantに関しては boxの構造とかVagrantfileの事とか 色々と整理できたので 後日 初心者向けにvagrantの基本的な事柄についてまとめます。
(続きを読む…)

ご無沙汰です。

本当は「数千万件のデータが入ったテーブルでインデックスを構築したらパフォーマンスが劇的に改善された話」というタイトルで書こうと思ったのだけど、書いているうちに内部構造が気になり出したので上記のタイトルに変更。

まずはパフォーマンスが改善された話から

SELECT A FROM hoge WHERE B = ~~~ ORDER BY C DESC;

hogeは数千万件のデータが入ったテーブルで、その中から結果約4万件程のデータのうち A の部分をSELECT。条件としては、カラムBの値が~~~に合致するときで、更には Cという別のカラムで並び替えるというクエリになっている。

結果的に

ALTER TABLE hoge ADD INDEX foo ( B, C, A );

というインデックスを張ることによって、それまで2分以上かかっていたselect文が 0.1秒～0.2秒まで短縮されたという某赤いモビルスーツも驚きのパフォーマンス改善を見せた。

正直インデックスの劇的な威力に感動して、その喜びをブログにつづろうと思い立った所、以下の疑問が生まれたというのが始まり。

すなわち、

何で↓じゃだめなの？

ALTER TABLE hoge ADD INDEX foo ( A, B, C );

という話(どこかのブログで「インデックスは順序左から書かないと意味無いよ」と書いていたので)。

仮説

なんとなーく最近コンパイラをいじっていて記憶に新しい構文木的なにおいがするなあと感じた。

そこで、MySQLの構文解析機構を調べてみたところ、

案の定字句解析と構文解析をそれぞれFlexとBisonで行っているようなので、勉強がてらMySQLの構文解析ロジックを見てみることにした。

調査

丁度GoogleがMySQLのコードを出していたので、MySQLの構文定義部であるsql_yacc.yyの中身を拝見。

http://code.google.com/p/google-mysql/source/browse/sql/sql_yacc.yy?r=d15790ab618324fb1729aa212b244cad5cb9778f

まずは式全体の構文を探す。1600行目でみっけ。

/* Verb clauses, except begin */
statement:
alter
| analyze
| backup
| binlog_base64_event
| call
| change
| check
| checksum
| commit
| create
| deallocate
| delete
| describe
| do
  :
  :
  :

中には「select」もしっかり定義されていたので、続いてselectを探す。

6638行目から始まっているのがそれっぽい。

select:
select_init
{
LEX *lex= Lex;
lex->sql_command= SQLCOM_SELECT;
}
;

/* Need select_init2 for subselects. */
select_init:
SELECT_SYM select_init2
| '(' select_paren ')' union_opt
;

どんどん掘り下げていった結果、だいたいこんな感じになりました。

考察

選択するカラムと where句、order by句、 having 句、group by 句などの条件が明確に分断されていました。

つまり、select_from の部分は、よくあるコンパイラの factor = ( expression ) 的な感じで先に解析されていて、解析が終了した後でSELECT_SYM とがっちゃんこするのではないかと予想(定かではありません)。

こう考えると

ALTER TABLE hoge ADD INDEX foo ( B, C, A );

になるのはそこまで不思議な話ではないかなと感じた。

実際はどうだったのか(2014.03.26追記)

記事の公開後、友人から「covering index 的な話では」とご指摘をいただきました。

Covering Indexに関しては 以下の記事がとても参考になった。

MySQLでインデックスを使って高速化するならCovering Indexが使えそう

もう少しDBまわりの勉強もしないとなあと思いつつ、また新しいことを勉強させていただいた上にMySQLの内部構造にもちょこっと触れられたので 結果としては良かったかなと思った。

Vagrant？

簡単に言うとインフラ構築の自動化。
例えば 手動でやろうとすると、OS入れる度に VMでディスクイメージ読み込ませて あれやこれやと細かい初期設定しないといけないけど、Vagrantを使えばたった3つのコマンドで上に書いた事を勝手にやってくれる。
Vagrantは chefのようなツールと合わせて使えば超強力と巷では言われていて、要するにソフトウェアのインストールまで自動化してくれる。
これはどういうことかというと…

インフラ構築にいちいち時間かける必要もなくなるし、ミスも防げるし、チーム開発の場合は 新しく入ってきた人でもすぐに環境構築できるし、何より「俺の環境では動いたよ」も減る。

個人で勉強用に開発環境立てては壊しまくったりする場合にもかなり便利だけど、チーム開発でも圧倒的な力を発揮。

とりあえず 今回に関しては Chef を使用せずに VagrantでOSだけ入れてもらって、動作確認の意味合いを込めてWebサーバの立ち上げをやってみる。

因みにVMを動作させる環境はフリーで落とせる VirtualBox を使用。

(続きを読む…)