for TLQ changes that align with other PR #483 https://github.com/opensearch-project/documentation-website/pull/483
Signed-off-by: alicejw <alicejw@amazon.com>
This commit is contained in:
alicejw
parent
a0fe54bc91
commit
c4d71eb1eb
|
|
@ -7,7 +7,7 @@ nav_order: 40
|
|||
|
||||
# Full-text queries
|
||||
|
||||
This page lists all full-text query types and common options. Given the sheer number of options and subtle behaviors, the best method of ensuring useful search results is to test different queries against representative indices and verify the output.
|
||||
This page lists all full-text query types and common options. There are many options for full-text queries, each with its own subtle behavior difference, so the best method to ensure that you obtain useful search results is to test different queries against representative indexes and verify the outputs individually.
|
||||
|
||||
|
||||
---
|
||||
|
|
|
|||
|
|
@ -12,9 +12,31 @@ redirect_from:
|
|||
|
||||
# Query DSL
|
||||
|
||||
While you can use HTTP request parameters to perform simple searches, you can also use the OpenSearch query domain-specific language (DSL), which provides a wider range of search options. The query DSL uses the HTTP request body, so you can more easily customize your queries to get the exact results that you want.
|
||||
OpenSearch provides a query domain-specific language (DSL) that you can use to search with more options than a simple search via HTTP request parameter alone. The query DSL uses the HTTP request body, so you can more easily customize your queries to get the exact results that you want.
|
||||
|
||||
For example, the following request performs a simple search to search for a `speaker` field that has a value of `queen`.
|
||||
The OpenSearch query DSL provides three query options: term-level queries, full-text queries, and boolean queries. You can even perform more complicated searches by using different elements from each variety to find whatever data you need.
|
||||
|
||||
## DSL Query Types
|
||||
|
||||
OpenSearch supports two types of queries when you search for data: term-level queries and full-text queries.
|
||||
|
||||
The following table describes the differences between them:
|
||||
|
||||
| | Term-level queries | Full-text queries
|
||||
:--- | :--- | :---
|
||||
*Description* | Term-level queries answer which documents match a query. | Full-text queries answer how well the documents match a query.
|
||||
*Analyzer* | The search term isn't analyzed. This means that the term query searches for your search term as it is. | The search term is analyzed by the same analyzer that was used for the specific field of the document at the time it was indexed. This means that your search term goes through the same analysis process that the document's field did.
|
||||
*Relevance* | Term-level queries simply return documents that match without sorting them based on the relevance score. They still calculate the relevance score, but this score is the same for all the documents that are returned. | Full-text queries calculate a relevance score for each match and sort the results by decreasing order of relevance.
|
||||
*Use Case* | Use term-level queries when you want to match exact values such as numbers, dates, tags, and so on, and don't need the matches to be sorted by relevance. | Use full-text queries to match text fields and sort by relevance after taking into account factors like casing and stemming variants.
|
||||
|
||||
OpenSearch uses a probabilistic ranking framework called Okapi BM25 to calculate relevance scores. To learn more about Okapi BM25, see [Wikipedia](https://en.wikipedia.org/wiki/Okapi_BM25).
|
||||
{: .note }
|
||||
|
||||
To show the difference between a simple HTTP search versus a search via query DSL, we have an example of each one so that you can see how they differ.
|
||||
|
||||
## Example: HTTP simple search
|
||||
|
||||
The following request performs a simple search to search for a `speaker` field that has a value of `queen`.
|
||||
|
||||
**Sample request**
|
||||
```json
|
||||
|
|
@ -55,7 +77,9 @@ GET _search?q=speaker:queen
|
|||
}
|
||||
```
|
||||
|
||||
With query DSL, however, you can include an HTTP request body to look for results more tailored to your needs. The following example shows how to search for `speaker` and `text_entry` fields that have a value of `QUEEN`.
|
||||
## Example: Query DSL search
|
||||
|
||||
With a query DSL search, you can include an HTTP request body to look for results more tailored to your needs. The following example shows how to search for `speaker` and `text_entry` fields that have a value of `QUEEN`.
|
||||
|
||||
**Sample request**
|
||||
```json
|
||||
|
|
@ -119,4 +143,3 @@ With query DSL, however, you can include an HTTP request body to look for result
|
|||
}
|
||||
}
|
||||
```
|
||||
The OpenSearch query DSL comes in three varieties: term-level queries, full-text queries, and boolean queries. You can even perform more complicated searches by using different elements from each variety to find whatever data you need.
|
||||
|
|
|
|||
|
|
@ -2,25 +2,11 @@
|
|||
layout: default
|
||||
title: Term-level queries
|
||||
parent: Query DSL
|
||||
nav_order: 30
|
||||
nav_order: 32
|
||||
---
|
||||
|
||||
# Term-level queries
|
||||
|
||||
OpenSearch supports two types of queries when you search for data: term-level queries and full-text queries.
|
||||
|
||||
The following table describes the differences between them:
|
||||
|
||||
| | Term-level queries | Full-text queries
|
||||
:--- | :--- | :---
|
||||
*Description* | Term-level queries answer which documents match a query. | Full-text queries answer how well the documents match a query.
|
||||
*Analyzer* | The search term isn't analyzed. This means that the term query searches for your search term as it is. | The search term is analyzed by the same analyzer that was used for the specific field of the document at the time it was indexed. This means that your search term goes through the same analysis process that the document's field did.
|
||||
*Relevance* | Term-level queries simply return documents that match without sorting them based on the relevance score. They still calculate the relevance score, but this score is the same for all the documents that are returned. | Full-text queries calculate a relevance score for each match and sort the results by decreasing order of relevance.
|
||||
*Use Case* | Use term-level queries when you want to match exact values such as numbers, dates, tags, and so on, and don't need the matches to be sorted by relevance. | Use full-text queries to match text fields and sort by relevance after taking into account factors like casing and stemming variants.
|
||||
|
||||
OpenSearch uses a probabilistic ranking framework called Okapi BM25 to calculate relevance scores. To learn more about Okapi BM25, see [Wikipedia](https://en.wikipedia.org/wiki/Okapi_BM25).
|
||||
{: .note }
|
||||
|
||||
Assume that you have the complete works of Shakespeare indexed in an OpenSearch cluster. We use a term-level query to search for the phrase "To be, or not to be" in the `text_entry` field:
|
||||
|
||||
```json
|
||||
|
|
@ -228,7 +214,12 @@ The search query “HAMLET” is also searched literally. So, to get a match on
|
|||
|
||||
---
|
||||
|
||||
## Term
|
||||
## Term-level query operations
|
||||
|
||||
This section provides examples for term-level query operations that you can use for specific search use cases.
|
||||
|
||||
|
||||
## Single term
|
||||
|
||||
Use the `term` query to search for an exact term in a field.
|
||||
|
||||
|
|
@ -245,7 +236,7 @@ GET shakespeare/_search
|
|||
}
|
||||
```
|
||||
|
||||
## Terms
|
||||
## Multiple terms
|
||||
|
||||
Use the `terms` query to search for multiple terms in the same field.
|
||||
|
||||
|
|
@ -265,7 +256,7 @@ GET shakespeare/_search
|
|||
|
||||
You get back documents that match any of the terms.
|
||||
|
||||
## IDs
|
||||
## Document IDs
|
||||
|
||||
Use the `ids` query to search for one or more document ID values.
|
||||
|
||||
|
|
@ -283,7 +274,7 @@ GET shakespeare/_search
|
|||
}
|
||||
```
|
||||
|
||||
## Range
|
||||
## Range of values
|
||||
|
||||
Use the `range` query to search for a range of values in a field.
|
||||
|
||||
|
|
@ -364,7 +355,7 @@ GET products/_search
|
|||
|
||||
The keyword `now` refers to the current date and time.
|
||||
|
||||
## Prefix
|
||||
## Multiple terms by prefix
|
||||
|
||||
Use the `prefix` query to search for terms that begin with a specific prefix.
|
||||
|
||||
|
|
@ -379,7 +370,7 @@ GET shakespeare/_search
|
|||
}
|
||||
```
|
||||
|
||||
## Exists
|
||||
## All instances of a specific field in a document
|
||||
|
||||
Use the `exists` query to search for documents that contain a specific field.
|
||||
|
||||
|
|
@ -394,7 +385,7 @@ GET shakespeare/_search
|
|||
}
|
||||
```
|
||||
|
||||
## Wildcards
|
||||
## Wildcard patterns
|
||||
|
||||
Use wildcard queries to search for terms that match a wildcard pattern.
|
||||
|
||||
|
|
@ -422,7 +413,7 @@ If we change `*` to `?`, we get no matches, because `?` refers to a single chara
|
|||
|
||||
Wildcard queries tend to be slow because they need to iterate over a lot of terms. Avoid placing wildcard characters at the beginning of a query because it could be a very expensive operation in terms of both resources and time.
|
||||
|
||||
## Regex
|
||||
## Regular expressions (Regex)
|
||||
|
||||
Use the `regexp` query to search for terms that match a regular expression.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue