In 7.10, we’re thrilled to be releasing the beta of searchable snapshots, a feature that allows you to reduce storage costs while no significant impact to performance so you can store and search everything.

<p>In 7.10, we're thrilled to be releasing the beta of searchable snapshots, a feature that transforms the way in which you can use your choice of object store (such as AWS S3, Microsoft Azure Storage, Google Cloud Storage, or equivalent) to trade off between dramatically reducing storage costs, ingesting and retaining more data in the Elastic Stack, and the fast search performance you're used to with the Elastic Stack. While we've had support for backing up data to low-cost object stores for a long time, with searchable snapshots you can now use them as an active part of storing and searching your data.
</p><p>We will be using searchable snapshots to power two new first-class data tiers: cold tier, which is also in beta in 7.10, and a future frozen tier. We've long supported multiple data tiers for data lifecycle management - hot for high speed, and warm for lower cost and performance. The new cold tier, powered by searchable snapshots, can reduce your storage costs by up to 50%, increasing the local storage density of your read-only data by offloading the redundant copy of the data to a low-cost object store. The frozen tier, currently in development, will take it a step further and fully store data exclusively in the low-cost object store while keeping it fully searchable, with local cache for fast queries on frequently accessed data. And, like all features we build, there are APIs to directly control how searchable snapshots load, manage, and search data from your object store. These new capabilities will make it both easier and cheaper to manage your growing data volumes in Elastic, empowering you to cost-effectively meet your data retention requirements while opening up new use cases such as giving your team the ability to have unlimited lookback for security investigations or year-over-year performance comparisons on Black Friday.
</p><h2>An evolving journey</h2><p>Time series data is everywhere. It is logs, metrics, traces, security events. It's the backbone of security and observability use cases, and many more. We've been continuously investing in making it easier, faster and more efficient to manage and scale such data over time. This is critical because of how quickly it grows. If you're collecting a terabyte of data per day, for example, that's seven terabytes a week. Kept over several years, this easily grows to petabytes of data. Users need a way to manage this exponential storage growth and still have the ability to search it.
</p><p>Our approach to solving this problem has been to look at the lifecycle of data. When data is first ingested, it's likely to be heavily searched. When you're investigating an incident, for example, you need fast access to all the relevant data to identify and resolve the issue. When an attacker compromises a host or an application, your ability to respond quickly often determines the impact of the breach. But data may also be categorized into different levels of use depending on the source or type. Some data may only be needed to be kept for legal or compliance reasons, or the occasional lookback for comparison purposes. Users therefore need different levels of storage and processing power for these different levels of needs, whether it's based on age, data source, or other criteria.
</p><p>We have been on a mission to give you the ability to balance the cost, performance, and capabilities to meet your needs. This involves investment at all levels of our stack, but a core pillar of our approach is data tiers - managing the lifecycle of data. This concept isn't new, and has been around since the earliest versions of Elasticsearch. Index Lifecycle Management (ILM) provides some conventions to make it easy to manage data across hot (fast machines with SSDs) and warm nodes (lower-cost machines that may have spinning disks), and we've had support for it in Elastic Cloud for years. Snapshot Lifecycle Management (SLM) further makes it easy to use low-cost object stores from AWS, Google, Azure, and on-prem storage vendors to take and store backups. While these snapshots are a key part of many deployments, they haven't been an active part of the data tiering story. Why? Because snapshots haven't been searchable. But that's all changing now with searchable snapshots, which allow us to create new, cheaper data tiers that leverage these low-cost object stores while bringing your backups to life.
</p><h2>Introducing searchable snapshots</h2><p>We're really excited about searchable snapshots, as it allows us to use S3 and other object stores in entirely new ways. While you can continue to use your object store to store your backed-up data as snapshots, you can now bring that object store to life, keeping it always online and available, by making your snapshots directly searchable by Elasticsearch. To build this and give a good experience, we've made changes at all layers of our products - from Kibana, to Elasticsearch, and all the way down to Lucene. In fact, we've used our deep expertise in Lucene to optimize the search mechanism to pull down only those subsets of the snapshot index that are really needed to answer your query or load your dashboard. Searchable snapshots makes the process of recovering or retrieving data from your snapshot-backed indices in S3 or other object store totally seamless and fast, and it has also allowed us to develop new data tiers that offer you more value at a lower cost.
</p><h3>The cold tier</h3><p>The new cold tier, available in beta in the 7.10 release, reduces your cluster storage by up to 50% over the warm tier. It maintains the same level of reliability and redundancy as your hot and warm tiers, with full support for automatic recovery from hardware failures on any of your nodes. This makes it much more cost effective to ask questions of your data like "How does this spike compare to last month?" or "Has this user logged into a restricted system in the last 6 months?"
</p><p>How did we do this? Well, in your hot and warm tiers, half of your disk is used to store replica shards. These redundant copies ensure fast and consistent query performance and provide you with resiliency in case a machine fails. If that happens, a replica seamlessly takes over as the primary, and your indexing and searches continue unabated.
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltab265f0cc2b23f59/5fb58cd342256d5ffdf4473b/diagram-primary-shard-disk-replica-shard.jpg" data-sys-asset-uid="bltab265f0cc2b23f59" alt="diagram-primary-shard-disk-replica-shard.jpg">
</p><p>But once your data becomes read-only, redundancy can easily be offloaded. Your snapshot repository is perfect for this, since it's much cheaper to store data in S3 than on either local SSDs or spinning disks. So, in the cold tier, your replica shards are stored in S3 as snapshots. As a result, we've doubled the usable capacity of your cold nodes for the same cost as before - with modest impact to query performance.
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltf83d69b7e5f12449/5fb58cf609ed4c6f277ee4ae/diagram-higher-performing-disk-es-snapshot-on-s3.jpg" data-sys-asset-uid="bltf83d69b7e5f12449" alt="diagram-higher-performing-disk-es-snapshot-on-s3.jpg">
</p><p>If there's a local node or disk failure in the cold tier, we use searchable snapshots to automatically recover using the replica indices stored as snapshots in S3, making these indexes available to serve search requests in a fraction of the time it takes to do a regular snapshot restore. That's how it all comes together.
</p><h3>The frozen tier</h3><p>Imagine if you had unlimited lookback in your security investigations, or could drill into the raw data from APM to see how your customer behavior has changed over the last two years. That's where the frozen tier comes in, and it opens the door to entirely new use cases with both types and volumes of data that previously just haven't been cost-effective to use Elasticsearch for. Think about how powerful the concept of searchable S3 can be to your business objectives. Actively in development right now, the frozen tier will let you directly search data stored in S3 or your choice of object store. With the frozen tier, there won't be a need to store any of your data locally at all - it can all just be stored as snapshots in S3. And here's the neat thing about the frozen tier - there's no need to pull out your frozen data and rehydrate it in the off chance that you do need to access it for an audit or security investigation. You can just use searchable snapshots to run your queries against it directly.
</p><p>With the frozen tier, what we will be offering is unprecedented: the ability to search nearly an unlimited amount of data, on demand, with costs approaching the cost of storing that data on S3. The fully automated lifecycle of your data becomes complete - from hot, to warm, to cold and then to frozen, all while ensuring you have the access and search performance you need at the lowest storage cost possible.
</p><h3>Optimizing for the best user experience</h3><p>Releasing groundbreaking new capabilities is one thing, and we always strive to do that for you. The other key piece to this is ensuring that everything else works well in unison with these new features to offer you the best possible user experience.
</p><ul>
	<li>Simplified data tier configuration: We've greatly simplified and streamlined the way you set up your data tiers and configure your ILM policies with new roles you assign to your data nodes, which are then used by the Elastic Stack to automatically allocate your data to the appropriate tier when using Index Lifecycle Management. </li>
	<li>Async search: While we've done everything we can to make searching S3 fast, we're not magicians. Queries against S3 will simply just take longer than milliseconds. And when they do, we want to provide the best possible user experience. That's why we've developed an asynchronous search mechanism in Elasticsearch which significantly enhances the experience in Kibana around long running queries. You can now execute a search request asynchronously without having to wait for the results. Instead, you can monitor the progress of the request and retrieve results at a later stage. You can even retrieve partial results as they become available before the search has completed. </li>
	<li>Query efficiency: We've introduced a series of improvements to skip searching indices that don't match or aren't even necessary when you run a search. For example, indices that we know won't have any matches are automatically skipped by pre-filtering based on time or other properties in the data. Searches are also exited early wherever possible, using block-max WAND for text search, sorted queries sorting the shards we search, stopping the search when we have enough matches, and so on.  </li>
