DBマイグレーションツール（Schemeマイグレーションツール）: Evolutions と Flywayについて調べてみた

db

はじめに

DB（Scheme）マイグレーションツールを使うにあたって，いろいろ調べたことをまとめて置こうと思う． 基本的には，EvolutionsとFlyway焦点をあててます． この2つのどちらを採用すればよいかを考えるために調査しました． 実績や運用時の失敗などがあれば教えていただけると幸いです．

DBマイグレーションツールとは何をするものなのか

DBマイグレーションとはDBMSの移行をすることで（例えばMySQLからPostgreSQLへ移行するとか）， それをサポートするツールのことを指す． この機能は，Railsでいち早く採用されたらしい（RubyにはMigr8というのがある）． しかし，調べているとDBMSの移行という意味よりも， TABLEのSchemeマイグレーションのことを指して言っていることもあった．

EvolutionsもFlywayもPlainなSQLファイルを使ったSchemeマイグレーションツール． 簡単に言うと，スキーマのバージョン管理のようなもの． と言いつつも，TABLEにはデータが入っているため，特定のバージョンに戻すのは難しい．

記述方法

  • DSLで書くものや，生のSQLを記述
  • XMLでDBMSに依存しない形で記述
  • Evolutionsã‚„Flywayは生のSQLで記述

記述内容

大きく分けてUpとDownがある． - Up: バージョンを上げるときの動作（Railsでは migrate） - Downs バージョンを戻すときの動作（Railsでは rollback）

ここで，Evolutionsとflywayをみてみると． 基本的にどっちもrollbackはできない（gitみたいに前のバージョンにホイッと戻せない）． FlywayはそもそもDownsが存在しない（逆に安全？）．

Evolutionsの挙動

挙動があやしいとの噂があるEvolutions．

Downsについて

Downはいつ実行されるかという件を調べていたら次のような記事があった．

簡単に訳すと， Downsはスクリプトが変更された時に使われる． 2.sqlがあって，2.sqlが変更されたとする．するとPlayはDownsを走らせてから新しい2.sqlのUpsを走らせる． 知るかぎりではDownsを手動で実行する方法はなく，それはApplicationとDBの関係を崩す状態になるため，エラーが起きる可能性がある． もし，戻したい変更を書くなら3.sqlのUpsに書くといい．

 sqlファイルに変更があった場合の実行順序について

簡単にまとめると， Evolutionsは一番purefixの大きいSQLファイルに変更があった場合，対象のファイルのDownsが走ってから新しいUpsが走る．

  • 1.sql, 2.sql, 3.sqlが存在するとする．
    • 2.sqlを変更しても何も実行されない．
    • 3.sqlが実行された場合変更を検知し，3.sqlのDownsが走ってから変更後の3.sqlのUpsが走る．
    • 2と3に変更があった場合，3:Downs, 2:Downs, 2:Ups, 3:Upsの順番で実行される．

FlywayとEvolutions

  • どちらもplay-pluginある
  • FlywayはDBPlugin非依存
  • FlywayはUpsのみ - FlywayはCLIがある

FlywayとEvolutionsとかいいつつも，Flywayに関することしか書いてない． Evolutionsを選ぶ理由が特にないというのもある．．．

どうやって選ぶのか？

  • そもそもSchemeマイグレーションツールを使って管理する必要があるのか？
  • DB-pluginに依存してもいいのか？問題ないか？
  • Downsは必要か？不要か？
  • DSLか生SQLか？

などの条件を考える感じになりそう．

選択肢

  • gitで管理
  • Evolutionsを使う
  • Flywayを使う
  • Liquibaseを使う（XML）

Evolutionsはいろいろ，良い噂を聞かないのでまず却下． LiqibaseもDBMSの鞍替えとかは考えないので却下． gitでも，Flywayのどっちかかなという感じ． Playと連携させるとするとFlywayかなぁ．

 Evolutionsを使った人達の声

参考文献