elasticsearch/docs/reference/how-to/search-speed.asciidoc

[[tune-for-search-speed]]
== Tune for search speed

[discrete]
=== Give memory to the filesystem cache

Elasticsearch heavily relies on the filesystem cache in order to make search
fast. In general, you should make sure that at least half the available memory
goes to the filesystem cache so that Elasticsearch can keep hot regions of the
index in physical memory.

[discrete]
=== Use faster hardware

If your search is I/O bound, you should investigate giving more memory to the
filesystem cache (see above) or buying faster drives. In particular SSD drives
are known to perform better than spinning disks. Always use local storage,
remote filesystems such as `NFS` or `SMB` should be avoided. Also beware of
virtualized storage such as Amazon's `Elastic Block Storage`. Virtualized
storage works very well with Elasticsearch, and it is appealing since it is so
fast and simple to set up, but it is also unfortunately inherently slower on an
ongoing basis when compared to dedicated local storage. If you put an index on
`EBS`, be sure to use provisioned IOPS otherwise operations could be quickly
throttled.

If your search is CPU-bound, you should investigate buying faster CPUs.

[discrete]
=== Document modeling

Documents should be modeled so that search-time operations are as cheap as possible.

In particular, joins should be avoided. <<nested,`nested`>> can make queries
several times slower and <<parent-join,parent-child>> relations can make
queries hundreds of times slower. So if the same questions can be answered without
joins by denormalizing documents, significant speedups can be expected.

[discrete]
[[search-as-few-fields-as-possible]]
=== Search as few fields as possible

The more fields a <<query-dsl-query-string-query,`query_string`>> or
<<query-dsl-multi-match-query,`multi_match`>> query targets, the slower it is.
A common technique to improve search speed over multiple fields is to copy
their values into a single field at index time, and then use this field at
search time. This can be automated with the <<copy-to,`copy-to`>> directive of
mappings without having to change the source of documents. Here is an example
of an index containing movies that optimizes queries that search over both the
name and the plot of the movie by indexing both values into the `name_and_plot`
field.

[source,console]
--------------------------------------------------
PUT movies
{
  "mappings": {
    "properties": {
      "name_and_plot": {
        "type": "text"
      },
      "name": {
        "type": "text",
        "copy_to": "name_and_plot"
      },
      "plot": {
        "type": "text",
        "copy_to": "name_and_plot"
      }
    }
  }
}
--------------------------------------------------

[discrete]
=== Pre-index data

You should leverage patterns in your queries to optimize the way data is indexed.
For instance, if all your documents have a `price` field and most queries run
<<search-aggregations-bucket-range-aggregation,`range`>> aggregations on a fixed
list of ranges, you could make this aggregation faster by pre-indexing the ranges
into the index and using a <<search-aggregations-bucket-terms-aggregation,`terms`>>
aggregations.

For instance, if documents look like:

[source,console]
--------------------------------------------------
PUT index/_doc/1
{
  "designation": "spoon",
  "price": 13
}
--------------------------------------------------

and search requests look like:

[source,console]
--------------------------------------------------
GET index/_search
{
  "aggs": {
    "price_ranges": {
      "range": {
        "field": "price",
        "ranges": [
          { "to": 10 },
          { "from": 10, "to": 100 },
          { "from": 100 }
        ]
      }
    }
  }
}
--------------------------------------------------
// TEST[continued]

Then documents could be enriched by a `price_range` field at index time, which
should be mapped as a <<keyword,`keyword`>>:

[source,console]
--------------------------------------------------
PUT index
{
  "mappings": {
    "properties": {
      "price_range": {
        "type": "keyword"
      }
    }
  }
}

PUT index/_doc/1
{
  "designation": "spoon",
  "price": 13,
  "price_range": "10-100"
}
--------------------------------------------------

And then search requests could aggregate this new field rather than running a
`range` aggregation on the `price` field.

[source,console]
--------------------------------------------------
GET index/_search
{
  "aggs": {
    "price_ranges": {
      "terms": {
        "field": "price_range"
      }
    }
  }
}
--------------------------------------------------
// TEST[continued]

[discrete]
[[map-ids-as-keyword]]
=== Consider mapping identifiers as `keyword`

include::../mapping/types/numeric.asciidoc[tag=map-ids-as-keyword]

[discrete]
=== Avoid scripts

If possible, avoid using <<modules-scripting,script>>-based sorting, scripts in
aggregations, and the <<query-dsl-script-score-query,`script_score`>> query. See
<<scripts-and-search-speed>>.


[discrete]
=== Search rounded dates

Queries on date fields that use `now` are typically not cacheable since the
range that is being matched changes all the time. However switching to a
rounded date is often acceptable in terms of user experience, and has the
benefit of making better use of the query cache.

For instance the below query:

[source,console]
--------------------------------------------------
PUT index/_doc/1
{
  "my_date": "2016-05-11T16:30:55.328Z"
}

GET index/_search
{
  "query": {
    "constant_score": {
      "filter": {
        "range": {
          "my_date": {
            "gte": "now-1h",
            "lte": "now"
          }
        }
      }
    }
  }
}
--------------------------------------------------

