Today we are pleased to announce the release of Elasticsearch 2.2.0 based on Lucene 5.4.1, and bug fix releases of Elasticsearch 2.1.2, and Elasticsearch 1.7.5. All of these new releases are already available on Found, our Elasticsearch-as-a-service platform. This week’s release bonanza also includes new versions of Kibana, Logstash, Beats, and Elasticsearch-Hadoop.
Elasticsearch 2.2.0 contains two awesome new features: a query profiler and greatly improved geo-point fields. It ships with tighter security and contains an important fix for a bug which caused slow shard recovery in Elasticsearch 2.1.0, along with many other bug fixes and enhancements.
All users are encouraged to upgrade.
Latest stable release:
Bug fixes in 2.1:
Bug fixes in 1.7.5:
For the first time ever in the history of Lucene and Elasticsearch, you now have access to detailed query profiling information which allows you to understand and debug query performance. Each part of the query is timed independently, recording statistics such as how long it took to rewrite the query, to find matching docs, and to score them. There need be no more guessing about why a particular query is slow: just set the
profile parameter to
true and you have immediate — and in-depth — insight.
Why is this called the Profile API instead of the Query Profile API? Because we plan to expand this functionality to cover aggregations as well, and perhaps suggesters and highlighters too.
See the Profile API docs for more.
Geo-point fields have been completely rewritten to take advantage of a new compact data structure stored in the Lucene index. The result is 50% faster indexing, 20-50% faster geo-queries, half the disk and heap usage, and simpler mapping options. Existing geo-point fields will continue to work as before, while new geo-point fields will automatically take advantage of the new functionality.
You can read more about the geo-point improvements in Supercharging geo_point fields in Elasticsearch 2.2.
As part of our ongoing quest to make Elasticsearch as secure as possible, the Groovy and Lucene Expressions scripting languages have been moved out of core and are now distributed as modules, which are essentially plugins that are shipped by default. This move has allowed us to lock down the permissions available to these modules to reduce the attack vectors available to any hacker. More parts of Elasticsearch core will be modularised in future versions.
Scripting languages now have a predefined whitelist of classes that they are allowed to load — you don’t want scripts reading or writing files, or opening sockets to remote servers! You can read more about how to customise the whitelist in Scripting and the Java Security Manager.
Any plugins that require special permissions not allowed by default will have to declare these permissions, and you will be warned of this requirement at plugin install time. This has allowed us to move the
mapper-attachments plugin into the main Elasticsearch repository for 2.2.