</ul><p>Each enhancement offers value just by itself, but together the whole is far greater than the sum of its parts. We're constantly keeping the bigger picture in mind as we develop features, and tying them seamlessly back to all the capabilities already available in the Elastic Stack.
</p><h3>Solving for use cases and our solutions</h3><p>Imagine the value you could unlock if you could easily and cost-effectively search years of logs, metrics, and APM traces with searchable snapshots on object stores like S3. So long, rehydration! With searchable snapshots and Elastic Observability, you'll be able to directly query years of archived data without having to go through the slow and costly process of restoring indices from snapshots before doing a search.
</p><p>What if you could arm threat hunters and analysts with years of high-volume security data sources on object stores like S3, made easily accessible through searchable snapshots? With searchable snapshots and Elastic Security, you can collect high-volume security-related data, such as IDS, NetFlow, DNS, PCAP, or endpoint data, at greater scale and keep it accessible for longer than previously practical on new data tiers that reduce costs while preserving searchability.
</p><p>Finally, consider the ability to search across all of your application content and historical workplace records without breaking the bank by searching object stores with searchable snapshots. Elastic Enterprise Search will also benefit from the new searchable snapshot capabilities launching in the Elastic Stack. Whether you're supporting additional orders of magnitude of application content or searching across historical organizational records that can be safely stored in object stores like S3, you can store all the archived and historical content in a searchable way without breaking the bank.
</p><h2>The journey continues</h2><p>We're excited about the big steps we've taken with the beta releases of searchable snapshots and the cold tier in 7.10. And we're just as excited about the road ahead - a frozen tier to come soon after, as well as both managed cold and frozen tiers with simple sliders in Elastic Cloud to really simplify the signup and subscription flow for users. As always, it's an ongoing journey for us, and what keeps us going is the continuous additional value we keep providing to you with every release.
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt932bb37af00919be/5fb58d1465bdd35303e03971/diagram-searchable-snapshots-today-next-future.jpg" data-sys-asset-uid="blt932bb37af00919be" alt="diagram-searchable-snapshots-today-next-future.jpg">
</p><h2>Get started today </h2><p>To get started with searchable snapshots and begin storing data in the cold tier, spin up a cluster on <a href="https://info.elastic.co/elasticsearch-service-trial-30d.html">Elasticsearch Service</a> or <a href="/downloads/">install the latest version</a> of the Elastic Stack. Already have Elasticsearch running? Just upgrade your clusters to 7.10 and give it a try. If you want to know more you can read the <a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.10/data-tiers.html">data tiers</a> and <a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.x/searchable-snapshots-apis.html">searchable snapshots</a> documentation.
</p>

