|
|
@@ -11,7 +11,8 @@ For detailed information about this release, see the <<es-release-notes>> and
|
|
|
// Add previous release to the list
|
|
|
Other versions:
|
|
|
|
|
|
-{ref-bare}/8.15/release-highlights.html[8.15]
|
|
|
+{ref-bare}/8.16/release-highlights.html[8.16]
|
|
|
+| {ref-bare}/8.15/release-highlights.html[8.15]
|
|
|
| {ref-bare}/8.14/release-highlights.html[8.14]
|
|
|
| {ref-bare}/8.13/release-highlights.html[8.13]
|
|
|
| {ref-bare}/8.12/release-highlights.html[8.12]
|
|
|
@@ -30,104 +31,13 @@ Other versions:
|
|
|
|
|
|
endif::[]
|
|
|
|
|
|
+// The notable-highlights tag marks entries that
|
|
|
+// should be featured in the Stack Installation and Upgrade Guide:
|
|
|
// tag::notable-highlights[]
|
|
|
-
|
|
|
-[discrete]
|
|
|
-[[esql_inlinestats]]
|
|
|
-=== ESQL: INLINESTATS
|
|
|
-This adds the `INLINESTATS` command to ESQL which performs a STATS and
|
|
|
-then enriches the results into the output stream. So, this query:
|
|
|
-
|
|
|
-[source,esql]
|
|
|
-----
|
|
|
-FROM test
|
|
|
-| INLINESTATS m=MAX(a * b) BY b
|
|
|
-| WHERE m == a * b
|
|
|
-| SORT a DESC, b DESC
|
|
|
-| LIMIT 3
|
|
|
-----
|
|
|
-
|
|
|
-Produces output like:
|
|
|
-
|
|
|
-| a | b | m |
|
|
|
-| --- | --- | ----- |
|
|
|
-| 99 | 999 | 98901 |
|
|
|
-| 99 | 998 | 98802 |
|
|
|
-| 99 | 997 | 98703 |
|
|
|
-
|
|
|
-{es-pull}109583[#109583]
|
|
|
-
|
|
|
-[discrete]
|
|
|
-[[always_allow_rebalancing_by_default]]
|
|
|
-=== Always allow rebalancing by default
|
|
|
-In earlier versions of {es} the `cluster.routing.allocation.allow_rebalance` setting defaults to
|
|
|
-`indices_all_active` which blocks all rebalancing moves while the cluster is in `yellow` or `red` health. This was
|
|
|
-appropriate for the legacy allocator which might do too many rebalancing moves otherwise. Today's allocator has
|
|
|
-better support for rebalancing a cluster that is not in `green` health, and expects to be able to rebalance some
|
|
|
-shards away from over-full nodes to avoid allocating shards to undesirable locations in the first place. From
|
|
|
-version 8.16 `allow_rebalance` setting defaults to `always` unless the legacy allocator is explicitly enabled.
|
|
|
-
|
|
|
-{es-pull}111015[#111015]
|
|
|
-
|
|
|
-[discrete]
|
|
|
-[[add_global_retention_in_data_stream_lifecycle]]
|
|
|
-=== Add global retention in data stream lifecycle
|
|
|
-Data stream lifecycle now supports configuring retention on a cluster level,
|
|
|
-namely global retention. Global retention \nallows us to configure two different
|
|
|
-retentions:
|
|
|
-
|
|
|
-- `data_streams.lifecycle.retention.default` is applied to all data streams managed
|
|
|
-by the data stream lifecycle that do not have retention defined on the data stream level.
|
|
|
-- `data_streams.lifecycle.retention.max` is applied to all data streams managed by the
|
|
|
-data stream lifecycle and it allows any data stream \ndata to be deleted after the `max_retention` has passed.
|
|
|
-
|
|
|
-{es-pull}111972[#111972]
|
|
|
-
|
|
|
-[discrete]
|
|
|
-[[enable_zstandard_compression_for_indices_with_index_codec_set_to_best_compression]]
|
|
|
-=== Enable ZStandard compression for indices with index.codec set to best_compression
|
|
|
-Before DEFLATE compression was used to compress stored fields in indices with index.codec index setting set to
|
|
|
-best_compression, with this change ZStandard is used as compression algorithm to stored fields for indices with
|
|
|
-index.codec index setting set to best_compression. The usage ZStandard results in less storage usage with a
|
|
|
-similar indexing throughput depending on what options are used. Experiments with indexing logs have shown that
|
|
|
-ZStandard offers ~12% lower storage usage and a ~14% higher indexing throughput compared to DEFLATE.
|
|
|
-
|
|
|
-{es-pull}112665[#112665]
|
|
|
-
|
|
|
-[discrete]
|
|
|
-[[8_x_remove_zstd_feature_flag_for_index_codec_best_compression]]
|
|
|
-=== [8.x] Remove zstd feature flag for index codec best compression
|
|
|
-Backports the following commits to 8.x: - Remove zstd feature flag for
|
|
|
-index codec best compression. (#112665)
|
|
|
-
|
|
|
-{es-pull}112857[#112857]
|
|
|
-
|
|
|
+// [discrete]
|
|
|
+// === Heading
|
|
|
+//
|
|
|
+// Description.
|
|
|
// end::notable-highlights[]
|
|
|
|
|
|
|
|
|
-[discrete]
|
|
|
-[[esql_multi_value_fields_supported_in_geospatial_predicates]]
|
|
|
-=== ESQL: Multi-value fields supported in Geospatial predicates
|
|
|
-Supporting multi-value fields in `WHERE` predicates is a challenge due to not knowing whether `ALL` or `ANY`
|
|
|
-of the values in the field should pass the predicate.
|
|
|
-For example, should the field `age:[10,30]` pass the predicate `WHERE age>20` or not?
|
|
|
-This ambiguity does not exist with the spatial predicates
|
|
|
-`ST_INTERSECTS` and `ST_DISJOINT`, because the choice between `ANY` or `ALL`
|
|
|
-is implied by the predicate itself.
|
|
|
-Consider a predicate checking a field named `location` against a test geometry named `shape`:
|
|
|
-
|
|
|
-* `ST_INTERSECTS(field, shape)` - true if `ANY` value can intersect the shape
|
|
|
-* `ST_DISJOINT(field, shape)` - true only if `ALL` values are disjoint from the shape
|
|
|
-
|
|
|
-This works even if the shape argument is itself a complex or compound geometry.
|
|
|
-
|
|
|
-Similar logic exists for `ST_CONTAINS` and `ST_WITHIN` predicates, but these are not as easily solved
|
|
|
-with `ANY` or `ALL`, because a collection of geometries contains another collection if each of the contained
|
|
|
-geometries is within at least one of the containing geometries. Evaluating this requires that the multi-value
|
|
|
-field is first combined into a single geometry before performing the predicate check.
|
|
|
-
|
|
|
-* `ST_CONTAINS(field, shape)` - true if the combined geometry contains the shape
|
|
|
-* `ST_WITHIN(field, shape)` - true if the combined geometry is within the shape
|
|
|
-
|
|
|
-{es-pull}112063[#112063]
|
|
|
-
|
Brian Seeders