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.
Sorting and Collations
editSorting and Collations
editSo far in this chapter, we have looked at how to normalize tokens for the purposes of search. The final use case to consider in this chapter is that of string sorting.
In String Sorting and Multifields, we explained that Elasticsearch cannot sort on an
analyzed
string field, and demonstrated how to use multifields to index
the same field once as an analyzed
field for search, and once as a
not_analyzed
field for sorting.
The problem with sorting on an analyzed
field is not that it uses
an analyzer, but that the analyzer tokenizes the string value into
multiple tokens, like a bag of words, and Elasticsearch doesn’t know which
token to use for sorting.
Relying on a not_analyzed
field for sorting is inflexible: it allows
us to sort on only the exact value of the original string. However, we can use
analyzers to achieve other sort orders, as long as our chosen analyzer always emits only a single token for each string value.
Case-Insensitive Sorting
editImagine that we have three user
documents whose name
fields contain Boffey
,
BROWN
, and bailey
, respectively. First we will apply the technique
described in String Sorting and Multifields of using a not_analyzed
field for sorting:
PUT /my_index { "mappings": { "user": { "properties": { "name": { "type": "string", "fields": { "raw": { "type": "string", "index": "not_analyzed" } } } } } } }
We can index some documents and try sorting:
PUT /my_index/user/1 { "name": "Boffey" } PUT /my_index/user/2 { "name": "BROWN" } PUT /my_index/user/3 { "name": "bailey" } GET /my_index/user/_search?sort=name.raw
The preceding search request would return the documents in this order: BROWN
,
Boffey
, bailey
. This is known as lexicographical order as opposed to
alphabetical order. Essentially, the bytes used to represent capital
letters have a lower value than the bytes used to represent lowercase letters,
and so the names are sorted with the lowest bytes first.
That may make sense to a computer, but doesn’t make much sense to human beings who would reasonably expect these names to be sorted alphabetically, regardless of case. To achieve this, we need to index each name in a way that the byte ordering corresponds to the sort order that we want.
In other words, we need an analyzer that will emit a single lowercase token:
PUT /my_index { "settings": { "analysis": { "analyzer": { "case_insensitive_sort": { "tokenizer": "keyword", "filter": [ "lowercase" ] } } } } }
The |
|
The |
With the case_insensitive_sort
analyzer in place, we can now use it in our
multifield:
PUT /my_index/_mapping/user { "properties": { "name": { "type": "string", "fields": { "lower_case_sort": { "type": "string", "analyzer": "case_insensitive_sort" } } } } } PUT /my_index/user/1 { "name": "Boffey" } PUT /my_index/user/2 { "name": "BROWN" } PUT /my_index/user/3 { "name": "bailey" } GET /my_index/user/_search?sort=name.lower_case_sort
The preceding search request returns our documents in the order that we expect:
bailey
, Boffey
, BROWN
.
But is this order correct? It appears to be correct as it matches our expectations, but our expectations have probably been influenced by the fact that this book is in English and all of the letters used in our example belong to the English alphabet.
What if we were to add the German name Böhm?
Now our names would be returned in this order: bailey
, Boffey
, BROWN
,
Böhm
. The reason that Böhm
comes after BROWN
is that these words are
still being sorted by the values of the bytes used to represent them, and an
r
is stored as the byte 0x72
, while ö
is stored as 0xF6
and so is
sorted last. The byte value of each character is an accident of history.
Clearly, the default sort order is meaningless for anything other than plain English. In fact, there is no “right” sort order. It all depends on the language you speak.
Differences Between Languages
editEvery language has its own sort order, and sometimes even multiple sort orders. Here are a few examples of how our four names from the previous section would be sorted in different contexts:
-
English:
bailey
,boffey
,böhm
,brown
-
German:
bailey
,boffey
,böhm
,brown
-
German phonebook:
bailey
,böhm
,boffey
,brown
-
Swedish:
bailey
,boffey
,brown
,böhm
The reason that the German phonebook sort order places böhm
before boffey
is that ö
and oe
are considered synonyms when dealing with names and
places, so böhm
is sorted as if it had been written as boehm
.
Unicode Collation Algorithm
editCollation is the process of sorting text into a predefined order. The Unicode Collation Algorithm, or UCA (see www.unicode.org/reports/tr10) defines a method of sorting strings into the order defined in a Collation Element Table (usually referred to just as a collation).
The UCA also defines the Default Unicode Collation Element Table, or DUCET, which defines the default sort order for all Unicode characters, regardless of language. As you have already seen, there is no single correct sort order, so DUCET is designed to annoy as few people as possible as seldom as possible, but it is far from being a panacea for all sorting woes.
Instead, language-specific collations exist for pretty much every language under the sun. Most use DUCET as their starting point and add a few custom rules to deal with the peculiarities of each language.
The UCA takes a string and a collation as inputs and outputs a binary sort key. Sorting a collection of strings according to the specified collation then becomes a simple comparison of their binary sort keys.
Unicode Sorting
editThe approach described in this section will probably change in a future version of
Elasticsearch. Check the icu
plugin documentation for the
latest information.
The icu_collation
token filter defaults to using the DUCET
collation for sorting. This is already an improvement over the default sort. To use it,
all we need to do is to create an analyzer that uses the default
icu_collation
filter:
PUT /my_index { "settings": { "analysis": { "analyzer": { "ducet_sort": { "tokenizer": "keyword", "filter": [ "icu_collation" ] } } } } }
Typically, the field that we want to sort on is also a field that we want to search on, so we use the same multifield approach as we used in Case-Insensitive Sorting:
PUT /my_index/_mapping/user { "properties": { "name": { "type": "string", "fields": { "sort": { "type": "string", "analyzer": "ducet_sort" } } } } }
With this mapping, the name.sort
field will contain a sort key that will be
used only for sorting. We haven’t specified a language, so it defaults to
using the DUCET collation.
Now, we can reindex our example docs and test the sorting:
PUT /my_index/user/_bulk { "index": { "_id": 1 }} { "name": "Boffey" } { "index": { "_id": 2 }} { "name": "BROWN" } { "index": { "_id": 3 }} { "name": "bailey" } { "index": { "_id": 4 }} { "name": "Böhm" } GET /my_index/user/_search?sort=name.sort
Note that the sort
key returned with each document, which in earlier
examples looked like brown
and böhm
, now looks like gobbledygook:
ᖔ乏昫တ倈⠀\u0001
. The reason is that the icu_collation
filter emits keys
intended only for efficient sorting, not for any other purposes.
The preceding search returns our docs in this order: bailey
, Boffey
, Böhm
,
BROWN
. This is already an improvement, as the sort order is now correct for
English and German, but it is still incorrect for German phonebooks and
Swedish. The next step is to customize our mapping for different languages.
Specifying a Language
editThe icu_collation
filter can be configured to use the collation table for a
specific language, a country-specific version of a language, or some other
subset such as German phonebooks. This can be done by creating a custom version
of the token filter by using the language
, country
, and variant
parameters
as follows:
- English
-
{ "language": "en" }
- German
-
{ "language": "de" }
- Austrian German
-
{ "language": "de", "country": "AT" }
- German phonebooks
-
{ "language": "de", "variant": "@collation=phonebook" }
You can read more about the locales supported by ICU at: http://userguide.icu-project.org/locale.
This example shows how to set up the German phonebook sort order:
PUT /my_index { "settings": { "number_of_shards": 1, "analysis": { "filter": { "german_phonebook": { "type": "icu_collation", "language": "de", "country": "DE", "variant": "@collation=phonebook" } }, "analyzer": { "german_phonebook": { "tokenizer": "keyword", "filter": [ "german_phonebook" ] } } } }, "mappings": { "user": { "properties": { "name": { "type": "string", "fields": { "sort": { "type": "string", "analyzer": "german_phonebook" } } } } } } }
First we create a version of the |
|
Then we wrap that up in a custom analyzer. |
|
And we apply it to our |
Reindex the data and repeat the same search as we used previously:
PUT /my_index/user/_bulk { "index": { "_id": 1 }} { "name": "Boffey" } { "index": { "_id": 2 }} { "name": "BROWN" } { "index": { "_id": 3 }} { "name": "bailey" } { "index": { "_id": 4 }} { "name": "Böhm" } GET /my_index/user/_search?sort=name.sort
This now returns our docs in this order: bailey
, Böhm
, Boffey
, BROWN
.
In the German phonebook collation, Böhm
is the equivalent of Boehm
, which
comes before Boffey
.
Multiple sort orders
editThe same field can support multiple sort orders by using a multifield for each language:
PUT /my_index/_mapping/_user { "properties": { "name": { "type": "string", "fields": { "default": { "type": "string", "analyzer": "ducet" }, "french": { "type": "string", "analyzer": "french" }, "german": { "type": "string", "analyzer": "german_phonebook" }, "swedish": { "type": "string", "analyzer": "swedish" } } } } }
With this mapping in place, results can be ordered correctly for French,
German, and Swedish users, just by sorting on the name.french
, name.german
,
or name.swedish
fields. Unsupported languages can fall back to using the
name.default
field, which uses the DUCET sort order.
Customizing Collations
editThe icu_collation
token filter takes many more options than just language
,
country
, and variant
, which can be used to tailor the sorting algorithm.
Options are available that will do the following:
- Ignore diacritics
- Order uppercase first or last, or ignore case
- Take punctuation and whitespace into account or ignore it
- Sort numbers as strings or by their numeric value
- Customize existing collations or define your own custom collations
Details of these options are beyond the scope of this book, but more information can be found in the ICU plug-in documentation and in the ICU project collation documentation.