blog-banner-generic-blue.png

blog-thumb-generic-blue.png

Introducing Elasticsearch searchable snapshots

Elasticsearch 7.10.0 is here!  Featuring searchable snapshots which is the beginning journey to searchable S3, stored field compression to save up to 10% on index size, Event Query Language for security use cases, and more.

<p>We're pleased to announce the release of Elasticsearch 7.10.0, based on Apache Lucene 8.7.0. Version 7.10 is the latest stable release of Elasticsearch and is now available for deployment via <a href="/elasticsearch/service">Elasticsearch Service</a> on <a href="/cloud">Elastic Cloud</a> or via <a href="/downloads/elasticsearch">download</a> for use in your own environment(s).
</p><p>If you're ready to roll up your sleeves and get started, we have the links you need:
</p><ul>
	<li><a href="/cloud/">Start Elasticsearch on Elastic Cloud</a></li>
	<li><a href="/downloads/elasticsearch">Download Elasticsearch</a></li>
	<li><a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.10/release-notes-7.10.0.html">Elasticsearch 7.10.0 release notes</a></li>
	<li><a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.10/breaking-changes-7.0.html">Elasticsearch 7.10.0 breaking changes</a></li>
</ul><p>With today's release, our <a href="/enterprise-search">Elastic Enterprise Search</a>, <a href="/observability">Elastic Observability</a>, and <a href="/security">Elastic Security</a> solutions also received significant updates. To learn more about these updates&nbsp;you might consider giving our main<a href="/blog/whats-new-elastic-7-10-0-searchable-snapshots-lens-user-experience-monitoring"> Elastic 7.10 release</a> blog a read.
</p><h2>Store more and spend less with searchable snapshots</h2><p>Data is growing at an exponential rate across many organizations. This is especially true for time series data like logs, metrics, traces, and security events used to observe and protect your systems. In time-series data, the most recent data ingested into Elasticsearch is what's valuable. This data drives alerting, machine learning detection, devops workflows, and monitoring security events. But keeping all of this data on high-performance instances can become very expensive if not economically feasible.
</p><p>To address this, we began looking at the lifecycle of data. Using features like <a href="/blog/elastic-stack-6-6-0-released">index lifecycle management</a> helped move data from high-performance, high-cost <a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.10/data-tiers.html">“hot” nodes to lower cost “warm” nodes</a> with less performant disks. But what if your organization asked you to keep years of data? Could you answer the question of how many unique visitors visited your site year over year on Cyber Monday? Or how many systems a user accessed over a 5 year period for a security forensic investigation? To keep this much data on warm nodes still requires a significant financial investment. This has prompted many organizations to store some data as&nbsp;<a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/snapshots-take-snapshot.html">snapshots</a>. This isn't a perfect solution, as you still need to take the time to restore the data from a snapshot whenever you need to search.
</p><p>Introducing... <a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.10/searchable-snapshots.html">searchable snapshots</a>, a new beta feature which allows you to directly search your snapshots without a restore, on low cost object stores such as AWS S3, Microsoft Azure Storage, or Google Cloud Storage without a significant impact to search performance. Balance the cost, performance and capabilities to meet your storage and search needs.&nbsp;
</p><p>
	<img class="vidyard-player-embed" src="https://play.vidyard.com/ZsDF2rsBhcof1LcdsmZBth.jpg" data-uuid="ZsDF2rsBhcof1LcdsmZBth" data-v="4" data-type="inline" data-autoplay="1" data-loop="1" data-disable_analytics="1" data-hidden_controls="1" data-muted="1" style="width: 100%; margin: auto; display: block;">
