Neural Networks and Deep Learning - Neural Networks Basics

CourseraでNeural Networks and Deep Learningを受講し始めました. www.coursera.org

2week目です. 1weekの内容はこちら

内容

この週の講義の前半を一言で表すと,2値分類問題をニューラルネット的な考え方を取り入れたロジスティック回帰で解くといった内容です. コスト関数の定義,(最急)勾配法の説明を行い,勾配法で必要となるコスト関数の各変数での微分を計算するために便利な方法(チェインルール)を紹介するといったような流れです.

講義の後半はPythonの使い方とfor文を使わないでコーディングするためのベクトル化の説明です. for文を使わないでベクトル化したコーディングができると最適化が効いて処理が早く完了するので,そうしましょうというような内容.

コードの見た目的にもfor文を使って手続きがつらつらと書かれているよりも宣言的に書かれている方が見やすくてベターだと感じました.

コスト関数自体の導出はOptionとなっているビデオを見ると結構詳しく開設されていますが,ここら辺の丁寧さは下記の別コースの方が親切かもしれません.

www.coursera.org

まあ本講座はMLの各アルゴリズムの説明を目的としたものではなくDeepLearningに入門するためのものなので,そういう棲み分けになってるんでしょうね

後ぶっちゃけ,この週の動画,かなり多いです...

勾配法

ロジスティック回帰のコスト関数は下に凸な形をしているため,局所解が存在しないものになっている. そのため,ある時点でのコスト関数を求めた後,そのコストが下がる方向に各係数を更新してあげればよりコストが低くなる係数の組み合わせが見つかるという考え方が勾配法です. 「コストが下がる方向」を知るために勾配を求める必要がありこれがコスト関数を各係数で微分することで求まります.

チェインルール

L=f(w), w=g(x+y)というようなx+y=>w=>Lと変換していく1つの処理の流れがあった場合,dL/dx, dL/dyを求める便利な方法があります. 合成関数の微分の際にあるチェインルールがまさにそれで,dL/dx = dL/dw * dw/dx, dL/dy = dL/dw * dw/dy というような形で求めることができます. この時dL/dwは使いまわすことができます.

ロジスティック回帰レベルではそんなに便利さは感じませんでしたが,これがニューラルネットワークでの各係数を更新するための勾配を求めるのに使われるとても便利なルールになっているようです

ベクトル化

各計算を行列の計算に当てはめていくことで,for文を明示的に書かなくて行列の計算という形でコーディングできるようにする手法です. これによって最適化されるので計算が早く完了します.

感想

やはりAndrew先生の説明はわかりやすいです. ただ,全編英語で聞いてるのはしんどいので字幕表示しながら受けているのですが,一部の動画で字幕がずれているケースがあり,ちょっとしんどかったです.

ちなみにプログラミング課題ではロジスティック回帰を用いた猫の分類ロジックを実際に書きます. 拍子抜けするくらい簡単に70%程度の精度で猫判定器が作れるのは嬉しい驚きでした.

Neural Networks and Deep Learning - Introduction to deep learning

CourseraでNeural Networks and Deep Learningを受講し始めました.

www.coursera.org

deeplearning.aiのAndrew Ng先生のオンライン講義です. Andrew Ng先生といえばStanford UniversityのMachine Learningで有名な先生です.

www.coursera.org

僕のMachine Learningの学習はこの講義から始まりました. とてもわかりやすくて,宿題も身につく内容だったので,新たなシリーズが始まったと聞き喜び勇んで1weekの受講を完了しました.

内容

タイトルはIntroduction to deep learning. Introductionということで短いセッションでした.30分に満たないくらい. 内容としてはニューラルネットワークの超導入部という感じでした.

ニューラルネットワークの基礎

住宅価格の推定問題を例として,一つの特徴量をinputとして価格を推定する最小構成のニューラルネットワークの概念をまずは紹介しました.

