Today we are excited to announce the release of Elasticsearch 5.0.0-alpha4 based on Lucene 6.1.0. This is the fourth in a series of pre-5.0.0 releases designed to let you test out your application with the features and changes coming in 5.0.0, and to give us feedback about any problems that you encounter.
Open a bug report today and become an Elastic Pioneer.
IMPORTANT: This is an alpha release and is intended for testing purposes only. Indices created in this version will not be compatible with Elasticsearch 5.0.0 GA.
DO NOT DEPLOY IN PRODUCTION
Elasticsearch 5.0.0-alpha4 delivers some exciting new features which we talk about below. In addition, there are many small changes which you can read about in the release notes above.
- Ingest Node
- Painless Scripting
- Instant Aggregations
- Text/Keyword fields replacing String
- Completion Suggester v2
- Settings Validation
- Safety in Production
- Resiliency Improvements
- Percolate Query
- Deleted Index Tombstones
- Dots in field names
- Cluster allocation explain API
The Elasticsearch Migration Helper is a site plugin designed to help you to prepare for your migration from Elasticsearch 2.3.x to Elasticsearch 5.0. It comes with three tools:
- Cluster Checkup
- Runs a series of checks on your cluster, nodes, and indices and alerts you to any known problems that need to be rectified before upgrading.
- Reindex Helper
- Indices created before v2.0.0 need to be reindexed before they can be used in Elasticsearch 5.x. The reindex helper upgrades old indices at the click of a button.
- Deprecation Logging
- Elasticsearch comes with a deprecation logger which will log a message whenever deprecated functionality is used. This tool enables or disables deprecation logging on your cluster.
Instruction for install the Elasticsearch migration helper.
After years of waiting, we have finally released the first version of a low-level Java HTTP/REST client. It provides a simple HTTP client with minimal dependencies, which handles sniffing, logging, round robinning of requests, and retry on node failure. While the Java Transport client has served us well, it has certain problems:
- Application code has to be upgraded with every release of Elasticsearch.
- Applications are forced to use the same JVM version as Elasticsearch, which is Java 8 in 5.0.
- It pulls in all of the dependencies of Elasticsearch which can conflict with application dependencies.
- It cannot be used across major version upgrades.
- It cannot be used with an HTTP proxy.
The Java HTTP client improves on this situation:
- It uses the REST layer which has historically been much more stable than the Java API, which means that it can be used across upgrades, possibly even upgrades across major versions.
- It can be used with Java 7.
- It has minimal dependencies, resulting in fewer dependency conflicts.
- It is just HTTP and so can be firewalled/proxied like all of the other HTTP clients.
Be aware that this is a low-level client. At this stage we don’t provide any query builders or helpers that will allow for autocompletion in your IDE. It is JSON-in, JSON-out, and it is up to you how you build the JSON. Development won’t stop here — we will be adding an API which will help you to construct queries and to parse responses. You can follow the changes in issue #19055.
Managing indices for time-based event data like log messages is about to get much easier. The new Rollover API will rollover an index alias to a new index when the old index is too big or too old. The new Shrink API allows you to shrink an index with multiple shards into a new index with a single shard (or with fewer shards than the original). This means that your active index can start off having one shard for every node, making the most of the I/O resources available in your cluster. When the index is rolled over, you can shrink the old index down to a single shard, force-merge, and compress it. A blog post explaining this procedure will follow soon.
When a user adds a comment to a blog post, they expect to see their comment at the top of the list. Achieving this, however, can be tricky. Elasticsearch has near real time search; document changes only become visible to search once the index has been refreshed. This happens once every second by default but can take longer than that depending on how busy the system is. Waiting for one second before redirecting the user to the comments page works sometimes, but it can be a bit hit and miss. The alternative, forcing a refresh every time you index a document, is heavy and will reduce indexing rates.
Now there is an easy solution to this problem. If you specify
?refresh=wait_for on any index, update, or delete request, the request will block until a refresh has happened and the change is visible to search. If too many requests are queued up, it will force a refresh to clear out the queue.
- The search profiler now supports aggregations as well as queries.
half_floatfield datatype, which uses only 16 bits, has enough precision for most metric use cases, but half the storage cost of a
- Scroll requests can now be sliced into multiple requests to be consumed in parallel.
_ttlmeta-fields can no longer be used on new indices.