みかログ

最近は常にInnoDBを利用しているので，MyISAM vs InnoDB にちょっとコメントしてみる．

まず「Webアプリならトランザクションはいらないか」について．

Webアプリで，トランザクションの重要性が高くないといっても，無いよりはあった方が良いはず．
ちょっとしたシステムでも，たとえばユーザのテーブル，プロフィールのテーブル，日記の記事のテーブルなどでわけるわけで，それぞれのテーブル間の整合性がとれていないと問題が生じてしまうと思う．

ハードウェア障害などでクラッシュしたときに，ユーザのテーブルにはレコードがあるけど，プロフィールにはレコードが無いケースとか，そういうケースが発生することを考えると，トランザクションは利用すべきじゃないのかなと．

というわけで，JOINを使うようなアプリケーションであれば，トランザクションは使うようにすべき，というのが持論．

それ以外でInnoDBを利用する理由として大きいのは，データが安全，というか，保証されているところ．
MyISAMは，一度クラッシュしてしまうと，もう中身が正しいかどうか判断する方法が無くなってしまう．
myisamchkでチェック・修復した場合，テーブルの構造は正しくなるけれども，データの整合性がとれているとは限らない．
さらに，myisamchkはテーブルのサイズに依存して時間がかかるので大きなDBでは停止時間が長くなってしまう．

InnoDBでは，クラッシュしても再起動時に自動修復されるので，無事起動すればデータの整合性が確保されていると安心できる．
自動修復もテーブルサイズによらないので，でかいDBでも安心．

まぁ，この辺はレプリケーションを利用すれば回避できるので，その場合はあまり影響がないかも．(^^;

速度に関しては，そこまで大きな差は無い．．．と思う．
InnoDBのベンチ・・・をそのまま信用はできないけど，ベンチ結果が以下に．

http://www.innodb.com/bench.php

体感では，やっぱりInnoDBの方が重く感じることが多いかなぁ．
特にDBサイズがかなり大きくなるので，ディスクキャッシュなどの関係で遅くなってしまうのではと推測・・・

MyISAMのテーブルロックに関しては，短時間で終わる参照と，短時間で終わる更新の場合は問題ないけれど，長時間かかる参照が間にはいるとうまくいかなくなるので，そこに注意すべきかなと．

バッチ処理とかで，テーブルに対して集計をかけたりする場合，MyISAMでは更新・参照トランザクションの両方が待たされてしまうので，Webアプリとしては致命的な遅延が出てしまうはず．
普段は長時間のクエリがなくても，例えばランキングを作ったり，ユーザの男女比率とかを集計したりをする必要があって，長時間のクエリをたまに発行する場合は多いと思う．

でも，あまりそういう点に注意して選ぼう，みたいな記述をみたことがない気がする．
（そもそもテーブルロックだから長時間のクエリは論外？なのかもだけど(^^;）

これも，やっぱりレプリケーションを使えばある程度回避できるので，大規模だとあまり関係ないのかもしれないけど．
普通はレプリして，そういうクエリやらバックアップをスレーブ側からとると思うので．．．

というわけで，MyISAMでもレプリケーションを使えばトランザクションによる整合性の確保以外は大きな問題がないけれど，そういった工夫をしなくても，

InnoDBなら
・データの整合性に関して安心
・クラッシュ後にちゃんとリカバリでき，速い．
・ロック待ちを気にせず長時間かかる参照クエリを発行できる

というあたりがメリットじゃないかと思う．

欠点は，DBサイズがでかい，でしょうか．．．

運用に関しては，InnoDBだから面倒，と思うことは無いんだけど，何が面倒だと思わせるんだろう．．．
設定パラメータはMyISAMより多少多いけど，Oracleとかと比べれば非常に簡素な作りになっていると思うのだけど．．．

TLのインストールテストをしていたら，少し前までは正常にできたのに，今はうまくはいらない．

調べてみたら，Test::Exception が make test に失敗していた．
Test::Exception は Test::Simple に依存しているけれど，Test::Simple が最近バージョンアップしたおかげで，今まで動いていたテストが動かなくなった模様．

Test::Simpleのバージョンアップで互換性が崩れたのか，Test::Exceptionのテストの書き方が悪いのかはわからないけれど，こういうのは困るなぁ，と改めて思ったり．
結構メジャーなモジュールだと思ったんだけどなぁ．

ちなみに，1つ前のバージョンではちゃんとはいるので，

cpan> install MSCHWERN/Test-Simple-0.62.tar.gz

とかやって古いバージョンを入れれば回避可能．

Perlコアに取り込まれていないモジュールは，やっぱりこういう問題がおきやすいのかな．
CPANで，依存されているモジュールの一覧を見る機能が提供されれば，こういう問題は少しは減りそうだけど．
（作者が依存されているモジュールも含めてテストする気力があれば，の話だけど）

こういう事があると，なるべく外部モジュールに依存しないようにする方針は間違ってなかったかな，とか思ったり．
YAPCとかのイベントでの話では，数十個以上のモジュールに依存しているようなのもあったけど，そういうのだとモジュールのバージョンがあがったときが大変そう．．．
（開発時のモジュールバージョンでずっと固定するのも手だけど）

うちの会社で使っていた自社フレームワークをリファインしたものがようやく公開．

http://tripletail.jp/

公開用作り直す際に，今まで変えられなかったところもいろいろ直せたのが良い感じ．

少しは流行るといいなぁ，とは思っているけど，Perlハッカーレベルの人にはあまり受けが良くない気がする(^^;

Railsとかと違って特別楽しそうな機能とかは無いし，基本的な機能重視という感じだから．．．
その分初心者にはとっつきやすいと思うけどね．

でもPerlの下位互換性の良さもあって，互換性の高さだけはほかに負けないと思う．
進化が激しそうなWebアプリでも，3年とか5年とか使い続けるお客さんもいたりするので，互換性は重要．．．

PHPはまぁぼろぼろだとして，Javaもフレームワークとか使うと，フレームワーク自体が終了したりとかあるようなので．
その辺は自社で用意しておくと強い気がする．

PHPとか流行っているけど，あの互換性の低さはみんな気にしないのかなぁ．というのは疑問．
作った後の保守とかはあまり考えないのだろうか．．．
よくバージョンアップで動かなくなった，とか聞くけど，業務で使っているところはみんなどうしてるんだろう．