DBマイグレーションツール: Liquibase と Flyway の比較議論

StackOvevflow - DB Migration tool Liquibase or Flyway? をざっと翻訳 (as of 2013.6.18)

訳注サマリ：複数データベース考慮が不要で実SQLをシンプルに扱うならFlyway、複数データベースを考慮して抽象化もさせてより高度にマイグレーションするならLiquibase

Question

J2EE ウェブアプリケーションのためにDBマイグレーションツールを使いたいと思っています。このアプリは、Jenkins サーバで継続的統合がされます。また、Ant と Maven も使っているので、(可能なら)その両方に対応したものがいいです。

シンプルで簡単な設定がいいですが、将来的に異なる複数のデータベースをサポートすることも必要です。

現在、Liquibase と Flyway と見ています。上記を満たすためにどちらが、なぜよいかを知りたいです。

Answer

Answer (37 votes) by Axel Fontaine

cdeszaq が既に言っているように、[Flyway Homepage] にある機能比較マトリクスは、よい出発点です。

Liquibase と Flyway の両方とも、Maven と Ant へ統合できます。

次のステップは、Liquibase の XML ないしは注釈付き(annotated)のSQLフォーマットを使うか、(Flywayの)プレーンなSQLを使うないしはJavaで書いたマイグレーションを行いたいかを決定することです。

それぞれ、メリット・デメリットがあります。

• Liquibase XML: 最小限のDB非依存の最大公約数のフォーマット。DDLを書かなくて良くなるし、DB間で互換性がある。ベンダーロックインではある(問題になるかもしれない。ならないかもしれない。)
• Liquibase annotated SQL: Liquibaseのメタデータをコメント(必須)に付与したSQL。実行時にカスタムのSQLブロックとともにLiquibase XMLに変換されす。DB間で互換性があるかもしれないし、ないかもしれない。SQL with Liquibase metadata in comments (must be present).
• Plain SQL (Flywayのみ): 通常のDDL SQLファイル。DB間で互換性があるかもしれないし、ないかもしれない。特別なアノテーションはない。ネイティブなDBツールを使って出力したDB構成のダンプが使える。ツール依存はない。ロックインがない。
• Java migrations (Flywayのみ): JDBC API を使ったJavaクラスのマイグレーション。業務アプリケーション(LOB)の複雑なデータ変換を扱うのに適している。DB間で互換性があるかもしれないし、ないかもしれない。ベンダーロックインではある(問題になるかもしれない。ならないかもしれない。)
• DDL のポータビリティに関するちょっとしたノート: H2のようなインメモリDBは、”実”DBへの互換モードがある。これだけで、追加で互換性のための抽象化をする必要性がなくなる。

他にも考えられる相違点がいくつかあります。

• PL/SQLや T-SQL、MyQLやPostgreSQLのストアドをそのままダンプしてつかいたいなら、Flyway にしましょう。
• もし、DDLがデータベース間で非互換で、LiquibaseのXMLやベンダー特有の機能を使うことを気にしないなら、Liquibase にしましょう。
• Flywway にサポートされていないDBが必要なら、Liquibase にしましょう。
• (たとえば、参照データなど) 業務アプリケーション(LOB)のサポートが必要なら、Flyway にしましょう。

シンプルさ と アプリケーション統合 については、言及してませんでした。ここは Flyway が輝ける領域であると信じています。とても軽量で、アプリケーション統合はこれ以上簡単にできないぐらい簡単に出来ます。

YAGNIの精神に基づいて手っ取り早く: ニーズに合った最もシンプルなツールを使いましょう！

ノート: ここのダウンマイグレーションは、ここにかいたように、おとり(薫製のニシン。訳注：ニュアンスいまいち)です。

免責情報: 私はFlaywayの開発者の一人で、フィードバックを待っています。:-)

Answer (17 votes) by Mark O'Connor

Flyway はとても似たツールです。軽くて、シンプルで、よい統合ができます。もし、すべての変更がSQLで収まるなら、どんなレベルの開発者でも抵抗感がないでしょう。

ただ、個人的にはやっぱりLiquibaseです。Liquibaseは、もっとパワフルな機能があります。

• すべてのデータベース変更は、"リファクタリング"としてモデル化されます。ロールバックも可能です。
• DBAレビューのためのSQLスクリプト 生成
• 現在のデータベースからのスキーマ抽出
• データベースインスタンス間のdiff操作
• 複数データベースのサポート
• 条件を指定したチェンジセットの実行(DB、またはcontext や changeset に基づいた変更)

Answer ( 9 votes) by Nathan Voxland

書かれている要件の「将来的に異なる複数のデータベースをサポートする」を考えるなら、Liquibaseの法が良いでしょうあ。Flyway はデータベース特有の生SQLスクリプトを走らせることを中心にデザインされています。一方で、Liquibaseは変更をデータベース中立な方法で記述するオプションを持っており、アップグレードスクリプトは複数のデータベースに利用することができる。もし、Flyway (ないしはLiquibaseの注釈付きSQL)から始めたとしてら、異なるデータベースにデプロイしようとし始めるまでは動作するでしょうし、そこでスクリプトを書き換える必要があるでしょう。

もし、データベースを横断したサポートというものが、小さい課題であるのなら、Liquibase vs Flyway で、その他の機能と設計思想について比較しましょう。Axel の比較は良いものです、しかしながら、私は Flyway が Liquibase に比べて、"よりシンプル"だとは思いません。Liquibase は もっと多くの機能を持つ一方 (データベースdiff、チェンジログパラメータ、プリコンパイル、dbdoc、ロールバックスクリプト生成、実行用出力SQL)で、通常の”変更をすべてのデータベースに適用する”ケースでは、Flyway と同様に、とても直接的でシンプルです。

違いをサマリすると、

Flywayは、”低レベル”で必要なSQLを正しく書いていく、一方で、Liquibase は、”高レベル”で変更したいものを記述し、Liqubase はSQLを算出します。Flyway は、変更をファイル名で管理し、Liquibase は 変更をファイル内の順序で管理します。

免責事項: 私は Liquibase の開発者です。