ネストされたvs親/チャイルドドキュメントに関するスケーリング

Question

私はESのより多くの "正規化された"データに対してネストされたクエリを実行するための概念証明を実行しています。

> - - メール - - イベント - > - を作成 - タイプ

今、私は特定の顧客のためのイベントのリストを別のものに移動することができる状況がある
に名前を入れ子になった

カスタマーと顧客。例えば顧客Aが50件のイベント 顧客Bが5000件のイベント

私は今、顧客とクエリの何百万人と規模で、顧客B

に顧客Aからすべてのイベントを移動したいがUIでのグラフのために、この上で実行されていたです親子がより適しているか、それともネストされていなければ処理できないのでしょうか？

私の状況の賛否両論は何ですか？

Answer 1

"Nested is good"のような大まかなパフォーマンスメトリクスを与えるのは難しいですが、Nested vs Parent/Childについてのいくつかの詳細を教えていただけます。私はまだパフォーマンスが許容可能であることを確認するために、いくつかのベンチマークテストの作業をお勧めします。

ネスト

• ネストされたドキュメントを読み出し/クエリのパフォーマンスを助ける互いに同じLuceneのブロックに格納されます。ネストされたドキュメントの読み込みは、同等の親/子の読み込みよりも高速です。
• ネストされたドキュメント（親またはネストされた子）の1つのフィールドを更新すると、全体のネストされたドキュメントが強制的に再インデックスされます。これは大規模なネストされたドキュメントでは非常に高価になる可能性があります。
• "親"を変更すると、古いドキュメントを削除し、古いドキュメントを再ネストした古いドキュメントを再作成し、新しいドキュメントを削除します。

親/子

• 子供たちは親とは別に保存されているが、同じシャードにルーティングされます。したがって、親子は読み込み/クエリのパフォーマンスがネストされたものよりわずかに低い
• ESが "結合"リストをメモリに保持するので、親子マッピングに少しのメモリオーバーヘッドがある
• 子ドキュメントの更新は親に影響しません大規模なドキュメントに多数のインデックスを保存する可能性があります。
• 親を変更すると、古い子ドキュメントが削除され、新しい親の下にある同じドキュメントにインデックスが作成されます。

可能性があります。ネストされたものはうまく機能しますが、「データシャッフル」の可能性が高いと思われる場合は、親子が適している可能性があります。入れ子になったデータは頻繁に更新されずに頻繁に読み込まれるインスタンスに最適です。親子は、データがより頻繁に移動する取り決めに適しています。