2017-12-07 8 views
0

これは弾性サーチの可能性であるかどうかを調査しようとしています。そのデータを最適に切り離したいので、私は内部にindexと異なるようにしますtypesフィールドごとに異なるタイプのESクエリーと共通フィールドへの参加

Question1:この決定がどのように悪いのですか?

/myindex/name 

{ 
    "name" : "mat", 
    "id":1 
} 

surname

/myindex/surname  
{ 
    "surname" : "txt", 
    "id":1 
} 

質問2:私はタイプnameをした場合

さて、どのように私はname='mat AND surname='txt'あるとidを返す検索を作成することができますか?私はこの(インデックスで、タイプを指定せずに)としてクエリを実行する場合

:それは(obviusly)二つの文書を返します

/myindex/_search 
{ 

    "query" : { 
     "bool" : { 
     "should" : [{ 
      "term" : { "name" : "mat" } 
     }, 
     { 
      "term" : { "surname" : "txt" } 
     }] 
     } 
    } 
} 

、私はjoin by idような何かを言うことができますか?

答えて

0

あなたがElasticSearch(または任意の他のNoSQLデータベース)を使用するつもりなら、あなたが本当に周りにあなたの考え方を変更する必要があり、「参加します」。私たちはnoSQLで結合をしません...まったく...これまで。代わりに、それぞれのレコードに重複データを入れる必要があります。

次の例を考えてみましょう:商品があり、各商品に商品タイプがあるとします。

SQLでは、2つのレコードは次のようになります。製品タイプ情報が両方に重複しているか

products/product/1 
{ 
    "name": "product name 1", 
    "type: { 
     "type name": "product type 99" 
    } 
} 

products/product/2 
{ 
    "name": "product name 2", 
    "type: { 
     "type name": "product type 99" 
    } 
} 

お知らせ:

| Product ID | Product Name | Product Type ID | 
| ---------- | ------------ | --------------- | 
| 1 | product name 1 | 99 | 
| 2 | product name 2 | 99 | 

elasticsearchで、我々はこのようなデータを格納します行。原則として、noSQLは、データの重複を犠牲にして、はるかに高速であるという利点があります。これは、「製品タイプ99」という名前をNレコードで変更する必要があるため、名前を変更することは非常に難しいことを意味します。

うまくいけば助けてください。

+0

私はこれを知っていますが、セキュリティ上の理由から情報を切り離して検索しながら情報に結合したいと考えています。おそらく、私が達成しようとしていることは、ESの実装によってまだ検討されていません(私は目標との境界線です) – EsseTi