WARNING: The 2.x versions of Elasticsearch have passed their EOL dates. If you are running a 2.x version, we strongly advise you to upgrade.
This documentation is no longer maintained and may be removed. For the latest information, see the current Elasticsearch documentation.
wildcard and regexp Queriesedit
The wildcard
query is a low-level, term-based query similar in nature to the
prefix
query, but it allows you to specify a pattern instead of just a prefix.
It uses the standard shell wildcards: ?
matches any character, and *
matches zero or more characters.
This query would match the documents containing W1F 7HW
and W2F 8HW
:
Imagine now that you want to match all postcodes just in the W
area. A
prefix match would also include postcodes starting with WC
, and you would
have a similar problem with a wildcard match. We want to match only postcodes
that begin with a W
, followed by a number. The regexp
query allows you to
write these more complicated patterns:
The regular expression says that the term must begin with a |
The wildcard
and regexp
queries work in exactly the same way as the
prefix
query. They also have to scan the list of terms in the inverted
index to find all matching terms, and gather document IDs term by term. The
only difference between them and the prefix
query is that they support more-complex patterns.
This means that the same caveats apply. Running these queries on a field with
many unique terms can be resource intensive indeed. Avoid using a
pattern that starts with a wildcard (for example, *foo
or, as a regexp, .*foo
).
Whereas prefix matching can be made more efficient by preparing your data at index time, wildcard and regular expression matching can be done only at query time. These queries have their place but should be used sparingly.
The prefix
, wildcard
, and regexp
queries operate on terms. If you use
them to query an analyzed
field, they will examine each term in the
field, not the field as a whole.
For instance, let’s say that our title
field contains “Quick brown fox”
which produces the terms quick
, brown
, and fox
.
This query would match:
{ "regexp": { "title": "br.*" }}
But neither of these queries would match:
- Elasticsearch - The Definitive Guide:
- Foreword
- Preface
- Getting Started
- You Know, for Search…
- Installing and Running Elasticsearch
- Talking to Elasticsearch
- Document Oriented
- Finding Your Feet
- Indexing Employee Documents
- Retrieving a Document
- Search Lite
- Search with Query DSL
- More-Complicated Searches
- Full-Text Search
- Phrase Search
- Highlighting Our Searches
- Analytics
- Tutorial Conclusion
- Distributed Nature
- Next Steps
- Life Inside a Cluster
- Data In, Data Out
- What Is a Document?
- Document Metadata
- Indexing a Document
- Retrieving a Document
- Checking Whether a Document Exists
- Updating a Whole Document
- Creating a New Document
- Deleting a Document
- Dealing with Conflicts
- Optimistic Concurrency Control
- Partial Updates to Documents
- Retrieving Multiple Documents
- Cheaper in Bulk
- Distributed Document Store
- Searching—The Basic Tools
- Mapping and Analysis
- Full-Body Search
- Sorting and Relevance
- Distributed Search Execution
- Index Management
- Inside a Shard
- You Know, for Search…
- Search in Depth
- Structured Search
- Full-Text Search
- Multifield Search
- Proximity Matching
- Partial Matching
- Controlling Relevance
- Theory Behind Relevance Scoring
- Lucene’s Practical Scoring Function
- Query-Time Boosting
- Manipulating Relevance with Query Structure
- Not Quite Not
- Ignoring TF/IDF
- function_score Query
- Boosting by Popularity
- Boosting Filtered Subsets
- Random Scoring
- The Closer, The Better
- Understanding the price Clause
- Scoring with Scripts
- Pluggable Similarity Algorithms
- Changing Similarities
- Relevance Tuning Is the Last 10%
- Dealing with Human Language
- Aggregations
- Geolocation
- Modeling Your Data
- Administration, Monitoring, and Deployment