could be replaced with the following query:

[source,console]
--------------------------------------------------
GET index/_search
{
  "query": {
    "constant_score": {
      "filter": {
        "range": {
          "my_date": {
            "gte": "now-1h/m",
            "lte": "now/m"
          }
        }
      }
    }
  }
}
--------------------------------------------------
// TEST[continued]

In that case we rounded to the minute, so if the current time is `16:31:29`,
the range query will match everything whose value of the `my_date` field is
between `15:31:00` and `16:31:59`. And if several users run a query that
contains this range in the same minute, the query cache could help speed things
up a bit. The longer the interval that is used for rounding, the more the query
cache can help, but beware that too aggressive rounding might also hurt user
experience.


NOTE: It might be tempting to split ranges into a large cacheable part and
smaller not cacheable parts in order to be able to leverage the query cache,
as shown below:

[source,console]
--------------------------------------------------
GET index/_search
{
  "query": {
    "constant_score": {
      "filter": {
        "bool": {
          "should": [
            {
              "range": {
                "my_date": {
                  "gte": "now-1h",
                  "lte": "now-1h/m"
                }
              }
            },
            {
              "range": {
                "my_date": {
                  "gt": "now-1h/m",
                  "lt": "now/m"
                }
              }
            },
            {
              "range": {
                "my_date": {
                  "gte": "now/m",
                  "lte": "now"
                }
              }
            }
          ]
        }
      }
    }
  }
}
--------------------------------------------------
// TEST[continued]

However such practice might make the query run slower in some cases since the
overhead introduced by the `bool` query may defeat the savings from better
leveraging the query cache.

[discrete]
=== Force-merge read-only indices

Indices that are read-only may benefit from being <<indices-forcemerge,merged
down to a single segment>>. This is typically the case with time-based indices:
only the index for the current time frame is getting new documents while older
indices are read-only. Shards that have been force-merged into a single segment
can use simpler and more efficient data structures to perform searches.

IMPORTANT: Do not force-merge indices to which you are still writing, or to
which you will write again in the future. Instead, rely on the automatic
background merge process to perform merges as needed to keep the index running
smoothly. If you continue to write to a force-merged index then its performance
may become much worse.

[discrete]
=== Warm up global ordinals

<<eager-global-ordinals,Global ordinals>> are a data structure that is used to
optimize the performance of aggregations. They are calculated lazily and stored in
the JVM heap as part of the <<modules-fielddata, field data cache>>. For fields
that are heavily used for bucketing aggregations, you can tell {es} to construct
and cache the global ordinals before requests are received. This should be done
carefully because it will increase heap usage and can make <<indices-refresh, refreshes>>
take longer. The option can be updated dynamically on an existing mapping by
setting the <<eager-global-ordinals, eager global ordinals>> mapping parameter:

[source,console]
--------------------------------------------------
PUT index
{
  "mappings": {
    "properties": {
      "foo": {
        "type": "keyword",
        "eager_global_ordinals": true
      }
    }
  }
}
--------------------------------------------------

[discrete]
=== Warm up the filesystem cache

If the machine running Elasticsearch is restarted, the filesystem cache will be
empty, so it will take some time before the operating system loads hot regions
of the index into memory so that search operations are fast. You can explicitly
tell the operating system which files should be loaded into memory eagerly
depending on the file extension using the
<<preload-data-to-file-system-cache,`index.store.preload`>> setting.

WARNING: Loading data into the filesystem cache eagerly on too many indices or
too many files will make search _slower_ if the filesystem cache is not large
enough to hold all the data. Use with caution.

[discrete]
=== Use index sorting to speed up conjunctions

<<index-modules-index-sorting,Index sorting>> can be useful in order to make
conjunctions faster at the cost of slightly slower indexing. Read more about it
in the <<index-modules-index-sorting-conjunctions,index sorting documentation>>.

[discrete]
[[preference-cache-optimization]]
=== Use `preference` to optimize cache utilization

There are multiple caches that can help with search performance, such as the
{wikipedia}/Page_cache[filesystem cache], the
<<shard-request-cache,request cache>> or the <<query-cache,query cache>>. Yet
all these caches are maintained at the node level, meaning that if you run the
same request twice in a row, have 1 <<glossary-replica-shard,replica>> or more
and use {wikipedia}/Round-robin_DNS[round-robin], the default
routing algorithm, then those two requests will go to different shard copies,
preventing node-level caches from helping.

Since it is common for users of a search application to run similar requests
one after another, for instance in order to analyze a narrower subset of the
index, using a preference value that identifies the current user or session
could help optimize usage of the caches.

[discrete]
=== Replicas might help with throughput, but not always

In addition to improving resiliency, replicas can help improve throughput. For
instance if you have a single-shard index and three nodes, you will need to
set the number of replicas to 2 in order to have 3 copies of your shard in
total so that all nodes are utilized.

