1. ソースコードのオンラインアドレスを再インデックスする
参考までに、再インデックスの github ソース コード アドレスを次に示します。
https://github.com/elastic/elasticsearch/blob/001fcfb931454d760dbccff9f4d1b8d113f8708c/server/src/main/java/org/elasticsearch/index/reindex/ReindexRequest.java
再インデックスに関するよくある質問:
2. ソースコードの再インデックスの本質
インデックス再作成操作の本質は、1 つ以上のソース インデックスからドキュメントを読み取り、それらのドキュメントをターゲット インデックスにインデックス付けすることであり、場合によってはドキュメントに対するいくつかの変換が含まれます。
ソース コードから派生した再インデックス操作の重要なポイントは次のとおりです。
2.1 ソースとターゲット
ReindexRequest は、ソース インデックス (ドキュメントの読み取り元) とターゲット インデックス (ドキュメントのインデックス付け先) を定義します。
2.2 クエリとフィルタ
ソース インデックスに対してクエリを定義して (setSourceQuery メソッドを使用)、どのドキュメントのインデックスを再作成する必要があるかを決定できます。
つまり、特定の検索ステートメントを満たすデータを移行できます。
2.3 ドキュメントの変換
スクリプトが提供されている場合は、ドキュメントをソース インデックスからターゲット インデックスに移動する前に変更または変換できます。
2.4 バッチ処理
ドキュメントはソース インデックスからバッチで読み取られ、ターゲット インデックスにバッチでインデックス付けされます。
バッチ サイズはsetSourceBatchSizeメソッドで調整できます。
この値がどのくらい大きくなるかは、ソース コードでは表現されていません。ただし、次のルールを知っておく必要があります。
非常に大きなロール サイズを設定しても、メモリ使用量とクラスター ノード間のデータ転送が増加するため、クラスターにストレスがかかる可能性があります。
したがって、クラスターに過度のストレスを与えずに良好なパフォーマンスを確保するには、適切なスクロール サイズを選択することが重要です。
2.5 リモートソースのインデックス作成
reindex は、現在の Elasticsearch クラスター内のインデックス間でドキュメントを移動する (図 1 を参照) だけでなく、リモート Elasticsearch クラスターからドキュメントを読み取ることもできます(図 2 を参照)。
これは、リモート クラスターに関する必要な情報がすべて含まれている RemoteInfo クラスを通じて実現されます。
次の情報が含まれます。
リモート クラスターのアドレス (URL または URI の場合があります)
認証情報（ユーザー名やパスワードなど）
リクエストヘッダー (リモートリクエスト用にカスタマイズされた特定のヘッダー)
接続タイムアウトとソケットタイムアウト
リモートクラスターと対話するために必要なその他の構成情報
2.6 検証
インデックス再作成操作が実行される前に、リクエストが有効であることを確認するために一連の検証チェック (validate メソッドを使用) が実行されます。
2.7 シリアル化/逆シリアル化
ReindexRequest クラスには、リクエストをネットワーク トランスポート形式にシリアル化したり、ネットワーク トランスポート形式から逆シリアル化したりするためのメソッドが含まれています。
これにより、Elasticsearch ノードが効率的に通信し、再インデックスリクエストを実行できるようになります。
2.8 出力
ReindexRequest は、ログ記録やデバッグに役立つ説明文字列 (toString メソッドを使用) または XContent 形式 (通常は JSON、toXContent メソッドを使用) に変換できます。
要約すると、インデックス再作成操作の本質は、ソース インデックスからドキュメントを読み取り、場合によってはいくつかの変換を実行し、これらのドキュメントをターゲット インデックスにインデックス付けすることです。
この操作は、現在のクラスター内のインデックス間、またはクラスター全体で実行できます。これは、データ移行、インデックスの再編成、データ変換などのタスクに使用できる強力なアプローチです。
3. 再インデックスの高速化
再インデックス操作の速度は、いくつかの要因によって影響されます。再インデックス操作を高速化したい場合は、次のような提案があります。
3.1 バッチサイズを調整します。
ReindexRequest には、バッチごとのドキュメント数を設定できるsetSourceBatchSizeメソッドがあります。
/**
* Sets the scroll size for setting how many documents are to be processed in one batch during reindex
*/
public ReindexRequest setSourceBatchSize(int size) {
this.getSearchRequest().source().size(size);
return this;
}バッチ サイズを増やすとパフォーマンスが向上する可能性がありますが、バッチが大きすぎるとメモリの問題やリクエスト タイムアウトが発生する可能性があることに注意してください。
3.2 スライス並列処理
スライスは、Elasticsearch の再インデックス操作の高速化に非常に役立ちます。スライスは、大きなクエリをより小さな部分に分割し、並列実行して全体の操作を高速化する方法です。
ReindexRequest クラスには、特定のスクロール リクエストのサブスライスを作成できるメソッドforSlice (TaskId slicingTask、SearchRequest スライス、int totalSlices) が表示されます。
どのように練習すればよいでしょうか？
スライス数の設定について: 再インデックス操作を実行するとき、slices パラメーターを設定して、必要なスライスの数を指定できます。
たとえば、スライス数: 5 を選択した場合、Elasticsearch はクエリを 5 つのサブクエリに分割し、ドキュメントを可能な限り均等に分散しようとします。
並列実行の高速化
スライスを使用すると、各スライスを別のスレッドまたはノードで並行して実行できます。このように、複数のノードまたは十分なリソースがある場合、スライスによってインデックスの再作成が大幅に高速化されます。
実際のコマンド:
Elasticsearch REST API では、スライスを使用してインデックスを再作成するコマンドは次のようになります。
POST _reindex
{
"source": {
"index": "old_index",
"size": 1000,
"slice": {
"id": 0,
"max": 5
}
},
"dest": {
"index": "new_index"
}
}上記のコマンドでは、元のインデックスを 5 つのスライスに分割し、id パラメーターを使用して現在のスライスの番号を指定しました。
すべてのスライスを並列実行するには、スライス番号 (この場合は 0 ～ 4) ごとにこのコマンドを実行する必要があります。
スライスに関する注意事項
スライスにより操作が高速化される一方で、各スライスが独自のスクロール コンテキストを作成するため、クラスターに負担がかかる可能性もあります。Elasticsearch クラスターに、選択したスライスの数を処理するのに十分なリソースがあることを確認してください。
スライス操作の最適な数は、データ、クエリ、クラスター構成によって異なります。最適なスライス数を見つけるには、パフォーマンス テストが必要になる場合があります。
一般に、スライスはインデックス再作成操作の速度を大幅に向上させることができます (すぐに検証し、事実で証明します) が、速度を向上させながらクラスターに過度の負担をかけないよう、スライスが正しく使用されていることを確認する必要があります。
3.3 クエリの最適化
インデックス再作成リクエストでドキュメントをフィルタリングするためにクエリを使用した場合は、クエリが最適化されていることを確認してください。複雑なクエリや非効率なクエリは避けてください。たとえば、複雑なネストされたクエリ、ワイルドカードのあいまいクエリなどは、できる限り避ける必要があります。
3.4 ハードウェアリソースの増加
Elasticsearch ノードの CPU、メモリ、および I/O 機能を増やすと、インデックス再作成の速度が向上します。
リモート クラスターからインデックスを再作成する場合は、両方のクラスターに十分なリソースがあることを確認してください。
これは大量のデータの場合に当てはまります。
3.5 インデックス設定の最適化:
ターゲット インデックスのフラッシュやレプリカなどの一部の機能を一時的に無効にします。インデックスの再作成が完了したら、再度有効にします。
レプリケーションを無効にするindex.number_of_replicasには、0 に設定します。
フラッシュを無効にするindex.refresh_intervalには、-1 に設定します。
3.6 取り込みパイプラインの使用
インデックス再作成操作でドキュメントを変換するためにスクリプトを使用している場合は、スクリプトよりも効率的な可能性があるIngest Pipelinesの使用を検討してください。
3.7 ネットワークの最適化
リモート クラスターからインデックスを再作成する場合は、ネットワーク接続が高速かつ低遅延であることを確認してください。再インデックス要求が帯域幅を完全に利用できるように、他のネットワーク集約型操作の使用を制限します。
これは周縁化された提案であり、常識はあなたが知っていなければならないものです。
3.8 その他の操作を制限する
クラスターのオフピーク時間再インデックス操作を実行し、大規模な検索やセグメントのマージなどの他のインデックス作成操作など、リソースを大量に消費する操作を制限するようにしてください。
3.9 プラグインと外部スクリプトの確認
プラグインや外部スクリプトがインデックス再作成操作のパフォーマンスに影響を与えていないことを確認してください。
3.10 モニタリングとチューニング
Elastic Stack 監視機能などの Elasticsearch 監視ツールを使用して、インデックス再作成操作のパフォーマンスを監視します。これはボトルネックを特定し、それに応じて調整するのに役立ちます。
これらの推奨事項を念頭に置いて、運用環境でテストして最適な設定と最適化戦略を見つけることが最善です。
4. 再インデックスはスライスを使用して検証を高速化します
4.1 準備
条件 1——十分な大きさのデータを選択または作成します。
パフォーマンスの違いを顕著にするには、大きなインデックスが必要です。小さなデータセットでは、目立った違いが見られない場合があります。
条件 2 - クラスターが正常であることを確認します。
テストを開始する前に、Elasticsearch クラスターが正常であり、すべてのノードがオンラインであり、保留中のタスクがないことを確認してください。
条件 3 - 他の大規模な操作を終了します。
パフォーマンス テストの結果に影響を与えないように、クラスター上で他の大規模なクエリやインデックス作成操作が実行されていないことを確認してください。
4.2 スライスを使用しない再インデックス
記録開始時刻。
スライスを使用せずに再インデックス操作を実行するには、_reindex API を使用します。
完了時間を記録します。
期間を計算します。
## 第一种：直接迁移。
"took": 4005,
POST _reindex
{
"source": {
"index": "image_index"
},
"dest": {
"index": "image_index_direct"
}
}
GET image_index_direct/_count4.3 スライスを使用したインデックスの再作成
スライスの数を選択します。たとえば、データ ノードが 5 つある場合は、5 つのスライスを試してみるとよいでしょう。
記録開始時刻。
_reindex API を使用して再インデックス操作を実行し、スライスごとに個別のリクエストを作成します。並列コマンドやスクリプトなどの同時実行ツールを使用して、すべてのリクエストを並列実行できます。
すべてのスライスが完了した時間を記録します。
合計時間を計算します。
## 第二种，加了并行处理！
POST _reindex
{
"source": {
"index": "image_index",
"slice": {
"id": 0,
"max": 5
}
},
"dest": {
"index": "image_index_slice"
}
}4.4 比較
2 回のインデックス再作成の合計時間を比較します。理論的には、特に多くのノードと大量のデータを含むクラスターでは、スライスを使用するバージョンの方が高速になるはずです。
下記の動画の通り、小規模な検証を優先しました。
データ量は 16MB で、数万件のデータ移行結果を比較すると次のようになります。
| 移行方法 | 時間がかかる |
|---|---|
| 直接転送 | 4005ミリ秒 |
| スライスの移行 | 1123ミリ秒 |
データ量は 112MB で、150,000 件の昌津湖映画レビューのデータ移行結果が比較されます。
| 移行方法 | 時間がかかる |
|---|---|
| 直接転送 | 約 30000 ミリ秒 (その後のビデオ再生で確認) |
| スライスの移行 | 10263ミリ秒 |
上記の 2 桁異なるデータの再インデックス結果に基づいて、スライスを追加すると速度が 3 ～ 4 倍向上することがわかります。
より多くのノードスケールのクラスターと大規模なデータについては、結果についてのフィードバックをお待ちしています。
5. まとめ
計画を立てて、さらに実践すれば、より説得力のある結果が得られます。
来て！
推奨読書
より多くの乾物をより短時間で素早く入手できます。
世界中の約 2,000 人以上の Elastic 愛好家と一緒に改善しましょう!
大型モデルの時代、一歩先行く先進乾物を学ぼう！