そこから,複数の特徴量に拡張して浅いニューラルネットワークへと説明を展開していきました. 複数の特徴量(sizeや#bedroom)からfamily sizeという特徴量ができて,それがpriceを推定するニューロンのinputになるというような例でした. 最小限の構成を知った上でどんどん発展させていくように説明してくれるので理解がしやすいです.

教師あり学習

次に,教師あり学習についての説明がありました.

どんな応用をしたいか?どんな問題を解きたいかによって何を説明変数として何を推定するか?を決めることが大切だというお話でした.

例えば不動産価格の推定問題であれば家の特徴を説明変数とし,住宅価格を推定します. オンライン広告問題であれば,広告の特徴やユーザー情報を説明変数とし,Clickされるか否かを推定します. こんな感じでいくつかの例を紹介していました.

また,解きたい問題によって使うべきニューラルネットワーク自体も変わることを説明していました.

例えば不動産価格の推定問題であれば通常のニューラルネットワークを使いますが, 画像認識問題であればCNNsを使いますし,音声認識や会話認識ではRNNsを使うことが一般的だという説明でした. これらはこの講義シリーズの後の方で出てくるので楽しみです.

構造化と非構造化データ

最後に構造化データと非構造化データの説明がありました.

構造化データとはDBに入っているような表データを示し,非構造化データとは音声とか画像とかのデータを示します.

感想

とりあえず1weekが完了しました.

始めの一歩ということでかるーい内容でした. というか1weekはMachine Learningのコースでも聞いたような話が多かった気がします. RNNとかCNNとかは出てきてなかったかもですが.

1weekはプログラミング課題はありませんでしたがQuizがありました. 少し迷いましたが初回で100%正解できたのでよかったです.

最後まで受けられるようにがんばろうと思います.

ちなみにOptionですがあのHinton先生の40分に及ぶインタビュー動画も観れます. 何処かのタイミングで見なくては.

SPRINT最速仕事術を読んで(火曜日編)

前回は月曜日のタスクについてまとめた。 今回は火曜日のタスクについてまとめてみる。

SPRINT 最速仕事術――あらゆる仕事がうまくいく最も合理的な方法

火曜日:思考を発散させる

月曜日にはチームで取り組む課題を決めて、ターゲットを決めた。 火曜日はソリューションを考える。

材料を取り揃える

アイディアの素を集める

スプリントでは0から1を作るような方法はとらず、すでにあるアイディアを組み合わせて課題を解決することを目指す。 本書の中ではレゴの部品を集めるようなイメージと書かれている通りで、レゴの部品を自分で生み出したりはしない。

この作業はネットを使うなりなんなり方法を駆使して参考になりそうな他のモノを洗い出す。 他社製品でもいいし、他の業界の同様の問題を解決しようとしているものでもいいし、社内で過去に検討されたアイディアでもいい。

3分間の光速デモを行う

アイディアの素をチームで共有するために3分間の光速デモを行う。 アイディアの主な部分をビッグアイディアと呼びホワイトボードにメモしておく。

ここまでの作業はあくまでみんなでアイディアを共有し、チームの中に材料を取り揃えることを目的として行う。 ここで議論したりはとりあえずしなくていい。

スケッチを行う

今書き出したアイディアと月曜日に作ったマップとスプリントクエスチョンとどうすればメモは大切な素材集となる。 これからこの素材集を使ってソリューションを構築する。

その前に

ソリューションを構築していくためには「スケッチ」を行うが、チームのメンバーと誰がどの部分を担当するのか?それとも分担したりせずみんな同じ箇所を攻めるのかと言ったことはあらかじめ相談しておくこと。

なぜスケッチを行うか?

スケッチを行うことで抽象的なアイディアに具体性を持たせる。 抽象的なアイディアは具体性に乏しいので間違って評価されることが多い。 具体性がないので過小評価されたり、逆に過大に期待されたりする。 これに対してスケッチを行って具体的になったアイディアは公平な評価を受けることができるので、スケッチを行って具体的なアイディアにしてあげることが大事。

どうスケッチを行うか?

以下の4つのステップに沿って行うと良い。

  • メモ-24時間のベストヒット集を作る-
  • アイディア-落書き帳のようになんでも書く-
  • クレイジー8-高速でバリエーションを考える-
  • ソリューションスケッチ-3コマで全体像を見る-

メモ-24時間のベストヒット集を作る-

月曜日と火曜日のこれまでに作ってきたモノを見返して、気になったものをメモにとる。 20分くらいでこの作業を終える

アイディア-落書き帳のようになんでも書く-

20分くらいでざっくりしたソリューションのアイディアを書く。 自分しか見ないから適当に書けばいい。

クレイジー8-高速でバリエーションを考える-

上で作ったアイディアのバリエーションを8分で8個考える(ように頑張る)。 無茶なチャレンジではあるが、無難な原案をより興味深いものに押し拡げるためにとてもいい方法らしい。 同じアイディアの「これをやるための良い方法」としてのバリエーションをたくさん考えることが大事。

ソリューションスケッチ-3コマで全体像を見る-

ソリューションの全体像を3コマで表す。 顧客がサービスを利用するときに目にするものを、3つのコマからなるストーリーボードで表す。

最後に作成したソリューションは水曜日の朝いちばんに、全員で見えるように壁に貼りだして品評を行う。 なので、わかりやすく書くこと。 また、品評に影響を与えないように匿名にしておくことも大切。 キャッチーなタイトルを自分のソリューションにつけて、下手でも構わないので仕上げる。

基本的には1人1つのスケッチを描く。 ひらめきが止まらなければ複数書いてもいいが、収穫逓減の法則があるのであまり良い結果には繋がらないのが著者たちの考えとのこと。

最後に、ソリューションを回収し 他の人のスケッチは見ない。 初めて見る体験をできるのは1度きりなので、それは品評会の水曜日まで取っておくこと。

SPRINT最速仕事術を読んで(月曜日編)

SPRINT最速仕事術を読んだのでまとめてみる. 長くなりそうなのでまずはざっくりとした全体像と月曜日のタスクについてまとめる.

SPRINT 最速仕事術――あらゆる仕事がうまくいく最も合理的な方法

スプリントとは?

GV(Googleベンチャーズ)が活用しているプロセス.
5日間のタイムボックスで1つの実験を行うことで,難しい問題に対して迅速に結果を得ることを目的としている.
ここでの結果とは,アイディアの成功という結果や失敗という結果をさす.
成功する素晴らしいアイディアを必ずしも得られるということではなく,本来的には長い時間かけないと成功するか失敗するかわからなかったような複雑な問題に対して 迅速に結果が得られるというところが利点.
素早く市場から学びを得ることを目的としたプロセス.

スプリントの大まかな流れ

  • 月曜日:目標を固める
  • 火曜日:思考を発散させる
  • 水曜日:ベストを決める
  • 木曜日:幻想をつくる
  • 金曜日:テストする

スプリントのメンバー

専門分野に精通し,課題に情熱を持っている人を集めて7人以下でチームを作る.
その中には決定権者を絶対に含めるべき.
これらのメンバーには5日間はそれ以外の仕事から外れてもらって,スプリントに完全集中できる状態を作ること.

月曜日:目標を固める

プロジェクトの長期目標

目標は高く,ポジティブに,下記の長期目標を決める.

  • プロジェクト完了時に何を成していたいのか?
  • どうなっていたいのか?

スプリントクエスチョンを書き出す

今度は逆に悲観的に,プロジェクトが失敗したと仮定した場合の原因を探す.
敗北条件を定めるとも言い換えられる.
同時に,長期目標達成のために満たされるべきポイントも洗い出す.

洗い出したものを,「○○○は×××だろうか?」という疑問に置き換える.
置き換えることでワクワクする興味深い疑問に変える効果がある.

マップを作る

全体を俯瞰し,問題の構成を把握するために役立つマップを作る.
マップは複雑な問題を人間が扱える程度の複雑さに変換する効果がある.
マップは以下の要素で構成される.

  • アクター
  • 完了(例えばECサイトであれば購入など)
  • 一言フレーズと矢印

ここでいう一言フレーズは「動詞」になりそうなきがする.
アクターと完了をつなぐステップであり,アクターの動きを表すものが一言フレーズなのかもしれない.

専門家に聞こう

スプリントで解決したいような大きな問題には様々な陰影がある.
みる立場や方向によって色々な様相を呈する.
なので多くのソースから情報を集めることが大切になる.

特に以下の4つの軸で情報を集めることはとても大切である.

  • 戦略
  • 顧客の声
  • 仕組み
  • 過去の取り組み

これらをヒアリングし,マップの修正を行う. また,同時に「どうすればメモ」を作成する.

どうすればメモ

専門家の話から得られた情報やそこで生じた疑問,面白いと思ったことを「どうすれば」から始まる形で付箋に書き出していく.

チームみんなで書き出したメモをホワイトボードに張り出して,役に立ちそうな質問にみんなで投票する.
得票数が多かったものについて,先ほど作ったマップを振り返り,疑問が該当する箇所にどうすればメモを貼り付ける.

これによってマップ上での対応関係がわかるようになる.

ターゲットを決める

スプリントを通して取り組むべきターゲットを決定する.
ターゲットは「最もリスクが高く,最も大きなことができそうなもの」を選ぶと良い.
これはどうすればメモを見ると想像ができるはずなので,マップに貼り付けられたどうすればメモを参考にする.
どうすればメモを参考にして,マップ上からターゲットとなるアクターと一言フレーズを最終的には決定する.

これが決まったらスプリントクエスチョンを見直して,今回のターゲットで答えることができるものをピックアップする.

月曜日まとめ

長期目標でプロジェクトの達成すべきゴールを定めて,それに関連するスプリントクエスチョンを洗い出した.

全体を俯瞰するためのマップを作り,専門家の意見を取り入れてブラッシュアップした.

さらに,専門家の意見からどうすればメモを作り,チームの興味ある方向を共有した.

上記を受けて今回のスプリントでターゲットとなる瞬間を決定し,これによって答えが得られるスプリントクテスチョンが明らかになった.

残りの4日間はこれを明らかにするために頑張ろう.

とりあえず,月曜日のお仕事はこれにて完了.

人工知能研究会なるものに参加させていただきました

下記の研究会に参加させていただきました. 学生さんが主体でやっている研究会だそうです.

第17回 人工知能研究会「今後のDeepLearning技術の発展とビジネス応用」 https://air-osaka.doorkeeper.jp/events/60057

今日の研究会で聞けた内容が良かったのでお話を聞きながら取ったメモを晒します.

ビジネス応用

ビッグデータ解析と人工知能の違い

ビッグデータ解析は解析しておしまい. 一回では大抵良い結果は出ないのでうまくいかない.

人工知能はシステムを利用するたびに精度が上がっていく. 実運用しながら精度が上がっていくのが人工知能の特徴.

溜まったデータを解析することが目的となってはいけない. 何がしたいのか?そのために必要なデータはどんなデータか?を固めていくことが大切.

そしてデータは必ずしもビッグでなくてはならないわけではない

AIを導入しやすい領域

技術的課題

AIとの親和性が高い(ルール化・パターン化されている) データが取りやすい

社会的課題

AIが失敗しても被害が少ない(人が死なない・大損しない) AIに否定的な人が少ない

  • クラスタ別に分析が資料上ではありました.*
  • あの資料欲しいな・・・*

ビジネス利用のための人材育成のお話

データサイエンティストとして備えておくべきもの

  • 統計学
  • プログラミング
  • ビジネス知識 => お客さんの課題をどうAIに落とし込むか

それ以外にも幅広い知識が必要 物理とか数学とか心理学とか英語とか.

統計:理由を説明する学問.要因を見つける. 例)アイスクリームの売り上げを分析して主因を見つけたりする

