、効率的でスケーラブルなデータ保存と取得のための人気のテクノロジーです。ただし、パフォーマンスとデータの整合性を維持するには、再インデックスと呼ばれる重要な作業が必要です。インデックス作成は Elasticsearch にデータを追加する最初のプロセスですが、再インデックス作成はデータの正確性を維持し、検索パフォーマンスを最適化するために不可欠です。 Elasticsearch は 経験豊富な Elasticsearch ユーザーであっても、まだ使い始めたばかりであっても、効率的な Elasticsearch クラスターを維持するためには、再インデックス化を理解することが重要です。この記事では、Elasticsearch の再インデックス化の基本、それが必要なタイミング、それをトリガーする方法、Elasticsearch クラスターを最大限に活用するためのベスト プラクティスについて詳しく説明します。 Elasticsearch の再インデックスを理解する Elasticsearchでは、再インデックスはデータの整合性を維持し、パフォーマンスを向上させるのに役立ちます。簡単に言えば、データを1つのインデックスから別のインデックスにコピーするプロセスです。これは単純に聞こえるかもしれませんが、正しく実行されないと、データの取得が遅くなったり、結果が不正確になったりするなどの問題が発生する可能性があります。 Elasticsearch インデックスを整理整頓された図書館として想像してみてください。時間が経つにつれて、本を更新したり、並べ替えたり、さらには交換したりする必要が生じることがあります。再インデックスは、図書館の棚を並べ替えたり、本を更新してすべてを整理するのに似ています。再インデックスを行わないと、図書館が整理整頓されなくなり、検索が遅くなったり、データが不正確になる可能性があります。 この例えは、Elasticsearch の再インデックス化を理解することの重要性を強調しています。これは単にデータをコピーすることではありません。効率的な検索と取得のために「ライブラリ」の整合性を維持することです。 、それを適切に管理する方法を見てみましょう。 再インデックス化が必要な場合と 再インデックスはいつ必要ですか? Elasticsearch データ モデルやマッピングに変更があった場合、またはパフォーマンスの向上を求めている場合は、再インデックスが不可欠になります。このセクションでは、これらのシナリオを詳しく見ていき、再インデックスが必要な理由について理解を深めます。 データモデルの構造的変化 データ モデルの構造変更とは、Elasticsearch 内でデータが構造化される方法を変更することです。これらの変更には、新しいフィールドの追加や削除、既存のフィールドのデータ型の変更などが含まれます。 新しいフィールドを導入する場合、Elasticsearch がそのフィールドに保存されているデータを効率的に検索する方法を確実に認識できるように、再インデックスが必要になることがよくあります。データ タイプを変更するには、その場でデータ タイプを変更することはできないため、新しいインデックスが必要です。変更されたデータ タイプに対して新しいマッピングが作成されたら、データの再インデックスが必要です。 これらの構造変更には、Elasticsearch の schema-on-write アプローチによる再インデックスが必要です。Elasticsearch は取り込まれたデータをインデックスするため、データ構造を変更すると、既存のデータと新しいスキーマで書き込まれたデータの間に不整合が生じる可能性があります。その結果、再インデックスを行わないと、データ項目のスキーマの不一致により、検索クエリで予期しない結果や不正確な結果が返される可能性があります。これは、データの精度と検索パフォーマンスの両方に影響を及ぼす可能性があります。 マッピングの更新または変更 マッピングは、Elasticsearch でデータがどのようにインデックス化され、クエリされるかの青写真として機能します。これらのマッピングが変更されると、通常は再インデックス化が必要になります。 マッピングは、Elasticsearch 内のフィールドのデータ型とプロパティを定義します。これらのマッピングを変更すると、データのインデックス作成、保存、取得方法に影響します。たとえば、テキスト フィールドを日付フィールドに変更すると、データの処理方法とクエリ方法が根本的に変わります。Elasticsearch は、マッピング定義に基づいてデータの一貫性を確保します。マッピングを変更すると、データが再インデックス化されない場合、既存のデータと更新されたスキーマの間に不整合が生じる可能性があります。 マッピングが変更された場合、特にデータ型やフィールド プロパティの変更を伴う場合は、バックフィルも重要になります。バックフィルとは、既存のデータを遡及的に入力または更新して、新しいスキーマまたはデータ構造に合わせるプロセスです。つまり、マッピングの変更後も、既存のデータを効率的かつ正確にクエリできます。 パフォーマンスの向上とインデックスの最適化 再インデックスは単なる日常的なメンテナンス タスクではなく、Elasticsearch 内の検索パフォーマンスを最適化するための強力なツールです。たとえば、再インデックスを使用すると、インデックス内のシャードの数を変更できます。シャード数を調整する (再シャーディングする) と、データをより均等に分散できるため、特定のノードのワークロードが不均等になるのを防ぎ、検索パフォーマンスを向上させることができます。 再インデックスは、インデックスを統合するためにも使用できます。同じデータ構造を共有し、頻繁に一緒にクエリされる複数の小さなインデックスがあるとします。再インデックスにより、それらを 1 つの大きなインデックスに統合できます。これにより、多数の小さなインデックスを管理するオーバーヘッドが削減され、検索速度が向上します。 最後に、再インデックスを使用してルーティングを改善できます。再インデックスとルーティング戦略を効果的に適用することで、クエリを特定のシャードにルーティングし、検索する必要があるシャードの数を最小限に抑えることができます。このターゲットを絞ったアプローチにより、データがユーザー ID などの特定のキーで頻繁に検索される場合、検索クエリを大幅に高速化できます。 クラスターのアップグレード Elasticsearch バージョン 6.X から 8.0 (現在のメジャー バージョン) 以降にアップグレードする場合、バージョン 6 で作成されたインデックスを再インデックスする必要がある場合があります。Elasticsearch のデータ構造と基礎となるメカニズムはこれらのバージョン間で大幅に変更されたため、互換性と最適なパフォーマンスのために再インデックスが必要です。 再インデックス プロセスにより、データが更新された構造と新しい機能に一致するようになり、古いものから新しいものにシームレスに移行できるようになります。Elasticsearch では、このプロセスを支援するためにアップグレード アシスタントの使用を推奨しています。 再インデックス操作をトリガーする方法 Elasticsearch の再インデックスは、Elasticsearch Reindex API によって可能になります。Reindex API は、既存のインデックスと、作成または変更する新しいインデックスの間の橋渡しとして機能します。その主な目的は、あるインデックスから別のインデックスへのデータの効率的な転送を可能にすることですが、これに加えて、次のこともできます。 ソース インデックスからターゲット インデックスにドキュメントを選択的にコピーします。 フィールド名の変更や型変換などの複雑なデータ変換を適用します。 特定の基準に基づいてデータをフィルタリングします。 スロットルや更新間隔などのオプションを使用してインデックス作成プロセスを制御します。 Reindex API を使用する前に、データを移動または変換するターゲット インデックスが作成され、適切に構成されていることを確認してください。 再インデックスをトリガーするには、ソース インデックスとターゲット インデックス、および必要な変換やフィルターを指定して、 エンドポイントへの POST リクエストを作成する必要があります。再インデックス POST リクエストの例は次のようになります。 _reindex POST /_reindex { "source": { "index": "source_index" }, "dest": { "index": "target_index" }, "script": { "source": "ctx._source.new_field = 'transformed value'" }, "query": { "term": { "category.keyword": "example" } } } リクエストが構築されると、そのリクエストを Elasticsearch に送信して、再インデックス プロセスを開始できます。Elasticsearch は、定義した指示に従って、ソース インデックスからターゲット インデックスへのデータのコピーを開始します。 再インデックスが完了したら、ターゲット インデックスのデータを徹底的にテストして、期待どおりであることを確認します。たとえば、ソース インデックスとターゲット インデックスのフィールド マッピングを比較して、再インデックス中にフィールドが正しくマッピングされたことを確認できます。また、ソース インデックスとターゲット インデックスの両方からドキュメントのサンプルを取得して比較し、データが正確に再インデックスされたことを確認することもできます。 再インデックスのベストプラクティス Elasticsearch 内で再インデックスを行う場合は、再インデックス手順がスムーズに行われ、データが失われず、既存のクラスター操作への影響がほとんどないように、次のベスト プラクティスに従うようにしてください。 データのバックアップを優先する 再インデックス アクティビティを開始する前に、クラスターをバックアップすることが重要です。この予防措置はセーフティ ネットとして機能し、再インデックス プロセス中に予期しない問題が発生した場合に元の状態に戻す方法を提供します。 再インデックス後もソース インデックスは存在するはずですが、重要な変更を加える前に常にデータの信頼できるコピーを用意しておくことが基本原則です。 まず制御された環境で再インデックスを実行する 再インデックス作成中の潜在的なリスクと課題を軽減するために、まずは運用前環境で操作を実行することをお勧めします。そうすることで、運用システムに影響を与えることなく、予期しない問題を特定して対処することができます。運用前環境で手順が完了して検証されたら、運用環境で安全に実行できます。 リソース使用状況を監視する インフラストラクチャへの負担を防ぐために、再インデックス中にシステム リソースを監視することが重要です。特に大規模なデータセットの場合、再インデックスはリソースを大量に消費する可能性があります。CPU、メモリ、ディスク使用量、ネットワーク アクティビティを注意深く監視すると、リソースの割り当てを最適化し、パフォーマンスのボトルネックを起こさずにプロセスを効率的に実行できるようになります。リソースの使用状況を確認するには、ノード統計 API を使用できます。 GET /_nodes/stats 次のような応答が返されます。 { "_nodes": { "total": 2, "successful": 2, "failed": 0 }, "cluster_name": "my_cluster", "nodes": { "node_id1": { "name": "node_name1", "process": { "cpu": { "percent": 30, } }, "jvm": { "mem": { "heap_used_percent": 40.3, "heap_used_in_bytes": 123456789, "heap_max_in_bytes": 256000000 } } }, "node_id2": { "name": "node_name2", "process": { "cpu": { "percent": 50, } }, "jvm": { "mem": { "heap_used_percent": 60.8, "heap_used_in_bytes": 210987654, "heap_max_in_bytes": 256000000 } } } } } 再インデックス処理が集中しすぎる場合は、再インデックス要求を送信するときに、 パラメータを設定することで、プロセスを調整できます。これにより、パラメータで設定された秒数だけバッチ間のスリープが追加され、バッチ間のクールダウン期間が提供されます。 requests_per_second 結果の検証と検証 再インデックスが完了したら、ターゲット インデックスのデータが期待どおりであることを確認する必要があります。この検証プロセスには、ドキュメント数、フィールド マッピング、検索クエリなど、さまざまなテストが含まれます。 代替ソリューション Elasticsearch は、NoSQL 検索および分析分野で間違いなく主要なソリューションとしての地位を確立しています。ただし、データのインデックス作成とクエリに独自のアプローチを提供する代替ソリューション、特に Rockset のようなソリューションを検討する価値はあります。 Rockset は Elasticsearch の であり、データのインデックス作成とクエリに関して異なる視点を提供します。Elasticsearch の schema-on-write アプローチとは異なり、Rockset ではスキーマレスな取り込みが可能です。事前のスキーマ定義を必要とせずにデータの取り込みとクエリを実行できるため、再インデックス作成を必要とせずに、進化し続けるデータセットをより柔軟に処理できます。 クラウドネイティブな代替手段 インデックス管理の分野では、Rockset は、取り込まれたデータに対して行インデックス、列インデックス、検索インデックスがすべて自動的に作成される モデルのメリットを活用しています。これは、インデックスがユーザーによって作成され、構造の変更によって時間のかかる再インデックス手順が必要になることが多い Elasticsearch とは対照的です。 統合インデックス Elasticsearch はさまざまなユースケースに対応する堅牢なソリューションですが、特に Elasticsearch での再インデックスが頻繁に行われるようになった場合は、Rockset などの代替手段を検討すると役立つ場合があります。 結論 再インデックスは Elasticsearch の基本的なプロセスであり、データ構造が進化しても検索結果の効率と精度を維持するために重要です。 再インデックスがチームにとって常に時間の負担になっている場合は、Rockset などの代替ソリューションを検討する価値があるかもしれません。Rockset は、開発者がより付加価値の高い活動に集中できるようにする、より合理化されたインデックス管理プロセスを提供します。
