Content and Search
Mappings & queries
Lesson 4 of 5
What you'll learn
- Distinguish a text field from a keyword field
- Tell a match query apart from a term query
- Model a bool query with must and should clauses
A mapping is Elasticsearch's schema: it declares each field's type. The key distinction for search is text vs keyword. A text field is analyzed — tokenized for full-text search. A keyword field is stored verbatim as one token, for exact matches, filters, and aggregations.
{
"mappings": {
"properties": {
"title": { "type": "text" },
"status": { "type": "keyword" },
"views": { "type": "integer" }
}
}
}
This pairs with two query types. A match query analyzes its input and searches a text field's terms. A term query looks for an exact, un-analyzed value — what you use on a keyword field.
Combining clauses with bool
Real queries combine conditions with a bool query. Its clauses each play a role: must clauses are required (and contribute to score), should clauses are optional boosts, and filter clauses are required but yes/no only — they don't affect the score.
{
"query": {
"bool": {
"must": [ { "match": { "title": "search" } } ],
"should": [ { "match": { "title": "fast" } } ],
"filter": [ { "term": { "status": "published" } } ]
}
}
}
Filter is cacheable and cheap
Because filter clauses are pure yes/no with no scoring, Elasticsearch can cache their results. Put exact, non-ranking constraints (status, category, date ranges) in filter, and full-text relevance in must/should.
The challenge models that logic: a document passes if it satisfies all must and filter clauses, while should clauses only nudge a count.
Run it. Each doc must match all must + filter clauses to pass; should clauses are counted but not required.
Next: once documents match, how does Elasticsearch decide their order?
Sign in to save your progress across devices.