題の通り、「SQLパフォーマンス詳解」(原文タイトルSQL Performance Explained)という本を翻訳しました。PDF版と印刷版が上記サイトから購入できます。
(追記 2017年9月から、渋谷のBOOK LAB TOKYOさんでも印刷版を販売していただいています。輸送コストの関係で、サイトから購入するより若干安くなっています)
リレーショナルデータベースにおいて、SQLとインデックスがどのように関連し、どのようにすればSQLのパフォーマンスを良くできるのかを解説した本です。特定のデータベース製品に焦点を当てた本は多数ありますが、この本ではOracle Database、PostgreSQL、MySQL、SQL Serverの4つのメジャーなリレーショナルデータベース製品を同時に扱っていて、それぞれのクセや特徴も分かるように書かれている点が非常にユニークになっています。また、ORMが生成するSQL文の違いなどにも言及されています。
前書きにもあるように、データへのアクセスパスを知っているのは他ならぬ開発者なので、開発者自身がSQLとインデックスについての知識を深めなければ本当の高速化はできない、というのが著者の考えのようですが、もちろんアプリ開発者だけでなくインフラエンジニア、データベースエンジニアの方々にもおすすめできる内容だと思います。
目次とそれぞれの内容は以下の通りです。
- 第1章 インデックスの内部構造
- インデックスとはそもそも何か、インデックスはどのような仕組みか
- 第2章 where句
- where句とインデックスの関連、例えば=を使った場合、likeを使った場合など演算子の違いによるインデックスの活用方法など
- 第3章 パフォーマンスとスケーラビリティ
- インデックスの作り方の違いによるパフォーマンスとスケーラビリティの違い
- 第4章 結合処理
- 第5章 データのクラスタリング
- データのクラスタリング(HAクラスタなどではなく、いわゆるクラスタリングインデックスのこと)
- 第6章 ソートとグルーピング
- ソート(order by)やグルーピング(group by)とインデックスの関連
- 第7章 部分結果
- MySQLで言うlimitやPostgreSQLのfetch firstのような、結果の一部分を取得するSQL文とインデックスの関連
- 第8章 データの変更
- update, insert, deleteといった更新処理とインデックスの関連
- 付録A 実行計画
- 各データベース製品での実行計画の表示方法とその読み方
既にご存知の方もいるかもしれませんが、Use The Index, Lukeという名でほぼ全文がWeb上で公開されています。とはいえWeb上で通しで読むのはかなり辛いですし、PDFあるいは印刷版を購入いただければ、作者・訳者とも嬉しい限りです。
私は、Yakstというサイトで海外のブログ記事などを翻訳して公開するというのをやっているのですが、原著者(Markus Winandさん)が書かれたブログ記事を翻訳させてもらったのがきっかけで、この本の翻訳をやることになりました。オンライン販売だけの予定なので書店に本が並ぶわけではないとは言え、自分が訳した本が人に読まれることになるというのは、不思議な感覚です。Markusさんはオーストリア人で英語のネイティブスピーカーではないこともあり、原文は非常に分かりやすい英語で書かれているのですが、それでも翻訳の難しさ、自分の未熟さをひしひしと感じました。素晴らしい本を書いてくださった原著者のMarkusさん、私のつたない訳を丁寧にレビューしてくださった@matsuuさん、ありがとうございました！
訳の問題など、ご意見ご感想ありましたら@dblmktまでいつでもご連絡ください。
ちなみに、海外の有益な技術系ブログを翻訳して公開しているYakstで、翻訳を一緒にやっていただける仲間も募集しておりますので、良かったらそちらも是非よろしくお願いします。
ふう、MySQL Casual Talks Vol. 7行って参りました。前回は自分が発表者でもあったので、正直なところ他の人の発表を聞く余裕はなく(汗) 今回は、同僚の発表もあったので楽しみにしていったら、相変わらずの濃ゆい話が盛りだくさんで、非常に楽しめました。毎度の事ながら、@myfinderさん始め、会場提供・準備していただいたLINE
のみなさま、Oracleのみなさまに感謝です。
- GAから半年なのに誰も使ってない
- アメリカのイベントでは、MySQL Fabricだけに布がプレゼントされた(白目
- Fabric対応コネクタが各種言語向けに用意されてる
- yokuさん謹製fabric対応mysqlクライアント
- fabricとConnector/C経由で通信する
- ro(スレーブ、分散される)とrw(マスタ、当然1台)のモードがある
- マスタを落とすとちゃんと切り替わりますよ(デモ)
- 3年ぐらい運用、結構消耗
- MHA組んでおく
- ENIをつけておいて、マスタ切り替えはそれを付け替える
- Mackerelでモニタリング
- バックアップスレーブでsnapshotとってる
- スレーブ作る
- snapshotから作る
- dumpから作る
- 落ちたら捨てる前提(信頼性落とす、ダウンしたら捨てる)
- 取りあえず2セット作って入れ替える、が可能なのがよい
- スレーブのオートスケールは結構難しい
- warmup難しい
- 5.7はできそう(buffer poolリストア)
- データはEBSに置いている
- IOできなくなって死ぬことがある
- ヘルスチェック工夫しよう
- RDSはちょっと高いけど楽
- フェイルオーバーが長い
- 可用性がちょっと微妙でやめた(2012年ぐらいの話なので古いかも)
- ELBはDNSベースなのでちょっとってことでhaproxyで分散している
- もはや自前でMySQL運用する時代じゃないよね
- Oracle(200セット), MySQL/Percona(300セット)を運用中
- Percona Live 10月にロンドンで開催されたのに参加してきた
- XtraDB Cluster
- ActiveActiveの構成、高い冗長性
- ヨーロッパでは広く普及
- OpenStackのバックエンドに使われている
- 本家のGroup Replicationと似てる
- どのノードに書いても同期レプリされる
- MySQL Clusterよりは本家MySQLに近くてハードル低い
- Writeのスケールはできない(MySQL Cluster使おう)
- SST(丸ごとコピー)、IST(差分)でDonorからデータを送る
- ノードへの分散はHAProxyとか使う
- ヘルスチェックの仕組みもXtraDB型に準備されてる
- 書き込みは楽観的ロック
- コミットしてノード間の情報が食い違ってるとコミット時にエラー
- 従って書き込みはできるだけ1台がいい
- オンラインalterはできない(今後サポート予定)ので、ローリングで変更していく
- ブログ記事
- 2005年 4.0.25 -> 9年 -> 5.0.96にバージョンアップ
- @tnmt 氏がカジュアルに5.6バージョンアップを指示するイシューを投げたところから始まった
- しかしやる事になった時は何にも知識ありませんでした
- たくさんの爆弾が仕込まれていた。。
- マスタとスレーブの食い違いなどなど
- ハードもソフトも古い
- 検証の過程で色んなバージョンをインストールしたので、MySQL-AllStarというbox提供してます(4.0から5.6まで全部入り)
- 結局5.0まで上げることに
- 6/20 イベントがあるとレンタルサーバのアクセスが減るからwという理由でメンテ実施
- ダンプからリストア、切り替えまで同じタイミングでやった
- insertを実行するとbinlogが壊れることが発覚
- 失敗として切り戻し
- 5.0系を特定のgccでコンパイルすると起きるバグ？
- gccの最適化のレベルによってテストが通ったり通らなかったり
- その後別のバグ発生
- rpmbuild中に必要なファイルが消える
- 邪魔してたパッケージ消してビルド成功
- 8/22無事バージョンアップ成功
- 4.0に入っていたデータの一部がリカバリできなかったのは手動で戻した
- ブログ記事
- ギフトとかカードの情報が増えまくる
- 1日数十GB、論削だけで物理削除してなかったり
- 削除するのではなく、必要なデータだけをINSERT SELECTで抽出してテーブルを作り直すと速い
- deleteしてもテーブル容量減らない(MVCCのバージョン管理のため)
- pt-online-schema-changeでテーブル再構築
- レプリ遅延
- truncateすると遅れる(deleteより遅い)
- バッファプールを大きく使ってると遅くなるというバグ
- 結局deleteしました
- ブログ記事
- パーフェクトRuby出しました
- Rubyの人はRedis使う人多い(sidekiqで)けどQ4M
- shinq
- ActiveJobを利用
- Rails 4.2に入る予定のキュー機能
- ブログ記事
- DBのバックアップだけじゃなくてリストアも繰り返しやって、復旧可能性を担保
- バァーン、バァーン、バババァーン
@ijin さん ConsulでMySQLのフェイルオーバー
- 元ネタのブログ記事
- consulはraftを使ってcap定理のcpを実現している
- MHA発動時に実行されるfailover scriptでconsulのAPIを叩いてマスタのDNS名を変更する
- consul event
- eventをノードに伝えると伝播される(no guarantee)
- watchで検知してスクリプトを動かす
- consul templateを使いましょう
- my.cnfをチューニングする
- innodb_flush_log_at_trx_commit=2で結構上がる
- innodb_flush_method=nosync/O_DIRECTでも上がる
- この2つのオプションさえちゃんとやっておけばおk
- データ量に応じてinnodb_buffer_pool_sizeも
- ブログ記事
- 圧縮効いて8〜6割の性能
- 容量的には半分ぐらいに圧縮できた
- 圧縮伸長でCPU食う(元々ioDriveではCPUバウンドだけどさらにきつくなる)
- いつもの
- 特に進捗なし
- Raspberry piでN:1 replication動きましたw
日本Chefユーザ会なるものがいつの間にかできていたようで、Chef社の人も招いてMeetupが開催されると聞き、参加してきた。
先日発表されたChef 12(参考日本語記事)の簡単な紹介と、Chefのテスト環境に流れを追っての概要とデモがあった。新しい情報はそれほどなかったように思ったが、テストについてのデモ後は質問が活発に出たりしてなかなか面白かったので、メモ公開。
ちなみに、Chefユーザ会のハッシュタグは #getchef_ja だそうなので、日本語のChefに関連するつぶやきはここを見ておくのがよさそう。
- 新しくなったchef server
- 従来1組織しか管理できなかったがmulti tenantサポート
- chef client
- chef pushというクライアント側へのプッシュ機能が付く予定
- Chef development kitがバージョンアップ
- test-kichenやfoodcriticなどを含む
- Enterprise版の機能
- HA
- replication
- analytics
- 25ノードまでは有料版の機能を無料で使える
- 日本でEnterprise版を使いたければ、まずクリエーションラインさんに問い合わせ
- クックブックのテストをする時は、以下のツールを使っていくことが多いよ、という話
- test-kitchen
- chef dev kitの一部
- 仮想マシンでクックブックをテスト
- foodcritic
- chef dev kitの一部
- chefのお作法に沿った文法かチェック
- rubocop
- guard
- ファイルシステム変更確認
- これでcookbookの変更とかをチェックして、test-kichenやfoodcritic、rubocopとか走らせる
- 下の質問にもあるが、ローカル環境で動かしておいて、コミット前のテストを自動化するのに使う
- serverspec
- クックブックを実行した後に、対象のノードがどうなったかのチェックするのに使う
- chefspecは、どうなるべきかクックブックで実装できてるかをチェックするツール
質問
- クラスタがちゃんとセットアップできたかのチェックとかやりたいんだけど
- serverspecのspecファイルはどこに置くの
- mysqlだとクックブックのディレクトリのtest/integration以下に置いてる
- MySQLのクックブックが一番ちゃんとテストしてあって色々な点で参考になる。読むなら一番いい
- test-kitchenのサンプルとしてもMySQLがいい
- Windowsで使いにくいんだけど
- serverspecは全部実行した後にやると思うけどchefspec, test-kitchenとかはどのタイミングでかける？
- chefspecはlocalで実行する
- その後test-kitchenで確認する
- guardはどう使う感じ？
- 基本はローカルで動かしておいてコミット前のチェックまで自動でやるもの
- リモートで動かして使うことももちろんできる
- cookbook内のattributeをserverspecで使いたい時はどうしたらいい？
- serverspec側を何とかいじってattributeの書いてあるファイルを見るとかする他ない
- test-kitchenするのにいいのありますか？(EC2だとお金かかっちゃうから)
- DigitalOceanは(chef社からは)速いよ(ただし西海岸は。DigitalOceanはChefのユーザでもあるし)
- 速いところを探して使うしかない
- test-kitchen -parallelを使えば並列実行できて速い
- kitchen.yamlでnodeの情報にアクセスしたい
- chef-zeroを使えばいい
- chef-soloは将来的にdeprecatedになる予定
- 日本でのchefコミュニティを活性化させるにはどうしたらよいと思うか？
- ビールが必要(笑)
- 頻繁に勉強会やmeetupやっていきたい
- (逆に参加者への質問)女性chef関係者はいないのか？w
10/25の楽天テクノロジーカンファレンスでも、Michealさんが話をするそうで、参加者へのアンケート(？)の結果、Dockerと関連してChefを使う話を予定しているとのこと。
この後、Chef社とクリエーションライン社のおごりで、楽しくビールを飲みながらChefの話をしてお開き。
発表いただいたChef社の方、会場の準備などしていただいたクリエーションラインの方々、ありがとうございました。ビールごちそうさまでした。
題の通り、「SQLパフォーマンス詳解」(原文タイトルSQL Performance Explained)という本を翻訳しました。PDF版と印刷版が上記サイトから購入できます。