Elasticsearch 7.16 is there: What’s new?
The race to better is on and you should look at these improvements.
Elastic has released a new version of Elasticsearch and it’s time to go through what is new in this version. That’s the sole purpose of this tutorial.
Version 7.16 of Elasticsearch brings many improvements. In this tutorial, I’ll walk you through three (03) of them. What are we waiting for? Without further ado, let’s get into in.
1- Cross-cluster search support
Elasticsearch uses a distributed architecture that relies on clusters. Clusters are composed of nodes, nodes containing shards, and so on till the indices and the documents.
One of the amazing features that Elasticsearch offered before this latest version is multi-indices search. And from now on, you can make your request against a set of indices that are on different clusters. Take a minute to think about it. Just wonderful!
2- Cached requests and queries responses for frozen tier
Frozen tier is a feature introduced in Elasticsearch 7.12 that allows you to search through searchable snapshots stored as large volume objects on various cloud service providers like AWS, GCP, and Azure.
In this new version of Elasticsearch, Elastic levels up the standard to cache all the queries that you already made in order to serve you quicker as more as you are running queries again those less searched data.
3- Search: Improved can-match phase for scalability
This is a pure improvement and when it comes to Elasticsearch, it’s really relevant to reduce queries response times and avoid as much as possible any overload for a huge data processing. I think the documentation describes this best:
If a search hits a large number of shards, the search operation includes a pre-filter phase called the can-match phase. During this phase, Elasticsearch checks if an impacted shard contains data that could potentially match the search query. If not, Elasticsearch doesn’t run the query on the shard.
Previously, the search’s coordinating node sent an individual request to each shard checked during the can-match phase. However, if the search needed to check thousands of shards, the coordinating node would need to handle thousands of requests, resulting in high overhead.
With 7.16, the coordinating node instead sends a single request to each data node during the can-match phase. This request covers can-match checks for all impacted shards on the node, significantly reducing the number of requests and related overhead.
The fact here is that because the coordinating node is not going to send data to every shard that is on a node but rather to the nodes, the time the pre-checking operation will take drastically decreases, and we’re going to have a better time response.
Out of this tutorial, I want you to keep a few things in mind. If you want to take advantage of searchable snapshots on the Cloud providers platform, you should go for Elasticsearch 7.16. It brings so many other interesting improvements to better your experience using Elasticsearch.
Thank you for reading me. Till next time, take care!