2014-09-30 05:54:50 -04:00
|
|
|
[[breaking-changes-2.0]]
|
|
|
|
|
== Breaking changes in 2.0
|
|
|
|
|
|
|
|
|
|
This section discusses the changes that you need to be aware of when migrating
|
|
|
|
|
your application to Elasticsearch 2.0.
|
|
|
|
|
|
|
|
|
|
=== Indices API
|
|
|
|
|
|
|
|
|
|
The <<alias-retrieving, get alias api>> will, by default produce an error response
|
|
|
|
|
if a requested index does not exist. This change brings the defaults for this API in
|
|
|
|
|
line with the other Indices APIs. The <<multi-index>> options can be used on a request
|
2014-10-17 07:24:04 -04:00
|
|
|
to change this behavior
|
|
|
|
|
|
|
|
|
|
=== Partial fields
|
|
|
|
|
|
|
|
|
|
Partial fields were deprecated since 1.0.0beta1 in favor of <<search-request-source-filtering,source filtering>>.
|
2014-10-27 10:15:04 -04:00
|
|
|
|
|
|
|
|
=== More Like This Field
|
|
|
|
|
|
|
|
|
|
The More Like This Field query has been removed in favor of the <<query-dsl-mlt-query, More Like This Query>>
|
Switch to murmurhash3 to route documents to shards.
We currently use the djb2 hash function in order to compute the shard a
document should go to. Unfortunately this hash function is not very
sophisticated and you can sometimes hit adversarial cases, such as numeric ids
on 33 shards.
Murmur3 generates hashes with a better distribution, which should avoid the
adversarial cases.
Here are some examples of how 100000 incremental ids are distributed to shards
using either djb2 or murmur3.
5 shards:
Murmur3: [19933, 19964, 19940, 20030, 20133]
DJB: [20000, 20000, 20000, 20000, 20000]
3 shards:
Murmur3: [33185, 33347, 33468]
DJB: [30100, 30000, 39900]
33 shards:
Murmur3: [2999, 3096, 2930, 2986, 3070, 3093, 3023, 3052, 3112, 2940, 3036, 2985, 3031, 3048, 3127, 2961, 2901, 3105, 3041, 3130, 3013, 3035, 3031, 3019, 3008, 3022, 3111, 3086, 3016, 2996, 3075, 2945, 2977]
DJB: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 900, 900, 900, 900, 1000, 1000, 10000, 10000, 10000, 10000, 9100, 9100, 9100, 9100, 9000, 9000, 0, 0, 0, 0, 0, 0]
Even if djb2 looks ideal in some cases (5 shards), the fact that the
distribution of its hashes has some patterns can raise issues with some shard
counts (eg. 3, or even worse 33).
Some tests have been modified because they relied on implementation details of
the routing hash function.
Close #7954
2014-10-01 18:34:05 -04:00
|
|
|
restrained set to a specific `field`.
|
|
|
|
|
|
|
|
|
|
=== Routing
|
|
|
|
|
|
|
|
|
|
The default hash function that is used for routing has been changed from djb2 to
|
|
|
|
|
murmur3. This change should be transparent unless you relied on very specific
|
|
|
|
|
properties of djb2. This will help ensure a better balance of the document counts
|
|
|
|
|
between shards.
|
|
|
|
|
|
|
|
|
|
In addition, the following node settings related to routing have been deprecated:
|
|
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
|
|
|
|
|
|
`cluster.routing.operation.hash.type`::
|
|
|
|
|
|
|
|
|
|
This was an undocumented setting that allowed to configure which hash function
|
|
|
|
|
to use for routing. `murmur3` is now enforced on new indices.
|
|
|
|
|
|
|
|
|
|
`cluster.routing.operation.use_type`::
|
|
|
|
|
|
|
|
|
|
This was an undocumented setting that allowed to take the `_type` of the
|
|
|
|
|
document into account when computing its shard (default: `false`). `false` is
|
|
|
|
|
now enforced on new indices.
|