機械学習:予測.当てればそれでいい.予測精度の追求. 例)アイスクリームの売り上げさえわかればいい!

AIシステム構築の流れ

課題設定=>AIモデル設計=>データ取得=>データ前処理=>アルゴリズム実装=>分析=>結果=>AIモデル設計へフィードバック

この流れを繰り返すのがとても大切. このために,データサイエンティストには幅広いアルゴリズムの利用経験と知識が必要.

よくある誤解

とりあえずネットワークにデータぶち込んだらええやん

分類精度をあげるには,データ前処理がとっても大事. 手法選定とかチューニングとかは支配的ではない. データ前処理が何より支配的!

データ前処理は実データ解析において重要. 手法の選択は研究において重要. チューニングはコンペにおいて重要.

一般物体認識と詳細画像識別の違いを把握しておく

一般的に誰が見ても明らかなものの比較と,専門家ではないと判断が難しいものの識別では難しさが当たり前だけど違う.

一般物体認識であればとりあえずデータをニューラルネットワークにぶち込んだらええ.ここら辺はよく論文として扱われる範囲. だから上のようにとりあえずぶち込んだらええやんという誤解が生まれる.

実社会で求められるような詳細画像識別ではこれだとワークしない.適切な前処理をしてあげることが大切.

データが大量に必要だが,質も大事