Now imagine that you have a 2-shards index and two nodes. In one case, the
number of replicas is 0, meaning that each node holds a single shard. In the
second case the number of replicas is 1, meaning that each node has two shards.
Which setup is going to perform best in terms of search performance? Usually,
the setup that has fewer shards per node in total will perform better. The
reason for that is that it gives a greater share of the available filesystem
cache to each shard, and the filesystem cache is probably Elasticsearch's
number 1 performance factor. At the same time, beware that a setup that does
not have replicas is subject to failure in case of a single node failure, so
there is a trade-off between throughput and availability.

So what is the right number of replicas? If you have a cluster that has
`num_nodes` nodes, `num_primaries` primary shards _in total_ and if you want to
be able to cope with `max_failures` node failures at once at most, then the
right number of replicas for you is
`max(max_failures, ceil(num_nodes / num_primaries) - 1)`.

=== Tune your queries with the Profile API

You can also analyse how expensive each component of your queries and
aggregations are using the {ref}/search-profile.html[Profile API]. This might
allow you to tune your queries to be less expensive, resulting in a positive
performance result and reduced load. Also note that Profile API payloads can be
easily visualised for better readability in the
{kibana-ref}/xpack-profiler.html[Search Profiler], which is a Kibana dev tools
UI available in all X-Pack licenses, including the free X-Pack Basic license.

Some caveats to the Profile API are that:

 - the Profile API as a debugging tool adds significant overhead to search execution and can also have a very verbose output
 - given the added overhead, the resulting took times are not reliable indicators of actual took time, but can be used comparatively between clauses for relative timing differences
 - the Profile API is best for exploring possible reasons behind the most costly clauses of a query but isn't intended for accurately measuring absolute timings of each clause

[[faster-phrase-queries]]
=== Faster phrase queries with `index_phrases`

The <<text,`text`>> field has an <<index-phrases,`index_phrases`>> option that
indexes 2-shingles and is automatically leveraged by query parsers to run phrase
queries that don't have a slop. If your use-case involves running lots of phrase
queries, this can speed up queries significantly.

[[faster-prefix-queries]]
=== Faster prefix queries with `index_prefixes`

The <<text,`text`>> field has an <<index-prefixes,`index_prefixes`>> option that
indexes prefixes of all terms and is automatically leveraged by query parsers to
run prefix queries. If your use-case involves running lots of prefix queries,
this can speed up queries significantly.

[[faster-filtering-with-constant-keyword]]
=== Use `constant_keyword` to speed up filtering

There is a general rule that the cost of a filter is mostly a function of the
number of matched documents. Imagine that you have an index containing cycles.
There are a large number of bicycles and many searches perform a filter on
`cycle_type: bicycle`. This very common filter is unfortunately also very costly
since it matches most documents. There is a simple way to avoid running this
filter: move bicycles to their own index and filter bicycles by searching this
index instead of adding a filter to the query.

Unfortunately this can make client-side logic tricky, which is where
`constant_keyword` helps. By mapping `cycle_type` as a `constant_keyword` with
value `bicycle` on the index that contains bicycles, clients can keep running
the exact same queries as they used to run on the monolithic index and
Elasticsearch will do the right thing on the bicycles index by ignoring filters
on `cycle_type` if the value is `bicycle` and returning no hits otherwise.

Here is what mappings could look like:

[source,console]
--------------------------------------------------
PUT bicycles
{
  "mappings": {
    "properties": {
      "cycle_type": {
        "type": "constant_keyword",
        "value": "bicycle"
      },
      "name": {
        "type": "text"
      }
    }
  }
}

PUT other_cycles
{
  "mappings": {
    "properties": {
      "cycle_type": {
        "type": "keyword"
      },
      "name": {
        "type": "text"
      }
    }
  }
}
--------------------------------------------------

We are splitting our index in two: one that will contain only bicycles, and
another one that contains other cycles: unicycles, tricycles, etc. Then at
search time, we need to search both indices, but we don't need to modify
queries.


[source,console]
--------------------------------------------------
GET bicycles,other_cycles/_search
{
  "query": {
    "bool": {
      "must": {
        "match": {
          "description": "dutch"
        }
      },
      "filter": {
        "term": {
          "cycle_type": "bicycle"
        }
      }
    }
  }
}
--------------------------------------------------
// TEST[continued]

On the `bicycles` index, Elasticsearch will simply ignore the `cycle_type`
filter and rewrite the search request to the one below:

[source,console]
--------------------------------------------------
GET bicycles,other_cycles/_search
{
  "query": {
    "match": {
      "description": "dutch"
    }
  }
}
--------------------------------------------------
// TEST[continued]

On the `other_cycles` index, Elasticsearch will quickly figure out that
`bicycle` doesn't exist in the terms dictionary of the `cycle_type` field and
return a search response with no hits.

This is a powerful way of making queries cheaper by putting common values in a
dedicated index. This idea can also be combined across multiple fields: for
instance if you track the color of each cycle and your `bicycles` index ends up
having a majority of black bikes, you could split it into a `bicycles-black`
and a `bicycles-other-colors` indices.

The `constant_keyword` is not strictly required for this optimization: it is
also possible to update the client-side logic in order to route queries to the
relevant indices based on filters. However `constant_keyword` makes it
transparently and allows to decouple search requests from the index topology in
exchange of very little overhead.