</p><p>Searchable snapshots power a new data tier called the&nbsp;<a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/data-tiers.html#cold-tier">cold tier</a>. The cold tier, also in beta, is designed to dramatically reduce storage costs for your read-only data by reducing your cluster storage by up to 50% without a significant impact to performance. It maintains the same level of reliability and redundancy as your hot and warm tiers, with full support for the automatic recovery you have come to expect from Elasticsearch. Are you craving more information? Check out this <a href="/blog/introducing-elasticsearch-searchable-snapshots">searchable snapshots introduction</a> blog for more information.
</p><h2>Bolstering Elasticsearch's security chops with EQL</h2><p>In 7.9, we <a href="/blog/whats-new-elasticsearch-7-9-0">announced</a> Event Query Language (EQL), a new experimental query language. <a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.x/eql-search-api.html">EQL</a>&nbsp;has been used for years within Endgame to help you get a holistic view of a system for threat investigation, identification, and prevention. These same unique capabilities used within the security space have now been brought to Elasticsearch, and in 7.10, EQL in Elasticsearch is now in beta for use cases such as observability and other time-series data.
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt7b3c6e098bd9c247/5fa9b95342256d5ffdf419bd/eql-final.gif" data-sys-asset-uid="blt7b3c6e098bd9c247" alt="eql-final.gif">
</p><p>A great way to understand EQL is to consider a home security analogy. Entering the house through any doorway to the home is not considered suspicious even if it's late at night. However, a person entering the house from the front door and from the back door at the same time raises questions because it would be impossible to be in two places at once. It may also be suspicious if someone enters the house after failing to use 90 different keys to open the front door in under a minute &lt;wink&gt;.
</p><p>EQL is designed to easily take an event (front door opening) and correlate other events or sequence of events (entering through the back door or window, forced entry, etc), to draw conclusions on the state of the system. These events can be correlated over a span of time to find new insights such as 90 previously failed attempts before gaining entry to the home. You can read an introduction to EQL&nbsp;<a href="/blog/introducing-event-query-language">here</a>.
</p><h2>Elasticsearch 7.10 will be smaller, in a big way</h2><p>Our initial benchmarks have reported space reductions of up to 10% using a new stored field compression! This is big news, especially for organizations paying for storing and maintaining petabytes of data. Indices created by our <a href="/observability">Elastic Observability</a> and <a href="/security">Elastic Security</a> solutions will see the greatest savings due to the repetitive nature of the data they typically hold. To learn more about stored field compression and how you can save up to 10% on index size, be on the look out for stored field compression blog overview being released shortly.</p><h2>Elasticsearch performance improvements</h2><p>Elastic has been on a mission to continually improve search aggregation performance and memory efficiencies. In <a href="/blog/elasticsearch-7-8-0-released">7.8</a>, we reduced aggregation memory consumption by maintaining serialized results, and in <a href="/blog/whats-new-elasticsearch-7-9-0">7.9</a> we increased the <a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/search-settings.html#search-settings-max-buckets">search.max_buckets</a> limit to 65,535. The Elasticsearch team has continued this work in 7.10, specifically targeting the coordinator node and the request-level circuit breaker to improve performance and memory tracking of <a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.10/search-aggregations-metrics-cardinality-aggregation.html">cardinality</a> and <a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.10/search-aggregations-bucket.html">bucket aggregation</a>. <a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.10/search-aggregations-bucket-datehistogram-aggregation.html">Date histogram aggregation</a> performance has also been improved by 50% by precomputing date ranges.
</p><h2>Elasticsearch functional and usability enhancements&nbsp;</h2><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt94e1cb58b5fbb532/5fa9b9ef42256d5ffdf419c9/quote-heraclitus-no-person-ever-steps-in-the-same-river-twice.png" data-sys-asset-uid="blt94e1cb58b5fbb532" alt="quote-heraclitus-no-person-ever-steps-in-the-same-river-twice.png">
</p><h3>Point in time reader</h3><p>No person ever steps in the same river twice, since it's not the same river and it's not the same person... unless you have <a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.10/point-in-time-api.html">point in time reader</a>. When querying an index in Elasticsearch, you are essentially searching for data at a given point of time. If your query returns the top 10% results, how do you query the other 90%? With an index that is constantly changing as in most observability and security use cases, sending another query will return a different result because the index or data has already changed. Point in time reader gives you the ability to repeatedly query an index at the state it was at at a given point in time. The point in time reader already serves the EQL query language, and we expect to use it for many other use cases in the future.<br>
</p><h3>Case insensitivity in wildcard field type</h3><p>In Elasticsearch 7.9 we introduced the new&nbsp;<a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.10/keyword.html#wildcard-field-type">wildcard field type</a>. Before the introduction of this new field type, using wildcards within your query was resource intensive and typically resulted in slower than expected search times despite the learned human behavior of how we search on web browsers. The wildcard field type provides additional flexibility and an easy way to assemble queries. In 7.10,&nbsp; support for case insensitivity queries have been added. This enables case insensitivity by default for term-level queries (such as term, terms, prefix, wildcard and regexp), simply by setting the optional case_insensitive flag to true. This should greatly benefit security and observability use cases.
</p><h3>Unsigned 64 bits integer</h3><p>The time for <a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.10/number.html#number">64 bit integers</a> is now! Elasticsearch now supports unsigned 64 bit integers. This new numeric type supports very large positive integers from 0 to 264-1. This is particularly useful for system-generated data, such as counters from routers or Windows registry events. Note that aggregations will still work on the nearest double. This is great news if you work with finance, security and network performance data.
</p><h3>Version data type</h3><p>How can you search across software versions where the numeric value is semantic? <a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/version.html">Version datatype</a> is a specialization of the keyword field to handle software version values and to support specialized precedence rules for them based on semantic versioning. For example, major, minor, and patch versions are sorted numerically (“2.1.0” &lt; “2.4.1” &lt; “2.11.2”), and pre-release versions are sorted before releases (“1.0.0-alpha &lt; “1.0.0”).
</p><h3>New aggregations</h3><p>In addition to the aggregations we added in <a href="/blog/elasticsearch-7-8-0-released">7.8</a>, we are introducing two new aggregations! Histograms: <a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/search-aggregations-metrics-max-aggregation.html#search-aggregations-metrics-max-aggregation-histogram-fields">min/max aggregations on histogram fields</a>, and hard bounds for histogram aggregations. The histogram datatype is useful for handling high volume numeric data, which is frequently aggregated where it is produced, allowing for a more space-efficient Elasticsearch index. For example, Elastic APM could roll up histogram data or sum it up in one structure to reduce the amount of data being sent from the APM agent into Elasticsearch. Being able to aggregate on the histogram enables supports new scenarios.
</p><p>The 2nd aggregation is <a href="https://www.elastic.co/guide/en/elasticsearch///reference/master/search-aggregations-metrics-rate-aggregation.html">rate metrics aggregation</a>, which is used inside a date_histogram and calculates the rate of occurrences of a specified field within a bucket of a date_histogram aggregation. Previously, it was harder to calculate the rate, but since rate is a basic piece of information when analyzing time series data, we thought it would be valuable to make it easier. This is one of many such adaptations we are making to verify that it is easy and intuitive to use the Elasticsearch generic search and analytics engine on time series data.
</p><h3>New ingest node pipeline UI</h3><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltc1155c42dc8e2f74/5fa9ba656f82405d9a4aaa81/ingest_node_pipelines_demo.gif" data-sys-asset-uid="bltc1155c42dc8e2f74" alt="ingest_node_pipelines_demo.gif">
</p><p>It is easier to debug your ingest flow with the new ingest node pipeline UI. Added visual cues and pipeline tests allow you to easily step through the execution flow. Viewing error messages from the output can help you identify what actions are needed to ensure your documents will work properly with your ingest processors.&nbsp;
</p><h2>Machine Learning</h2><h3>AUC ROC metric for evaluating your classification machine learning models</h3><p>We have added area under the curve of receiver operating characteristic (AUC ROC) as an evaluation metric for classification analysis. This is a common evaluation metric to know how well your models perform.
</p><p><br>
</p><h3>Custom feature processor in data frame analytics</h3><p>New field in data frame analytics allows you to supply your own feature transformations and processors that are applied before training, which are applied automatically at inference time. This allows you to do a last step feature transformation for any data row before giving it to analytics.
</p><h2>That's All Folks…</h2><p>7.10 is a huge release for Elasticsearch and we couldn't cover all of it within this blog. Be sure to check out more by reading the <a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.10/release-highlights.html">release highlights</a>.
</p><p>Ready to get your hands dirty? Spin up a 14-day free trial of <a href="/cloud/">Elastic Cloud</a> or <a href="/downloads/elasticsearch">download Elasticsearch</a> today. Try it out, and be sure to let us know what you think on Twitter (<a href="https://twitter.com/elastic">@elastic</a>) or in <a href="https://discuss.elastic.co/c/elasticsearch">our forum</a>.<br>
</p>

Articles by George Kobar

Introducing Elasticsearch searchable snapshots

Elasticsearch 7.10.0 released

Products & Solutions

Company

Resources

Featured topics

News

Articles by George Kobar

Introducing Elasticsearch searchable snapshots

Elasticsearch 7.10.0 released