For the 7.10 release of Elastic Workplace Search, we highlighted some of the new analytics logging capabilities and took you through a short walkthrough of some sample analysis scenarios. With the 7.11 release we introduced analytics fields, which open up new possibilities for exploring query and click data with helpful dashboards and visualizations.
We are excited to bring you a number of updates for using Elastic Cloud (Elasticsearch managed service) in the AWS Marketplace.
We're excited to announce that autoscaling is now available on Elastic Cloud. In our initial release, autoscaling monitors the storage utilization of your Elasticsearch data nodes and the available memory capacity for your machine learning jobs.
Back in our 7.10 release of the Elastic Stack, we announced the beta of our Ruby and Python clients for Elastic Enterprise Search. Now, with 7.11, both the Ruby and Python clients are generally available. We’ve also begun work on a PHP client. All client source code for both enterprise-search-ruby and enterprise-search-python is available on GitHub. Documentation on how to get started with each client is available on elastic.co.
The cold tier of searchable snapshots, previously beta in Elasticsearch 7.10, is now generally available in Elasticsearch 7.11. This new data tier reduces your cluster storage by up to 50% over the warm tier while maintaining the same level of reliability and redundancy as your hot and warm tiers.
Historically, Elasticsearch has relied on a schema on write approach to make searching data fast. We are now adding schema on read capabilities to Elasticsearch so that users have the flexibility to alter a document's schema after ingest and also generate fields that exist only as part of the search query. Together, schema on read and schema on write provides users with the choice to balance performance and flexibility based on their needs.
In 7.11, we’re excited to announce support for schema on read in the Elastic Stack. We now offer the best of both worlds on a single platform — the performance and scale of the existing schema on write mechanism that our users love and depend on, coupled with a new level of flexibility for defining and executing queries with schema on read. We call our implementation of schema on read runtime fields.