分析に適するデータベースは縦長(特徴量の次元に対してデータ量が多いという意味). 横長のデータはデータ量を増やして縦長にしてあげる必要がある. 要するに過学習の話だなきっと.

分類対象が増えても問題がない

分類するものが少ないほど精度が上がります. これは当たり前の話だと思うなぁ・・・よくある誤解なのかー

講師の考える今後大事になってくるDeepLearning技術Top4

DeepLearningは伸び代がやばい. 今できることって氷山の一角. 5年後,10年後にできることはもっといっぱいある.

これまでの技術と比べて複雑なモデルを扱えるようになってきた. 複雑であるがゆえに,表現度が高くなった.

2016年の現状 音声認識:実用レベル 画像認識:開発レベル~実用レベル 言語認識:研究レベル

2017年の現状 音声認識:実用レベル 画像認識:ほぼ実用レベル 言語認識:研究レベル~開発レベル

ということで講師が考える今後大切なDeepLearning技術Top4を紹介

第4位 転移学習

データが大量にあるドメインで学習させたモデルをデータの少ないドメインに使う. ドメインが大きく違っても高い精度が出るので一般的によく使われる. 別データで学習させたモデルを使って再学習させる.

コンペとかで優勝したモデルを使って転移することが可能. 画像系と音声系でかなり有効 テキストなどではあまり有用性が確認されていないとのこと.

