mirror of
https://github.com/honeymoose/OpenSearch.git
synced 2025-02-09 06:25:07 +00:00
a0becd26b1
If elasticsearch controls the ID values as well as the documents version we can optimize the code that adds / appends the documents to the index. Essentially we an skip the version lookup for all documents unless the same document is delivered more than once. On the lucene level we can simply call IndexWriter#addDocument instead of #updateDocument but on the Engine level we need to ensure that we deoptimize the case once we see the same document more than once. This is done as follows: 1. Mark every request with a timestamp. This is done once on the first node that receives a request and is fixed for this request. This can be even the machine local time (see why later). The important part is that retry requests will have the same value as the original one. 2. In the engine we make sure we keep the highest seen time stamp of "retry" requests. This is updated while the retry request has its doc id lock. Call this `maxUnsafeAutoIdTimestamp` 3. When the engine runs an "optimized" request comes, it compares it's timestamp with the current `maxUnsafeAutoIdTimestamp` (but doesn't update it). If the the request timestamp is higher it is safe to execute it as optimized (no retry request with the same timestamp has been run before). If not we fall back to "non-optimzed" mode and run the request as a retry one and update the `maxUnsafeAutoIdTimestamp` unless it's been updated already to a higher value Relates to #19813
72 lines
3.2 KiB
Plaintext
72 lines
3.2 KiB
Plaintext
[[breaking_50_index_apis]]
|
|
=== Index APIs changes
|
|
|
|
==== Closing / deleting indices while running snapshot
|
|
|
|
In previous versions of Elasticsearch, closing or deleting an index during a
|
|
full snapshot would make the snapshot fail. In 5.0, the close/delete index
|
|
request will fail instead. The behavior for partial snapshots remains
|
|
unchanged: Closing or deleting an index during a partial snapshot is still
|
|
possible. The snapshot result is then marked as partial.
|
|
|
|
==== Warmers
|
|
|
|
Thanks to several changes like doc values by default and disk-based norms,
|
|
warmers are no longer useful. As a consequence, warmers and the warmer API
|
|
have been removed: it is no longer possible to register queries that will run
|
|
before a new IndexSearcher is published.
|
|
|
|
Don't worry if you have warmers defined on your indices, they will simply be
|
|
ignored when upgrading to 5.0.
|
|
|
|
==== System CPU stats
|
|
|
|
The recent CPU usage (as a percent) has been added to the OS stats
|
|
reported under the node stats API and the cat nodes API. The breaking
|
|
change here is that there is a new object in the `os` object in the node
|
|
stats response. This object is called `cpu` and includes `percent` and
|
|
`load_average` as fields. This moves the `load_average` field that was
|
|
previously a top-level field in the `os` object to the `cpu` object. The
|
|
format of the `load_average` field has changed to an object with fields
|
|
`1m`, `5m`, and `15m` representing the one-minute, five-minute and
|
|
fifteen-minute loads respectively. If any of these fields are not present,
|
|
it indicates that the corresponding value is not available.
|
|
|
|
In the cat nodes API response, the `cpu` field is output by default. The
|
|
previous `load` field has been removed and is replaced by `load_1m`,
|
|
`load_5m`, and `load_15m` which represent the one-minute, five-minute
|
|
and fifteen-minute loads respectively. The field will be null if the
|
|
corresponding value is not available.
|
|
|
|
Finally, the API for `org.elasticsearch.monitor.os.OsStats` has
|
|
changed. The `getLoadAverage` method has been removed. The value for
|
|
this can now be obtained from `OsStats.Cpu#getLoadAverage` but it is no
|
|
longer a double and is instead an object encapsulating the one-minute,
|
|
five-minute and fifteen-minute load averages. Additionally, the recent
|
|
CPU usage can be obtained from `OsStats.Cpu#getPercent`.
|
|
|
|
==== Suggest stats
|
|
|
|
Suggest stats exposed through `suggest` in indices stats has been merged
|
|
with `search` stats. `suggest` stats is exposed as part of `search` stats.
|
|
|
|
==== Creating indices starting with '-' or '+'
|
|
|
|
Elasticsearch no longer allows indices to be created started with '-' or '+', so
|
|
that the multi-index matching and expansion is not confused. It was previously
|
|
possible (but a really bad idea) to create indices starting with a hyphen or
|
|
plus sign. Any index already existing with these preceding characters will
|
|
continue to work normally.
|
|
|
|
==== Aliases API
|
|
|
|
The `/_aliases` API no longer supports `indexRouting` and `index-routing`, only
|
|
`index_routing`. It also no longer support `searchRouting` and `search-routing`,
|
|
only `search_routing`. These were removed because they were untested and we
|
|
prefer there to be only one (obvious) way to do things like this.
|
|
|
|
==== OpType Create without an ID
|
|
|
|
As of 5.0 indexing a document with `op_type=create` without specifying an ID is not
|
|
supported anymore.
|