Elasticsearchと親子関係でネストされたマッピングを使用する場合の賛否両論

Question

現在、私のESドキュメント構造には、 'Object'タイプのフィールドがあります。これは内部に最大3000のフィールドを持つことができるjsonオブジェクトです。問題は、文書サイズが大きすぎるためにESがメモリ不足になることがあることです。だから、私は自分の文書構造を変更しようとしています。

私が見ている2つの構造は、ネストされたマッピングと親子関係です。どちらの構造も私の検索要件を満たしています。対象となるポイント：

1. ネストされたクエリは子クエリよりもはるかに高速です。
2. ネストされたマッピングもネストされたフィールドを別々のドキュメントとして保存します。

   1. どのように入れ子になったんインデックス作業を：私は直面しています混乱の

   2点？ ESは文書全体を一度に取得し、一度に完全に分析しますか、またはネストされた文書の要求は個別です。最初のケースでは、ESが再びメモリ不足になる可能性があるためです。

3. 親子クエリが遅いと言うと、どのくらい遅くなるのですか？

入力を検索します。

Answer 1

ネストされたものは親子よりも高速で、管理が簡単です。実際には、親なしで子供のインデックスを作成することができますので、インデックス作成時に注意する必要があります。また、親の1つのエントリを削除する場合は、すべての子ノードを削除する必要がありますが、自動タスクではありません。 一方、エントリを変更/更新する場合は、親/子がより快適になります。ネストされた型では、ネストされたフィールドで1つのネストされた値のみを変更することはできません。ネストされたフィールド内のすべてのネストされた値を再インデックスする必要があります。親/子では、その親フィールドまたは子フィールドで1つの値だけを変更/更新することもできます。 ネストされたデータは、インデックス内のアトミックなリレーショナルデータと見なされますが、parent/childは2つのフィールド（親、子）からのリレーションを保持するデータ型とは異なります。 ここではキムチの投稿を読むことができます。親/子供の遅さについては、ディスカッションの最後の1つのコメントを読むことができますhttps://discuss.elastic.co/t/choosing-parent-child-vs-nested-document/6742