ElasticSearchで階層を非正規化する方法は？

Question

私はElasticSearchを初めて利用しています。実際のファイルシステムのパスではなく、記事、画像、ドキュメントを1つに分類する単純なテキストフィールドではなく、特定のドキュメントへのパスを示すツリーがあります。各パスエントリのタイプは、Group Name、Assembly name、さらにはUnknownです。この型は、たとえばパス内の特定のエントリをスキップするクエリで使用できます。私のソースデータがSQL Serverに格納されている

は、スキーマは次のようになります。

ツリーTree.IdTree.ParentIdに接続することにより構築が、各ノードが型を持っている必要があります。ドキュメントは、ツリー内のリーフに接続されています。

私は、しかし、私は非正規化と弾性でそれらを検索するための最適な方法を見つける必要があり、SQL Serverの構造を照会心配ないです。私はパスを平らにし、文書の「記述子」のリストを作成した場合、私は弾性文書として文書の各エントリを保存することができます。：

{ 
    "path": "NodeNameRoot/NodeNameLevel_1/NodeNameLevel_2/NodeNameLevel_3/NodeNameLevel_4", 
    "descriptors": [ 
    { 
     "name": "NodeNameRoot", 
     "type": "type1" 
    }, 
    { 
     "name": "NodeNameLevel_1", 
     "type": "type1" 
    }, 
    { 
     "name": "NodeNameLevel_2", 
     "type": "type2" 
    }, 
    { 
     "name": "NodeNameLevel_3", 
     "type": "type2" 
    }, 
    { 
     "name": "NodeNameLevel_4", 
     "type": "type3" 
    } 
    ], 
    "document": { 
    ... 
    } 
} 

を私はElasticSearchで、このような構造を照会することはできますか？または、パスを別の方法で非正規化する必要がありますか？

私の主な質問：

は、種類やテキスト値（たとえば、正規表現のマッチング）に基づいて、それらを照会することができます。たとえば、次のように入力します。パスにXが含まれている場合、すべてのtype2-> type3パスを与えます（実際にはtype1はそのままにします）。

レベルに基づいて照会することは可能ですか？私は4つの記述子があるパスを好きです。

私は組み込み機能で検索行うことができますか私は、拡張機能を記述する必要がありますか？

編集 Gキンタナさんanwserに基づいて、私はこのようなインデックス。：

curl -X PUT \ 
    http://localhost:9200/test \ 
    -H 'cache-control: no-cache' \ 
    -H 'content-type: application/json' \ 
    -d '{ 
    "mappings": { 
    "path": { 
     "properties": { 
     "names": { 
      "type": "text", 
      "fields": { 
      "raw": { 
       "type": "keyword" 
      }, 
      "tokens": { 
       "type": "text", 
       "analyzer": "pathname_analyzer" 
      }, 
      "depth": { 
       "type": "token_count", 
       "analyzer": "pathname_analyzer" 
      } 
      } 
     }, 
     "types": { 
      "type": "text", 
      "fields": { 
      "raw": { 
       "type": "keyword" 
      }, 
      "tokens": { 
       "type": "text", 
       "analyzer": "pathname_analyzer" 
      } 
      } 
     } 
     } 
    } 
    }, 
    "settings": { 
    "analysis": { 
     "analyzer": { 
     "pathname_analyzer": { 
      "type": "pattern", 
      "pattern": "#->>", 
      "lowercase": true 
     } 
     } 
    } 
    } 
}' 

を行い、このように奥行きを問い合わせることができ：

正しい戻る

curl -X POST \ 
    http://localhost:9200/test/path/_search \ 
    -H 'content-type: application/json' \ 
    -d '{ 
    "query": { 
     "bool": { 
      "should": [ 
       {"match": { "names.depth": 5 }} 
      ] 
     } 
    } 
}' 

結果。私はもう少しそれをテストします。

Answer 1

まず、データのインデックス作成方法を設計するために、すべてのクエリパターンを特定する必要があります。あなたが与えた例から

、Iだろう形式のインデックス文書：

• フィールドpath：
  • 使用

    { 
        "path": "NodeNameRoot/NodeNameLevel_1/NodeNameLevel_2/NodeNameLevel_3/NodeNameLevel_4", 
        "types: "type1/type1/type2/type2/type3", 
        "document": { 
        ... 
        } 
    } 
    

    がインデックス化する前に、マッピングおよび解析を設定する必要がありますタイプtext + pattern analyzerに基づくアナライザは、/で分割する

  • 使用タイプtoken_count +パスアナライザと同じアナライザ。multi field（path.depth）
• フィールドtypes
  • 使用タイプtext + pathを分割する/文字

設定インデックスのマッピングおよび分析で分割するpattern analyzerに基づいて解析を作成します。フィールドには、aまたはaを使用します。

1. することは私にパスがX使用4つの記述子があるpathフィールド
2. にmatchクエリが含まれているすべてのtype2- typesフィールド
3. にmatch_phraseクエリを使用> TYPE3パスを与えますpath.depthサブフィールド上使用termクエリ

Y私たちの記述子フィールドは興味深いものではありません。 Path tokenizerはいくつかの用途では興味深いかもしれません。 multi-fieldsを使用して複数のアナライザを同じフィールドに適用し、サブフィールドがあるかどうかを問い合わせることができます。