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 の開発者です。