What Is New in Elasticsearch 5.2
Elasticsearch 5.2 delivers a solid set of incremental improvements focused on performance, usability, and new query capabilities. This release builds on the foundation of 5.x with key enhancements to the Painless scripting language, the introduction of the new random_score function, and significant index performance gains.
| Category | Key Highlights |
|---|---|
| New Features | Painless scripting enhancements, New random_score function, Ingest node processor updates |
| Improvements | Indexing performance, Recovery prioritization, Disk-based shard allocation |
| Bug Fixes | Various fixes across aggregation, mapping, and node discovery |
What scripting improvements were made in Painless?
Painless, the default scripting language, received several key upgrades. You can now use the continue keyword within loops, which is a standard control flow feature developers expect. The language also gained support for the += compound assignment operator, making scripts more concise and readable.
These changes matter because they reduce the friction of writing scripts for complex data processing and custom scoring. The syntax feels more like a full-fledged programming language, which speeds up development.
How does the new random_score function work?
The new random_score function generates a consistent random score for documents. You provide a seed and optionally a field to use for the hashing calculation. This is a replacement for the previous approach using a script.
{
"query": {
"function_score": {
"functions": [
{
"random_score": {
"seed": 10,
"field": "_seq_no"
}
}
]
}
}
}In practice, this is far more efficient than the old script-based method. It's perfect for A/B testing, shuffling results, or any use case where you need reproducible randomness.
What performance gains can I expect with indexing?
Indexing performance saw a significant boost, especially for append-only time-based data. The internal indexing process was optimized to reduce the merge overhead on indices that are primarily written to once. This directly benefits logging and metrics use cases.
The merge policy was tuned to be more efficient, which lowers I/O pressure and CPU usage on data nodes. You'll see this improvement during heavy indexing workloads without any required configuration changes.
How were ingest nodes improved?
The Set Processor in ingest nodes now supports copying values from one field to another. This is a simple but powerful addition for data transformation within an ingest pipeline, preventing the need for a custom script in many situations.
The Dot Expander processor was fixed to handle edge cases more reliably. These ingest node tweaks make data preprocessing smoother before it ever hits the index.
What's better about shard allocation and recovery?
Shard recovery now uses a prioritization system. Primary shards are recovered before replicas, which helps get your cluster back to a green state faster after a node failure. This is a logical change that improves recovery times.
The disk-based shard allocator got smarter about judging when a node is above the low watermark. It uses more accurate disk usage calculations, which helps prevent accidental read-only indices and makes allocation decisions more reliable.
FAQ
I used a script for random scoring before. Should I switch to random_score?
Yes, absolutely. The new random_score function is the official, supported way to do this and is significantly more performant than the old script method. It's a direct upgrade.
Do the Painless changes break my existing scripts?
No, the additions of continue and += are purely additive. Your existing scripts will continue to work without any modification. It just gives you more tools to write better scripts.
Will I see the indexing performance improvement for all my indices?
The most dramatic gains are for indices that are write-once, like time-series data streams. Indices with heavy update/delete workloads will still see benefits from the merge policy optimizations, but the effect might be less pronounced.
Is the recovery prioritization configurable?
No, the prioritization of primary shards over replicas is now the default behavior of the system. You don't need to configure it; the cluster will automatically prioritize for a faster recovery.
What was the main bug fix in this release?
One notable fix resolved an issue where the terms aggregation could return an incorrect document count (doc_count_error_upper_bound) when the index was refreshed during the aggregation execution. This improves the reliability of aggregation results.