目次
※この記事は次のブログを翻訳したものになります。
原文:The Delete by Query API Is now a plugin
Elasticsearchの2.0.0-beta1では、これまであった Delete by Query APIが削除され、 新しく Delete by Query pluginに置き換えられています。
もし、Delete by Query を利用する場合、2.0にアップグレードしたあとは、プラグインをインストールし、ドキュメントに従ってください。
bin/plugin install delete-by-query
なぜプラグインに?
ElasticsearchのコアなAPIの品質を保つためであり、以前のDelete by Queryの実装は簡単にはフィックスできない大きな問題がありました。
- 各リクエストのあとに、refreshを実行します。これは、削除されたデータが想定外に検索に出てこないようにするためです。
また、セグメントが大量にでき、マージが大量に発生し、ヒープが大量に消費されてインデキシングが劇的にスローダウンし、クラスタの複数のノードがクラッシュしてしまう状況も引き起こしました。 - このクエリは、プライマリ、レプリカの両方で実行されるため、ことなるドキュメントを削除し、矛盾したレプリカ(データの破損)を引き起こしました。
- アップグレードが不安定になります。これは、Delete by Queryリクエストがトランザクションログの中にクエリとして残るためです。そのため、アップグレードのあとに正確にパースされなかったり正確に実行されないかもしれません。例えば、インデックスエイリアスに対するリクエストで、それが削除された後の場合にこのようなバグが発生します。
対照的に、新しいプラグインは、安全な実装です。 scanとscrollリクエストでクエリにマッチしたIDを見つけ、そのIDを使って、bulk indexing APIで削除します。
この実装は、遅い必要があります。特に、クエリが多くのドキュメントを削除する場合です。 もし、多くのドキュメントをこのAPIを利用して削除する場合、アプリケーションをテストしてください。 そして、代わりにインデックス全体を消すようなアプローチに切り替えることができないか検討してください。
Delete by Query pluginのドキュメントに、新しい実装についての違いなどのより詳しい説明があります。
Elasticsearch coreを最小限に
プラグインに切り替えることは、簡単な決断ではありませんでした。 多くのユーザは問題なく、Delete by Queryを利用していました。 しかし、危険が常にそこにあり、些細とは言い切れない数のユーザが上記のような深刻な問題に遭遇していました。
さらに、Elsticsearchのコアは信頼できるものでなければなりません。 他のコアAPIを利用して実装できる機能は、コアに含みません。特に、それがバグを含んでいる場合。 コアのすべての機能は強固であるべきで、Delete by Queryは人気があり、高性能ですが、そうではありませんでした。
必要に応じて、このような難しいトレードオフの末、信頼性と品質を選びます。
マッピングの削除の廃止
タイプのマッピングを削除する機能も2.0で廃止されます。 これは、同じフィールド名を、異なるフィールドのタイプで再利用した場合に、インデックスの破損を引き起こす可能性があるためです。
しかし、Match All Queryで、Delete by Queryプラグインに対してタイプを指定することで、タイプのすべてのドキュメントを削除することはできます。 または、1つのインデックスに異なるタイプを複数含める代わりに、個別のインデックスに分割するようなアプローチに変更することを検討してください。
comments powered by Disqus
See Also by Hugo
- Mappingのすばらしいリファクタリング(日本語訳)
- validate APIの利用
- 機械学習による検索ランキング改善ガイドを読みました
- Querqyの調査(その2:アーキテクチャ)
- Kuromojiのカスタム辞書をインデックスの設定で指定