web-dev-qa-db-ja.com

Elasticsearch関係マッピング（1対1および1対多）

私のエラスティック検索サーバーには、1つのインデックスhttp://localhost:9200/blog。
（ブログ）インデックスには複数のタイプが含まれています。

例：http://localhost:9200/blog/posts、http://localhost:9200/blog/tags。

タグタイプで1000以上のタグを作成し、10の投稿を投稿タイプで作成しました。

例：投稿

{   
    "_index":"blog",
    "_type":"posts",
    "_id":"1",
    "_version":3,
    "found":true,
    "_source" : {
        "catalogId" : "1",
       "name" : "cricket",
       "url" : "http://www.wikipedia/cricket"
    }
}

例：タグ

{   
    "_index":"blog",
    "_type":"tags",
    "_id":"1",
    "_version":3,
    "found":true,
    "_source" : {
        "tagId" : "1",
        "name" : "game"
    }
}

既存のタグをブログ投稿に割り当てたい（つまり、関係=>マッピング）。

タグを投稿マッピングに割り当てるにはどうすればよいですか？

elasticsearchmappingrelationshipelastica
26
Aruljothi

Elasticsearch内で関係を管理するために使用できる4つのアプローチがあります。それらはElasticsearchブログの投稿で非常によく概説されています- Elasticsearch内の関係の管理 記事全体を読んで各アプローチの詳細を取得してから、技術的に残りながらビジネスニーズに最適なアプローチを選択することをお勧めします適切な。

4つのアプローチの要点を以下に示します。

内部オブジェクト

  • 簡単、高速、高性能
  • 1対1の関係が維持されている場合にのみ適用されます
  • 特別なクエリは不要

入れ子

  • ネストされたドキュメントは互いに同じLuceneブロックに保存されるため、読み取り/クエリのパフォーマンスが向上します。ネストされたドキュメントの読み取りは、同等の親/子よりも高速です。
  • ネストされたドキュメント（親またはネストされた子）の単一のフィールドを更新すると、ESはネストされたドキュメント全体のインデックスを再作成します。これは、ネストされた大きなドキュメントの場合、非常に高価になる可能性があります
  • ネストされたドキュメントの「相互参照」は不可能
  • 頻繁に変更されないデータに最適

親/子

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

非正規化

  • すべての関係を自分で管理できます！
  • 最も柔軟で、最も管理上のオーバーヘッド
  • 設定に応じて、多少のパフォーマンスが出る場合があります
52
Paige Cook