Sorting and collations - Elasticsearch 权威指南中文版


Sorting and collations

发布于 2019-07-04 字数 14140 浏览 668 评论 0

=== Sorting and Collations

So far in this chapter, we have looked at how to normalize tokens for the
purposes of search.(((“tokens”, “normalizing”, “for sorting and collation”))) The final use case to consider in this chapter
is that of string sorting.(((“sorting”)))

In <>, 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.(((“not_analyzed fields”, “for string sorting”)))(((“analyzed fields”, “for searh”)))

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

Imagine that we have three user documents whose name fields contain Boffey,(((“case insensitive sorting”)))(((“sorting”, “case insensitive”)))
BROWN, and bailey, respectively. First we will apply the technique
described in <> of using a not_analyzed field for sorting:


PUT /my_index { “mappings”: { “user”: { “properties”: { “name”: { “type”: “string”, “fields”: { “raw”: { “type”: “string”, “index”: “not_analyzed” } } } } } } }

The `analyzed` `name` field is used for search.
The `not_analyzed` `name.raw` field is used for sorting.

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 (((“lexicographical order”)))(((“alphabetical order”)))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 `keyword` tokenizer emits the original input string
as a single unchanged token.(((“keyword tokenizer”)))
The `lowercase` token filter lowercases the token.

With(((“lowercase token filter”))) the case_insentive_sort analyzer in place, we can now use it in our


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 `name.lower_case_sort` field will provide us with
case-insentive sorting.

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

Every language has its own sort order, and(((“sorting”, “differences between languages”)))(((“languages”, “sort order, differences in”))) sometimes even multiple sort
orders.(((“Swedish, sort order”)))(((“German”, “sort order”)))(((“English”, “sort order”))) 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

==== Unicode Collation Algorithm

Collation is the process of sorting text into a predefined order.(((“collation”)))(((“Unicode Collation Algorithm (UCA)”))) The
Unicode Collation Algorithm, or UCA (see[]) 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(((“Default Unicode Collation Element Table (DUCET)”))) 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(((“languages”, “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

The approach described in this section will probably change in (((“Unicode”, “sorting”)))(((“sorting”, “Unicode”)))a future version of
Elasticsearch. Check the <<icu-plugin,icu plugin>> documentation for the
latest information.


The icu_collation token filter defaults(((“icu_collation token filter”))) 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” ] } } } } }

Use the default DUCET 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


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. (((“Default Unicode Collation Element Table (DUCET)”)))(((“Unicode Collation Algorithm (UCA)”))) We haven’t specified a language, so it defaults to
using the <<uca,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

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

The icu_collation filter can be (((“icu_collation token filter”, “specifying a language”)))(((“languages”, “collation table for a specific language, icu_collation filter using”)))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 (((“German”, “collation table for, icu_collation filter using”)))using the language, country, and variant parameters
as follows:


  • [source,json]

    { “language”: “en” }


  • [source,json]

    { “language”: “de” }

Austrian German::

  • [source,json]

    { “language”: “de”, “country”: “AT” }

German phonebooks::

  • [source,json]

    { “language”: “en”, “variant”: “@collation=phonebook” }

You can read more about the locales supported by ICU at:


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 `icu_collation` customized for the German phonebook collation.
Then we wrap that up in a custom analyzer.
And we apply it to our `name.sort` field.

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

The same field can support multiple (((“sorting”, “multiple sort orders supported by same field”)))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” } } } } }

We would need to create the corresponding analyzers for each of these collations.

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

The icu_collation token filter takes(((“collation”, “customizing collations”)))(((“icu_collation token filter”, “customizing collations”))) 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].

上一篇:Character folding



需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。