One-Shot学習というものもある. 転移学習よりさらに少ないデータで学習させる. すでに作成されている特徴量空間に新たなクラスをプロットさせる方法. 少ないデータで学習可能だが,分類対象が増えると難しくなる.

第3位 DCGAN

絵の生成とかに使われる. 生成系と判別系のネットワークを戦わせて学習させていく. より本物に近い絵を作り出す技術っぽい.

画像の一部を欠損させて復元させる技術もある.

第2位 DQN

AI同士を戦わせてより強くしていく. 計算コストかかる.相当なリソースを持っていないと強化学習的な手法は難しい.

囲碁のように勝ち負けが明確な場合は有効だが,現実的な問題として良し悪しがわかりにくい問題については 強化学習のアプローチは難しかったりもする.

第1位 マルチモーダルDeepLearning

あらゆる構造のデータを同時に学習して概念を獲得してく. 言語認識精度の向上が見込まれる.

動画とか音声とかテキストとか数値とか,異なる構造のデータを同様に用いる.

テキストから動画を生成したりすることも可能になってきている.

ELBがApplication層でのロードバランシングに対応したらしい

AWSのELBが、Application層でのロードバランシングに対応したらしいです。 Application層で動くロードバランサーということで、ALBと呼ぶらしいです。

Application層で動作するロードバランサー

通信機能を7つの階層に分割するOSI参照モデル(物理層データリンク層・・・などに分割するモデル)の最上層であるアプリケーション層で動作するロードバランサーです。

