Adaptive replica selection enabled by default
In Elasticsearch 6.x and prior, a series of search requests to the same shard
would be forwarded to the primary and each replica in round-robin fashion.
This could prove problematic if one node starts a long garbage collection .
search requests could still be forwarded to the slow node regardless
and would have an impact on search latency.
7.0之前的版本 一系列同一分片的搜索请求 会以轮询方式转发给主副本和每个副本。
Each node tracks and compares how long search requests to other nodes take,
and uses this information to adjust how frequently to send requests to shards on particular nodes.
This option was disabled by default throughout 6.x,
but we’ve heard feedback from our users that have found the setting to be very beneficial,
so we’ve turned it on by default starting in Elasticsearch 7.0.0.
Skip shard refreshes if a shard is "search idle"
automatically in the background, by default every second.
This provides the “near real-time” search capabilities
results are available for search requests within one second after they’d been added
A shard now transitions to being search idle after it hasn’t had any searches for thirty seconds
Once a shard is search idle, all scheduled refreshes will be skipped until a search comes through,
which will trigger the next scheduled refresh.
The new behavior is only applied if there is no explicit refresh interval set
Default to one shard
Of course, if you have another preferred primary shard count, you can set it via the index settings.
Elasticsearch 7.0 bundles Lucene 8, which is the latest version of Lucene.
improved search performance for top-k queries
and better ways to combine relevance signals for your searches while still maintaining speed.
Introduce the ability to minimize round-trips in cross-cluster search
New cluster coordination implementation
easy to scale and resilient to catastrophic failures.
a pluggable cluster coordination system, with the default implementation known as Zen Discovery.
Zen Discovery was meant to be effortless, and give our users peace of mind (as the name implies).
Zen’s minimum_master_nodes setting was often misconfigured,
which put clusters at a greater risk of split brains and losing data.
Maintaining this setting across large and dynamically resizing clusters was also difficult.
The new implementation gives safe sub-second master election times
With the minimum_master_nodes setting removed,
growing and shrinking clusters becomes safer and easier,
and leaves much less room to misconfigure the system.
Better support for small heaps (the real-memory circuit breaker)
adds an all-new circuit breaker that keeps track of the total memory used by the JVM
and will reject requests if they would cause the reserved plus actual heap usage to exceed 95%.
changing the default maximum buckets to return as part of an aggregation
(search.max_buckets) to 10,000, which is unbounded by default in 6.x and prior.
keep cluster alive even in the face of adversarial or novice users running large queries and aggregations.
Cross-cluster replication is production-ready
Index lifecycle management is production-ready
hot, warm, cold, and deletion phases
ILM can now manage frozen indices.
Frozen indices are valuable for long term data storage in Elasticsearch,
and require a smaller amount of memory (heap) in relation to the amount of data managed by a node.
SQL is production-ready
JDBC and ODBC drivers
There are four methods to access Elasticsearch SQL:
through the REST endpoints, the SQL command line interface, the JDBC driver, and the ODBC driver.
High-level REST client is feature-complete
Support nanosecond timestamps
With JDK 8, an official Java time API has been introduced which can also handle nanosecond precision timestamps
date_nanos field mapper.
Note that aggregations are still on a millisecond resolution with this field to avoid having an explosion of buckets.
Faster retrieval of top hits
users typically just look at the first page of results on your site
and don’t care about exactly how many documents matched,
show them “more than 10,000 hits” and then provide them with paginated results.
It’s quite common to have users enter frequently-occurring terms like “the” and “a” in their queries,
which has historically forced Elasticsearch to score a lot of documents
even when those frequent terms couldn’t possibly add much to the score.
Support for TLS 1.3
Bundle JDK in Elasticsearch distribution
Script score query (aka function score 2.0)edit
Elastic Stack 7.0.0 特性介绍
不使用 select * 的七个理由