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.
String Sorting and Multifieldsedit
Analyzed string fields are also multivalue fields, but sorting on them seldom
gives you the results you want. If you analyze a string like fine old art
,
it results in three terms. We probably want to sort alphabetically on the
first term, then the second term, and so forth, but Elasticsearch doesn’t have this
information at its disposal at sort time.
You could use the min
and max
sort modes (it uses min
by default), but
that will result in sorting on either art
or old
, neither of which was the
intent.
In order to sort on a string field, that field should contain one term only:
the whole not_analyzed
string. But of course we still need the field to be
analyzed
in order to be able to query it as full text.
The naive approach to indexing the same string in two ways would be to include
two separate fields in the document: one that is analyzed
for searching,
and one that is not_analyzed
for sorting.
But storing the same string twice in the _source
field is waste of space.
What we really want to do is to pass in a single field but to index it in two different ways. All of the core field types (strings, numbers,
Booleans, dates) accept a fields
parameter that allows you to transform a
simple mapping like:
"tweet": { "type": "string", "analyzer": "english" }
into a multifield mapping like this:
"tweet": { "type": "string", "analyzer": "english", "fields": { "raw": { "type": "string", "index": "not_analyzed" } } }
The main |
|
The new |
Now, or at least as soon as we have reindexed our data, we can use the tweet
field for search and the tweet.raw
field for sorting:
GET /_search { "query": { "match": { "tweet": "elasticsearch" } }, "sort": "tweet.raw" }
Sorting on a full-text analyzed
field can use a lot of memory. See
Aggregations and Analysis for more information.
- 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