13

ES でより「正規化された」データに対してネストされたクエリを実行するための概念実証を実行しています。

たとえば、ネストされた

顧客 -> - 名前
- メール - イベント -> - 作成済み - タイプ

現在、特定の顧客のイベントのリストを別の顧客に移動できる状況があります。例: 顧客 A には 50 のイベントがあり、顧客 B には 5000 のイベントがあります。

すべてのイベントを顧客 A から顧客 B に移動したい

数百万の顧客を抱える大規模な環境で、UI のグラフに対してこれでクエリが実行されます。親/子の方が適切ですか、それともネストされた方が処理できるはずですか?

私の状況での長所と短所は何ですか?

4

1 に答える 1

25

「Nested で十分」などの大まかなパフォーマンス メトリクスを提供することさえ困難ですが、Nested と Parent/Child について役立つ情報をいくつか提供できます。パフォーマンスが許容範囲内であることを確認するために、いくつかのベンチマーク テストを実行することをお勧めします。

ネストされた

  • ネストされたドキュメントは互いに同じ Lucene ブロックに格納されるため、読み取り/クエリのパフォーマンスが向上します。ネストされたドキュメントの読み取りは、同等の親/子よりも高速です。
  • ネストされたドキュメント (親またはネストされた子) 内の単一のフィールドを更新すると、ES はネストされたドキュメント全体を強制的に再インデックス化します。これは、ネストされた大きなドキュメントの場合、非常にコストがかかる可能性があります
  • 「親」を変更すると、ES は、古いドキュメントを削除し、ネストされたデータが少ない古いドキュメントのインデックスを再作成し、新しいドキュメントを削除し、新しいネストされたデータで新しいドキュメントのインデックスを再作成することを意味します。

親子

  • 子は親とは別に保存されますが、同じシャードにルーティングされます。したがって、親/子は、ネストされたものよりも読み取り/クエリのパフォーマンスがわずかに低下します
  • ES はメモリ内に「結合」リストを維持するため、親/子マッピングにはメモリ オーバーヘッドが少し余分にかかります。
  • 子ドキュメントを更新しても、親や他の子には影響しません。これにより、大きなドキュメントのインデックス作成を大幅に節約できる可能性があります。
  • 親を変更すると、古い子ドキュメントが削除され、新しい親の下で同一のドキュメントがインデックス化されます。

Nested が問題なく動作する可能性はありますが、多くの「データ シャッフル」が発生する可能性があると思われる場合は、Parent/Child の方が適している可能性があります。Nested は、ネストされたデータが頻繁に更新されないが、頻繁に読み取られるインスタンスに最適です。親/子は、データがより頻繁に移動する配置に適しています。

于 2013-02-18T17:25:09.477 に答える