アプリケーション層で動作するため、この層で使われているHTTPというプロトコル等をもとに負荷分散をすることが可能になったようです。

現状(2016/08)のALBはHTTPリクエストのURLを用いてバランシングすることができます。

ELBでできなかったことと、ALBでできるようになること

ELBは通信を受け、処理を自身の配下のインスタンスに振り分けるという働きをしてくれていました。この際に、全ての処理を同一グループのインスタンスに負荷を分散しながら振り分けるというのがELBの挙動になります。

一方で、ALBではリクエストのURLに基づいて処理を割り振るグループを選択することができるようになります。

例えばhttp://example.com/*へのアクセスはデフォルトでGroup1に振り分けつつ、http://example.com/fugaへのアクセスのみGroup2に割り振るといったことが可能になります。

利点

これにより、より粒度の小さいサービスの組み合わせによるサービスの提供が可能になります。

例えば、ユーザーというドメインCRUDするようなアプリケーションがあったとします。

http://example.com/user/createでユーザーを作成し、http://example.com/user/delete/{id}でユーザーを削除することができるとします。

ELBでは、ユーザーのCRUD機能を全て実装したサーバーをグループに入れておいて、http://example.com/へのリクエストを各グループに負荷分散して処理を振り分けていました。

これがALBではユーザーのCRUD機能をモノリシックに用意する必要がなくなります。

CreateやDeleteなど機能を単体で用意しておき、それらをGroup1とGroup2にそれぞれ格納します。 そして、http://example.com/user/createへの通信はGroup1に処理を振り分け、http://example.com/user/delete/{id}への通信はGroup2に処理を振り分ければいいわけです。

これによって、よりマイクロなサービスの組み合わせでサービス全体を提供することが可能になるわけです。

ALBを使う上で気をつけたいこと

deployの話

アプリケーションのdeploy周りについては考える必要が出てくる気がします。

ELBを使っていた場合はユーザーのCRUD機能が一枚岩で提供されていたので、deploy時にはまるっと入れ替えることができました。

これがALBを使っている場合はCreate機能やUpdate機能が分割できてしまうので、新旧を無停止で入れ替えようとするとタイムラグが起きて問題になる気がします。

今回は例を示す際にユーザーのCRUD機能をあげましたが、分割の単位はドメインごとに切るなりなんなり、サービスにあった切り口を考える必要があるでしょう。

可用性の話

各グループにそれぞれ別の責務を負わせるわけで、それぞれのグループで可用性を確保する必要があると思われます。複数AZで各グループ用のインスタンスを起動してあげる必要があるでしょう。 結構構成が煩雑になりそうなので、CloudFormationによるコード化はしておいたほうがいいかもしれません。

CloudFormationにはすでにALBも対応しているようで、AWS::ElasticLoadBalancingV2::LoadBalancerというようにElasticLoadBalancingV2ってやつを使ってあげればいいみたいです。

MySQLのスキーマ変更をオンラインでやるための選択肢比較

MySQLを使っていて、スキーマを変更したい場合はAlterTableを流す必要があります。 すでに稼動しているサービスのスキーマを変更する際に、可能な限り稼働中システムに影響を与えずにスキーマの変更を行いたいです。

理想はオンライン状態を保った状態でAlterTableが全て完了することで、これが実現できれば少なくともスキーマ変更に伴うメンテナンスのためのダウンタイムが発生しません。

これを実現するためには幾つか方法が存在し、制約もあるみたいなので調べてまとめてみました。

その前にAlterTableのこれまでの挙動を調べる

オンラインでのスキーマ変更を調べる前に、まずはAlterTableの伝統的な挙動(MySQL5.1まで)について簡単にまとめてみます。これによってオンラインスキーマ変更のために何が問題になっているか?が理解できると思います。

MySQL5.1までのAlterTableは、変更したいスキーマ定義に沿った空のテーブルを作り、そこに古いテーブルのデータをコピーすることでスキーマの変更を行います。 この際にデータの不整合を防ぐため、まずは古いテーブルへのデータの書き込みをブロックするlock状態に入ります(ちなみに、古いテーブルからデータが読み込まれたとしても、新しいテーブルへのデータコピー時に不整合は起きないため、読み込みはブロックされません)。

