Discoveryクエリー言語クエリーの書き方

Discoveryクエリー言語は、インデックスされたドキュメントの構造を活用します。 次のJSONスニペットは、Entitiesエンリッチメントが適用されたコレクションからインデックス化されたドキュメントを示しています。 エンリッチメントの結果、JSON構造は、都市名、企業、有名人などの既知のエンティティのあらゆる言及をキャプチャする。

この例では、認識される実体は会社名 IBM です。

{
  "document": {
    "document_id": "f7f27ea30eb3e4c0ce21830618d9ee99",
    "enriched_text": [
      {
        "entities": [
          {
            "model_name": "natural_language_understanding",
            "mentions": [],
            "text":"IBM",
            "type":"Organization"
          }
        ]
      }
    ]
  }
}

エンティティ IBM が言及されているすべての文書を返すクエリを作成するには、次の構文を使います：

この基本的なクエリは、: 演算子の前に入れ子になったパス式を含んでいます。 各path要素は、ピリオド（.）で区切られたドキュメント内のフィールド名です。: 演算子は、演算子に続くテキストが結果に含まれなければならないことを示します。

:: 演算子は、テキストが結果の中で正確に一致しなければならないことを示します。 詳細は クエリー演算子 を参照してください。 この2つの演算子がどのように使われるかは、以下の例で見ることができる。

• マッチしたドキュメントを関連性の高い順に返すには、POST リクエストで以下のデータオブジェクトを渡します：

  {
    "query":"enriched_text.entities.text:IBM"
  }
  

• 一致するドキュメントを任意の順番で返すには、POST リクエストで以下のデータオブジェクトをクエリボディとして渡します：

  {
    "filter":"enriched_text.entities.text::IBM"
  }
  

フィルターとクエリーパラメーターを併用する

filter パラメータは、query パラメータよりも速く返され、その結果はキャッシュされます。 filter と query パラメータを使用したクエリを、小さなデータセットに対して別々に送信した場合、それぞれのリクエストは（同一ではないにしても）似たような結果を返します。

大きなデータセットでは、関連性の高い順に結果を返す必要がある場合、filter と query パラメータを組み合わせます。 filter パラメータが最初に適用されるため、パラメータを一緒に使うとパフォーマンスが向上します。 ドキュメントをフィルタリングし、結果をキャッシュする。 query パラメータは、キャッシュされた結果をランク付けします。

{
  "filter": "document_id::b6d8c6e3-1097-421b-9e39-75717d2554aa"
}

{
  "filter": "extracted_metadata.filename::100674.txt",
  "return": [ "document_id", "extracted_metadata" ]
}

{
  "matching_results": 1,
  "results": [
    {
      "document_id": "b6d8c6e3-1097-421b-9e39-75717d2554aa",
      "extracted_metadata": {
        "sha1": "AD447F7592A17CDCBF0A589C4E6EC2087AF7H35F",
        "filename": "100674.txt",
        "file_type": "text"
      }
    }
  ]
}

{
  "filter": "enriched_text.entities.text::Gilroy"
}

{
  "matching_results": 4
}

ネストした値のフィルタリング

1つのフィルタを別のフィルタの中に入れ子にすることで、返されるドキュメントが複数の条件に一致するようにすることができます。

これらの例に使われた文書では、"Gilroy" という実体は "Location"（カリフォルニア州の町）としても "Person"（苗字）としても現れます。 "Gilroy" が場所として現れる文書を見つけるには、入れ子になった2つのフィールドを同時にフィルタリングするクエリを書きます：エンティティテキストは "Gilroy" でなければならず、エンティティタイプは "Location" でなければなりません。

クエリを記述する方法の1つは次のとおりです

{
  "filter": "enriched_text.entities.text::Gilroy,enriched_text.entities.type::Location"
}

このクエリは、あるパス enriched_text.entities.text が Gilroy であり、あるパス enriched_text.entities.type::Location が Location である文書にマッチします。 しかし、これら2つのパスが同じ entities オブジェクトの下にあるという保証はない。 例えば、クエリは Gilroy を Person エンティティタイプとして持ち、同時に他の Location エンティティタイプオブジェクトを持つ文書にマッチします。

このクエリーのネストされたセマンティクスを正確に捉えるには、以下の構文を使ってフィルター値をネストする：

照会本体:

{
  "filter": "enriched_text.entities:(text::Gilroy,type::Location)"
}

このより厳密なクエリは、entities オブジェクトが存在し、text が Gilroy と等しく、type が Location と等しい文書にのみマッチします。

別の例として、entities オブジェクトを含み、text と Gilroy が等しく、type ないと Location が等しい文書にマッチさせたい場合は、クエリー内で ノットイコール 演算子を使うことができます：

{
  "filter": "enriched_text.entities:(text::Gilroy,type::!Location)"
}

また、集計を使って、より高度なフィルタリングを行うこともできる。 使用可能な集約タイプの詳細については、クエリ集約 を参照してください。

Discovery クエリ言語の詳細については、以下のトピックを参照してください

• 照会パラメーター
• 照会演算子 (query operators)