What Is New in Elasticsearch 6.0
| Category | Key Changes |
|---|---|
| New Features | Sequence IDs, Index Sorting, Partial Update Improvements, SQL Access (Alpha) |
| Performance & Scalability | Fewer Lucene Segments, Sparse Field Optimizations, Faster Indexing |
| Mapping & Index Management | Single Type per Index, Sparse Doc Values, Improved Defaults |
| Breaking Changes | Upgrade Path Enforcement, Removal of Deprecated Functionality |
How does index sorting improve query performance?
Index sorting allows you to physically store documents on disk in a specified order. This is a major performance win for range queries and sort aggregations. When data is pre-sorted, Elasticsearch can quickly locate the relevant value ranges without scanning the entire index.
You enable it during index creation. For instance, sorting by timestamp in descending order means your time-based queries will run significantly faster. In practice, this is a game-changer for log analytics and time-series use cases where sorting is common.
PUT my_index
{
"settings": {
"index": {
"sort.field": "timestamp",
"sort.order": "desc"
}
},
"mappings": {
"doc": {
"properties": {
"timestamp": {
"type": "date"
}
}
}
}
}Why is there only one mapping type per index now?
Elasticsearch 6.0 enforces a single mapping type per index. This is a crucial step in the plan to remove types entirely. The old multi-type model often caused mapping conflicts and confusion, as different types in the same index shared the same underlying Lucene fields.
You'll need to adjust your data modeling strategy. Instead of putting different types in one index, you now create separate indices. This leads to cleaner mappings, better performance, and avoids those tricky field-type collision errors we've all encountered.
What are sequence IDs and why do they matter for resiliency?
Sequence IDs are a new internal mechanism that track indexing operations. They provide a reliable way to distinguish between old and new operations during recovery, ensuring data is not replayed out of order after a restart or a failover.
This is the foundation for future crash-recovery features. It makes the system more robust by preventing document version conflicts that could previously occur if a primary shard failed and a new one was promoted.
How do sparse field optimizations save disk space?
Elasticsearch 6.0 is smarter about handling fields that are missing in many documents. It now disables Doc Values for fields that are predominantly sparse. Doc Values are great for aggregations and sorting, but they consume disk space for every document, even if the field is null.
By automatically disabling them for sparse fields, you get significant storage savings without any configuration. This is a huge benefit for schemas with many optional fields, a common pattern in E-commerce and logging.
FAQ
Can I upgrade directly from Elasticsearch 5.x to 6.0?
No. You must upgrade to the last available 5.6 release first. The 6.0 upgrade process performs a compatibility check and will fail if you try to upgrade directly from an earlier version like 5.5.
What happens to my existing indices with multiple types?
They will continue to work in 6.0, but you cannot create new indices with more than one type. All new indices are subject to the single-type rule. You should start planning to reindex your old multi-type indices into single-type ones.
Is the SQL feature production-ready?
No, the SQL access is in alpha. It's a cool feature for exploratory queries, but it lacks performance optimizations and full functionality. Avoid using it for production workloads until it's more mature.
Why are my string fields now mapped as both `text` and `keyword`?
This is a change to the dynamic mapping defaults. In 6.0, a dynamic string field will create both a full-text (text) and an exact-value (keyword) sub-field. This provides sensible defaults for both searching and aggregating out of the box.
Were any important features removed or deprecated?
Yes, several deprecated features were removed. The most notable ones are the `_all` field (which is disabled by default) and the `index.query.default_field` setting. You should stop relying on these if you haven't already.