OpenSearch/docs/reference/release-notes/highlights.asciidoc

81 lines
3.4 KiB
Plaintext
Raw Normal View History

[[release-highlights]]
== What's new in {minor-version}
coming[{minor-version}]
Here are the highlights of what's new and improved in {es} {minor-version}!
ifeval::["{release-state}"!="unreleased"]
For detailed information about this release, see the
<<release-notes-{elasticsearch_version}, Release notes >> and
<<breaking-changes-{minor-version}, Breaking changes>>.
endif::[]
// Add previous release to the list
Other versions:
{ref-bare}/7.9/release-highlights.html[7.9]
| {ref-bare}/7.8/release-highlights.html[7.8]
| {ref-bare}/7.7/release-highlights.html[7.7]
2020-06-15 15:50:49 -07:00
| {ref-bare}/7.6/release-highlights-7.6.0.html[7.6]
| {ref-bare}/7.5/release-highlights-7.5.0.html[7.5]
| {ref-bare}/7.4/release-highlights-7.4.0.html[7.4]
| {ref-bare}/7.3/release-highlights-7.3.0.html[7.3]
| {ref-bare}/7.2/release-highlights-7.2.0.html[7.2]
| {ref-bare}/7.1/release-highlights-7.1.0.html[7.1]
| {ref-bare}/7.0/release-highlights-7.0.0.html[7.0]
// tag::notable-highlights[]
[discrete]
=== More space-efficient indices
{es} 7.10 depends on Apache Lucene 8.7, which introduces higher compression of
stored fields, the part of the index that notably stores the
<<mapping-source-field,`_source`>>. On the various datasets that we benchmark
against, we noticed space reductions between 0% and 10%. This change especially
helps on datasets that have lots of redundant data across documents, which is
typically the case of the documents that are produced by our Observability
solutions, which repeat metadata about the host that produced the data on every
document.
Elasticsearch offers the ability to configure the <<index-codec,`index.codec`>>
setting to tell Elasticsearch how aggressively to compress stored fields. Both
supported values `default` and `best_compression` will get better compression
with this change.
// end::notable-highlights[]
// tag::notable-highlights[]
[discrete]
[[data-tier-formalization]]
=== Data Tier Formalization
7.10 introduces the concept of formalized data tiers within Elasticsearch. <<data-tiers,Data tiers>>
are a simple, integrated approach that gives users control over optimizing for cost,
performance, and breadth/depth of data. Prior to this formalization, many users configured their own
tier topology using custom node attributes as well as using {ilm-init} to manage the lifecycle and
location of data within a cluster.
With this formalization, data tiers (content, hot, warm, and cold) can be explicitly configured
using <<node-roles,node roles>>, and indices can be configured to be allocated within a specific
tier using <<data-tier-shard-filtering,index-level data tier allocation filtering>>. {ilm-init} will
make use of these tiers to <<ilm-migrate,automatically migrate>> data between nodes as an index goes
through the phases of its lifecycle.
Newly created indices abstracted by a <<data-streams,data stream>> will be allocated to
the `data_hot` tier automatically, while standalone indices will be allocated to
the `data_content` tier automatically. Nodes with the pre-existing `data` role are
considered to be part of all tiers.
// end::notable-highlights[]
// Use the notable-highlights tag to mark entries that
// should be featured in the Stack Installation and Upgrade Guide:
// tag::notable-highlights[]
// [discrete]
// === Heading
//
// Description.
// end::notable-highlights[]
// Omit the notable highlights tag for entries that only need to appear in the ES ref:
// [discrete]
// === Heading
//
// Description.