つまり、AlterTable実行中は書き込みがlockされるわけです。 古いテーブルに大量のデータが入っている場合には、新しいテーブルへのデータコピーに時間が掛かるわけなので、書き込みlockによるメンテナンスのためのダウンタイムがどんどん伸びていくわけです。

これがMySQL5.1までのスキーマ変更の挙動でした。

参考にさせていただいた記事はこちら

MySQL5.6からサポートされているオンラインDDL

DDLはデータ定義言語というもので、データベース自体を操作するためのSQL命令文のセットです。 AlterもDDLに含まれます。

多くのAlterTableの操作時に、上記のテーブルのコピーが発生しないようにする変更と、テーブルが変更されている時でも書き込みがロックされないようにした変更の2つを合わせてオンラインDDLと呼ばれています(ちなみに念のためですが、ロックが発生しないだけで、性能上の影響は当然出ます)。

あくまで 多くのAlterTable時であり、全てにおいてコピーが発生せず、書き込みがロックされないというわけではありません。 ざっくり書き込みロックされるされないで分類してみます。

書き込みロックされない

インデックスの作成,追加,削除 カラムのデフォルト値を設定する カラムの自動インクリメント値を変更する 外部キー制約を追加,削除する カラムを名前変更,追加※,削除,並べ替え 主キーを追加する ※オートインクリメントカラムの追加を除く

書き込みロックされる

全文検索インデックスを追加する カラムを追加する(オートインクリメントカラムの追加) カラムのデータ型を変更する 主キーを削除する 文字セットを変換する

参考にさせていただいたのはこちら

つまり、MySQL5.6からは変更の内容によりますが、AlterTable実施時にロックが発生しないケースもあるということです。

pt-online-schema-change

Percona-Toolkitという有名なツールキットに同梱されているpt-online-schema-changeというツールがあり、こちらを使うことでも読み書きロックなしでオンラインスキーマ変更が可能です。

pt-online-schema-change(長いので以後PT)はMySQLのAlterTableの挙動を内部的に再現してスキーマの変更を行いますが、工夫することでロックなしでの動作を可能にしています。

MySQL5.1では古いテーブルの書き込みをロックしてデータの不整合を防いでいました。 これに対して、PTはトリガーの仕組みを使うことで、書き込みロックを行わずにデータの整合性を保ちます。 古いテーブルから新しいテーブルへのデータコピー中に古いテーブルに対して更新が走った場合、トリガーが古いテーブルのデータ更新に伴って新しいテーブルのデータも更新するわけです。

トリガーはInsert, Update, Deleteの3種類全てが貼られます。 そのため 1つのテーブルに対して同じ種類のトリガーは貼れないため、トリガーがすでに貼られているようなテーブルにはPTは使えません。 なお、トリガーはMySQL5.0.2からサポートされるので、PTはMySQL5.0.2以上で動作するそうです。

参考にさせていただいたのはこちら

比較とまとめ

MySQLのオンラインDDLでもPTでもそれぞれ制約はありますがオンラインでスキーマ変更が可能であることがわかりました。オンラインDLLは、オンラインで実行可能なスキーマ変更の種類に制約があり、PTでは既存トリガーの有無が制約になることがわかりました。 また、オンラインDDLはMySQL5.6から、PTはトリガーをサポートしているMySQL5.0.2から動作することがわかりました。

次に性能比較ですが、こちらの記事によると、スキーマ変更にかかる時間は対して変わらないものの、スキーマ変更中の影響という観点からはPTの方オンラインDDLよりも小さいそうです。 さらに、PTでは設定できるオプションが多く、既存システムへの影響を考えながらきめ細やかな実行戦略が組めそうです。 サイバーエージェントさんのこちらの記事にある慎重に使うオプションや過去の失敗事例もすごく参考になります。

以上です。