ElasticSearch 1 対多リレーションシップ ソリューション

I.はじめに

MySQL をストレージとして使用すると、注文と注文商品の詳細、顧客と顧客の住所など、テーブル間に多くの 1 対多の関係が存在します。ただし、ES 自体はフラットなドキュメント構造であるため、通常、異なるテーブル間には関係がありません。インデックス. リレーショナル, ES は MySQL に比べてこの関係の処理が苦手ですが、この関係をサポートするいくつかの方法も提供します. 顧客と顧客のアドレス (1 人の顧客が複数のアドレスを持つ) を例に挙げてみましょう. さまざまな利点と欠点ストレージの種類については、たまたま今週 1 回の繰り返しで顧客データを ES に移行することになりました。


客户基本信息:first、last、code、email
客户地址信息:city、address

2. 配列

ES には実際には専用の配列型はありません。デフォルトでは、どのフィールドにも 0 個以上の値を含めることができますが、配列内のすべての値は同じデータ型でなければなりません。

1. 基本型配列

注: addr は複数のアドレスに格納することを目的としています。ここではテキストとして定義できます。定義時に配列型として設定するためのキーワードはありません。

注: 型が一貫しているか、強制的に変換できる限り、0 個以上の値を保存できます。

注: この DOC ドキュメントは、あいまいクエリを通じて見つけることができます。

2. オブジェクト配列

注: これは実際には ES の基本的なオブジェクト タイプです。

注: addr には埋め込みオブジェクトを含めることができます。

注: オブジェクト配列のクエリ結果には境界の問題があります。city="Brisbane" と

address="Ngungug" でレコードがチェックアウトされます。アドレスが厳密に必要でないシナリオでは問題ありませんが、注文に埋め込まれた商品リストの場合、商品コードと価格がいつ指定されたかを知りたいです実際には、配列全体で一致するのではなく、配列内の 1 つのオブジェクトと厳密に一致する必要があります。これは主に、ES が JSON オブジェクト データのストレージを圧縮するためです。

上記データの実際の内部保存は以下の通りであり、都市と住所のマッピング関係は失われます。

3. ネスティング

ネストされた型は、オブジェクト内にオブジェクトをネストしたり、フィールドにキーと値のペアを格納したりできる、オブジェクト データ型の特別なバージョンです。

1. 入れ子構造を定義する

注: ネストされた構造は、ネストされたタイプを使用して定義されます。

2. 文書データを挿入する

注: 複数のアドレス情報を入れ子構造に配置できます。また、ES の put 命令と post 命令には違いがあります。Put では、指定されたドキュメントに対して動作するためにドキュメント ID を指定する必要があります。POST では、ドキュメント ID を指定する必要はありません。ドキュメント ID コレクションに作用します この概念 HTTP プロトコルから派生した HTTP プロトコルは、PUT 操作が冪等であるのに対し、POST 操作は非冪等であると定義します。

3. ネストされたコンテンツに基づいてドキュメントをクエリする

クエリを次のように変更するとデータが見つからなくなりますが、これが入れ子構造とオブジェクト配列の違いです。

コマンドを使用したオブジェクト データとネストされたストレージの違い

get _cat/indices?v ES 内の実際のドキュメント数を表示します。

ネスト構造を使用すると、ネストされたサブドキュメントは実際には ES 内で独立したサブドキュメントであることがわかります。ただし、クエリを実行すると、ES が内部で結合処理を実行するため、相対的に言えば、クエリ実行時のネストのパフォーマンスは向上しません。通常の内部オブジェクトと同様に良好です。

4. 父と子の文書

1. 親子構造を定義する

注: 親子関係構造を表すには join を使用します。関係内の custmoer は親ドキュメント、customerAddr は子ドキュメントです。

2. 親文書データを挿入する

注: ここでの join_field.name は、ドキュメントが親ドキュメントであることを指定します。

3. サブドキュメントデータの挿入

注: ここで、 join_field.name はドキュメントがサブドキュメントであることを指定し、parent はその親ドキュメント タイプを指定します。親ドキュメントと子ドキュメントが同じシャード上にあることを保証するために、リクエストにルーティングが設定されます。

4. クエリ

customer_parent/_search を取得する{}

注: 親と子の 2 つのドキュメントを返します。

customer_parent/_doc/customer1 を取得する

注: 親ドキュメントのデータのみが返されます。

has_child クエリを使用する: 子ドキュメントの条件に基づいて親ドキュメントのコンテンツをクエリします。

注: 親ドキュメントのコンテンツのみが返されます。

has_parent クエリを使用する: 親ドキュメントの条件に基づいてサブドキュメントのコンテンツをクエリします。

注: サブドキュメントのコンテンツのみが返されます。

5. 数種類の ES 1 対多関係の比較

注: 顧客データはめったに更新されず、ほとんどの場合はクエリであるため、最終的にはネストされた構造が使用されます。

おすすめ

転載: blog.csdn.net/2301_76787421/article/details/133427789