web-dev-qa-db-ja.com

ElasticsearchのLiquibaseまたはFlywayデータベース移行の代替手段

私はESにかなり慣れていません。私は長い間データベース移行ツールを検索しようとしていましたが、見つかりませんでした。誰かが私を正しい方向に向けるのを手伝ってくれるかどうか疑問に思っています。

プロジェクトのプライマリデータストアとしてElasticsearchを使用します。プロジェクトで新しいモジュールを開発するときに実行するすべてのマッピングおよび構成の変更/データインポート/データアップグレードスクリプトをバージョン管理したいと思います。

以前は、FlywayやLiquibaseなどのデータベースバージョン管理ツールを使用していました。

同様のことを達成するためにESで使用できるフレームワーク/スクリプトまたはメソッドはありますか？

スクリプトを使用して手動でこれを実行し、少なくともアップグレードスクリプトを実行する移行スクリプトを実行した経験のある人はいますか？.

前もって感謝します！

javaelasticsearchmigrationliquibaseflyway
27
Istvano

この観点/必要性から、ESには大きな制限があります。

  • 動的マッピングがあるにもかかわらず、ESはnotスキーマレスですが、スキーマ集約的です。この変更が既存のドキュメントと競合する場合、マッピングを変更することはできません（実際には、新しいマッピングが影響するnull以外のフィールドがあるドキュメントがある場合、これにより例外が発生します）
  • eSのドキュメントは不変です。インデックスを作成すると、取得/削除できるのはでのみです。これに関する構文上の糖衣構文は部分的な更新であり、ES側でスレッドセーフな削除+インデックス（同じID）を作成します

それはあなたの質問の文脈でどういう意味ですか？基本的に、ES用の従来の移行ツールを使用することはできません。そして、ESでの作業を簡単にする方法は次のとおりです。

  • 厳密なマッピングを使用します（"dynamic": "strict"および/またはindex.mapper.dynamic: false、 マッピングドキュメント を参照してください）。これにより、インデックス/タイプが

    • 誤って間違ったタイプで動的にマッピングされている
    • データマッピング関係でエラーを見逃した場合に明示的なエラーを取得する

  • 実際のESマッピングを取得して、データモデルと比較できます。 PLにES用の十分に高いレベルのライブラリがある場合、これは非常に簡単です。

  • 移行に インデックスエイリアス を活用できます

だから、少しの経験。私にとって、現在合理的なフローはこれです：

  • コード内のモデルとして記述されているすべてのデータ構造。このモデルは実際にはORM抽象化も提供します。
  • インデックス/マッピング作成の呼び出しは、単純なモデルのメソッドです。
  • すべてのインデックスには、実際のインデックス（つまり、news_index_{revision}_{date_created}）を指すエイリアス（つまり、news）があります。

コードがデプロイされるたびに、

  1. モデル（タイプ）マッピングを配置してみてください。エラーなしで実行された場合、これはどちらかを実行したことを意味します

    • 同じマッピングを置く
    • 古いものの純粋なスーパーセットであるマッピングを配置します（新しいフィールドのみが提供され、古いものは変更されません）
    • 新しいマッピングの影響を受けるフィールドに値を持つドキュメントはありません

    これはすべて、実際には、持っているマッピング/データを使用して、いつものようにデータを操作するのが良いことを意味します

  2. ESが新しいマッピングに関する例外を提供する場合、あなた
    • 新しいマッピング（name_{revision}_{date}のような名前）で新しいインデックス/タイプを作成します
    • エイリアスを新しいインデックスにリダイレクトする
    • bulk 高速再インデックス作成のリクエストを行う移行コードを起動します。この再インデックス作成中に、エイリアスを介して通常どおり新しいドキュメントに安全にインデックスを作成できます。欠点は、インデックスの再作成中に履歴データが部分的に利用できることです。

これは、実稼働テスト済みのソリューションです。このようなアプローチに関する警告：

  • 読み取り要求に一貫した履歴データが必要な場合は、そのようなことはできません。
  • インデックス全体のインデックスを再作成する必要があります。インデックスごとに1つのタイプがある場合（実行可能なソリューション）、それで問題ありません。ただし、マルチタイプのインデックスが必要になる場合があります
  • データネットワークの往復。時々痛みを伴うことがあります

これを要約すると：

  • モデルを適切に抽象化するようにしてください。これは常に役立ちます
  • 履歴データ/フィールドを古くしてください。このアイデアを念頭に置いてコードを作成するだけです。最初は音よりも簡単です。
  • ES実験ツールを活用する移行ツールに依存することは避けることを強くお勧めします。これらは、river-*ツールのように、いつでも変更できます。
28
Slam