■本書を読む理由
 世の中の大規模サイトでは結構MySQLが使われているらしい、というのと、個人的にDBのリプリケーション、負荷分散(ロードバランシング)などに興味があるため。

 MySQLはトランザクションという概念がないとか、テーブルロックしか出来ないから使い物にならないと言われていた(いつの時代の話だ??歳がばれそう)のがその後どういう形になったのかについても知りたい。

 またエンジンが幾つかあるようなので(MyISAMエンジンとかInnnoDBエンジンとか)、どれを選択すればいいのか?要するに高負荷で24x365サイトを運用する際には、どういう構成にしてどういう運用をすればいいのかを知りたい。ヘビメタギタリスト的に速弾きが出来るのが一番偉い、というわけでもないとは思うが、とにかく自分の興味がそこにあるのだから仕方が無い。

 あと、全文検索が日本語で出来るらしいし(デフォルト機能ではないようですが)。

 ちなみに筆者は検索会議にも来ていたY!のジェレミー氏。
■本書の概要
 目次の中から、興味があるようなポイントをピックアップ。
 ロックと並行処理、トランザクション、エンジンの選択、ストレージエンジン、ベンチマーク、インデックスの構造、インデックスの保守、遅いクエリの特定、ボトルネックの解決方法、レプリケーションの概要、負荷分散の基礎、バックアップと復元

■一部ピックアップ

▽2.2.2 ロック範囲
引用:
ほとんどの商用データベースよりもMySQLのほうがずっと高速なので、テーブルロックしか使用できなくても普及の妨げにはならなかった


2002年ごろ、MySQLはテーブルロックしか出来ないということでほとんど無視していたんですが、気づくとPostgreSQLよりも普及しているっぽい。
MyISAMエンジン(デフォルトのエンジン)は90%が読み出しであるという前提で作られているっぽい。トランザクションを使用する場合にはInnoDBテーブルを使用したほうがいいっぽい。

▽2.2.3 MVCC(Multi-Version Concurrency Control:マルチバージョン並行処理制御)
引用:
概念的には、テーブルのクエリを実行すると、そのクエリは、いくら実行に時間がかかったとしても、クエリを開始した時刻に存在していたデータのスナップショットを参照する


Oracleと似てますね。
トランザクション分離レベル oracle mysql で検索すると色々出てきます。

▽2.3.5 MySQLのトランザクション
よくある4つのトランザクションレベル(read uncommitted, read committed, repeatable read, serializable)は使えるらしい。

▽2.4 適切なエンジンを選択
引用:
アプリケーションでトランザクションを使用する必要がなく、主にSELECTまたはINSERTとUPDATEクエリを実行するのであれば、MyISAMがふさわしい。多くのWEBアプリケーションはこのカテゴリに入る。


なるほど

あとはバックアップの問題とか、テーブルの分割(読み取り用と書き込み用)、エンジンの分割(マスターとスレーブに分けて、読み取りと書き込みを別々に担当させるとか)

▽2.5 ストレージエンジン
読み取り専用ならCompressed MyISAMテーブル、ストライピングを行うならRAID MyISAMテーブルが用意されている。

▽3.3.2 MySQL super-smack
MySQLとPostgreSQLとの両方で使える負荷テストツール。よさげなので今度いじってみよう。

▽3.3.3 MyBench
Zawodny氏作成のベンチマークツール。super-smackはカスタマイズにC++の知識が要求されるようだが、こっちならPerlで書けるらしい。

▽4.2 インデックスの構造
Bツリー、ハッシュ、Rツリー、フルテキスト、

▽4.3.2 Heapテーブル
オンメモリで使用することが出来る。当然速度が必要な際に有効なはず。

▽4.4.2 インデックス統計情報のリフレッシュ
OPTIMIZE TABLEコマンドでインデックスの付け直しを行う。ただし実行中はテーブルに書き込みロックが行われるので要注意。
DBが停止している状態であれば、myisamchkコマンドが使える。

オンライン状態でインデックス付けなおせないのか??

▽5.1.1 クエリキャッシュ
SELECT句のみキャッシュするらしい。大文字小文字が関係するのか。。

▽5.1.3 EXPLAINによる調査
PostgreSQLと同じような感じ。

▽6.2 RAID
規模にもよるが障害発生時に自動的にホットスワップするあたりのハードは欲しいところ。
別の仕事でFiber接続のDiskArrayを使うことになりそうだが、意外に安価だったりする(個人で買える値段ではないが。。

本書でも以下のように述べられている。

引用:
多くのMySQLユーザは、3WareのIDE RAIDコントローラと4〜12個のディスクを使用すれば、十分に満足するだろう。

▽6.3.1 ファイルシステム
LinuxだったらReiserFSか?

▽6.3.2 スワップ
Linuxはカーネルのバージョンによっては「活発にスワップしすぎる」らしい。
スワップ停止が基本か?

▽6.3.3 スレッド
スレッドについては、WindowsとSolarisがオススメっぽい。
Linuxだと、たとえばRedHatLinux9.0以降がオススメっぽい(POSIX準拠のスレッドライブラリ)

▽7.1.1 レプリケーションで解決できる問題

データ分散・・・ようはレプリケーション
負荷分散・・・ラウンドロビンDNSとかと組み合わせて、、
バックアップと復元・・・ダンプする代わりにレプリケーション
高可用性とフェイルオーバ・・・8.4章参照

ラウンドロビンDNSは個人的には微妙かなと。なんとかモンキーみたいなのを使って生存確認とのセットにしたいかなと。

MySQLのレプリケーションは非常に簡単で有用のようである。
マスターサーバ上のバイナリログファイルを元に、スレーブサーバ上のDBに同様の更新を行うという方式である。

▽7.5.1 監視
スレーブへのレプリケーションが正常に実行されているか監視するための施策
>「7.5.4 ツール」参照

▽7.5.2 ログの循環
上記、バイナリログファイルの削除は必要。

▽8.1 負荷分散の基礎
読み出しのDBアクセスを負荷分散装置経由でスレーブのクラスタへ繋ぐ、というのは有効と思われるが、それ以上にソフトウエア的なJDBCクラスタリングが世の中的に結構進化しているっぽい。
Clusterd JDBC、DBIx::DBCluster,SQL Relayなど。

ただしDBへの接続はプーリングが発生するので、たとえば恒常的な接続が発生してる状態では負荷分散が有効でない状況が発生することも考えられる。本書ではタイムアウトを短くすると良いとあるが、セッションを再接続するコストもそれなりに大きそうではある。実験してみないと判らないかもしれない。

▽9.2.5 レプリケーション(によるバックアップ)
レプリケーションとは、要するにオンラインバックアップなのでこれを使わない手は無い。基本的にはレプリケーション+時々のダンプで充分なのではないか?(レプリケーションだとオペレーションミスで失われたデータを復旧できないので)

レプリケーション中にマスターが壊れた場合は、スレーブをマスターとして復活させるだけでは厳しいので、もう少し工夫が必要。

■読後の感想
▽知りたい情報は全て得られたか?
 ほぼ期待通りの内容でした。

▽それ以外で得られたものは何か?
 設定ファイルの履歴管理を行う重要性<自分に足りない発想だなと
 あとはソフトウエア負荷分散についての調査の必要性を感じた。

ご購入はこちらから:
Amazon 実践ハイパフォーマンスMySQL