Elasticsearch で SQL 結合に相当することを行う最良の方法は何ですか?
Persons と Items という 2 つの大きなテーブルを持つ SQL セットアップがあります。個人は多くのアイテムを所有できます。Person 行と Item 行はどちらも変更できます (つまり、更新できます)。人物とアイテムの両方の側面でフィルタリングする検索を実行する必要があります。
Elasticsearch では、 Person を Item のネストされたドキュメントにしてから、 を使用できるようhas_childです。
しかし: 次に Person を更新する場合、所有するすべての Item を更新する必要があると思います (これはかなりの量になる可能性があります)。
あれは正しいですか？Elasticsearch でこのクエリを解決する良い方法はありますか?
すでに述べたように、行く方法は親/子です。ポイントは、ネストされたドキュメントは非常にパフォーマンスが高いということですが、それらを更新するには、構造全体 (親 + ネストされたドキュメント) を再送信する必要があります。ネストされたドキュメントの内部実装は個別の lucene ドキュメントで構成されていますが、これらのネストされたドキュメントは表示されず、直接アクセスすることもできません。実際、ネストされたドキュメントを使用する場合は、適切なクエリを使用してそれらにアクセスする必要があります (ネストされたクエリ、ネストされたフィルター、ネストされたファセットなど)。
一方、親/子を使用すると、相互に参照する個別のドキュメントを作成でき、個別に更新できます。パフォーマンスと使用されるメモリの点でコストがかかりますが、ネストされたドキュメントよりもはるかに柔軟です。
ただし、この記事で述べたように、elasticsearch がリレーションの管理に役立つという事実は、それらの機能を使用する必要があるという意味ではありません。多くの複雑なユースケースでは、リレーションを処理するアプリケーション レイヤーにカスタム ロジックを配置することをお勧めします。ファセットには、親/子にも制限があります。たとえば、一致する子のみを取得できないネストされたドキュメントとは対照的に、たとえば、親と子の両方を同時に取得することはできません (今のところ)。
私の回答を見てみましょう: Elasticsearch では、複数の最上位ドキュメントが 1 つのネストされたドキュメントを共有できますか?
これは_parent、Person が更新されたときにすべての Item を更新する必要があるという問題を回避する方法としてのマッピングの使用について説明しています。