Read about the updates and bug fixes that have been included in this release.

blog-banner-release-patch.png

blog-thumb-release-patch.png

Elastic Stack 7.13.4 released

elasticsearch-weekly-blog-banner.png

elasticsearch-weekly-blog-thumb.png

This Week in Elasticsearch - 2020-02-28

This is the final post in a three-part series about Instant Aggregations. Read how it all started in <a href="https://www.elastic.co/blog/the-tale-of-caching-and-why-it-matters">The Tale of Caching and Why It Matters</a> from Simon Willnauer and Shay Banon and the meaty middle detailed in <a href="https://www.elastic.co/blog/the-great-query-refactoring-thou-shalt-only-parse-once"> </a><a href="https://www.elastic.co/blog/the-great-query-refactoring-thou-shalt-only-parse-once">The Great Query Refactoring: Thou Shalt Only Parse Once</a>. Enjoy the trilogy! In 1.4.0 Elasticsearch gained a shard level ‘Request Cache’ which caches the result of the query phase on each shard keyed on the search request itself. Until 5.0 this feature was disabled by default since it wasn’t as useful as it could be for most of the computationally heavy use cases. The cache was intended to make searches faster, especially for aggregations. One problem was that ordering in JSON is not deterministic so although two requests may be logically the same, when rendered to JSON strings they may not be equal. The other main problem is that these computationally heavy use cases tend to use time windows relative to the current time so subsequent requests will tend to have slightly different time ranges. Enabling it would likely be a waste memory for most of the users &nbsp;since they would rarely ever get a cache hit. So why would we add such a feature?Here at Elastics, we try to follow the rule of “progress over perfection”. Even if we can’t utilize it’s full potential we get a step closer to our goals. Now after 2 years of engineering effort and <a href="/blog/the-great-query-refactoring-thou-shalt-only-parse-once">refactoring the entire search request</a> representation, we can finally take full advantage of it.From 5.0 the request cache will be enabled by default for all requests with `size:0`. The request cache is most useful for analytics use cases and generally analytics use cases use search requests with `size: 0`.So how did the changes made since 1.4.0 enable us to better use this feature?The search request cache gives massive improvements in search performance when running the same search multiple times on a static index. However, search requests are rarely exactly the same, especially in the time series use case.Lets look at some of the characteristics of typical search for time-series use cases:<ul><li>Queries have a &nbsp;time range component often relative to current time (e.g. from now-7d to now)</li><li>Search requests span &nbsp;across multiple indices</li><li>Indexing happens on the latest index, all other indices are static</li><li>Same search requests are run multiple times with different time ranges</li></ul>The above are common characteristics of search requests for a lot of time series use cases including common patterns of usage for Kibana. A lot of Kibana dashboards contain quite a few visualisations a lot of which are complex and can take a number of seconds for the dashboard request to be executed by Elasticsearch. Because search requests are rarely the same, the search request cache can’t be used effectively to improve search performance for these use cases.Or can it?How can we make the search request cache work when the time range is always moving? Let’s solve this by considering an example. Imagine we have the details for every residential house sale in the UK since 1995. We can index this into 21 yearly indices (e.g. house-prices-1995, house-prices-1996, …, house-prices-2016). For the purposes of this explanation let’s make each index only have 1 shard (though the same idea can easily be extended to multiple shard indices without modification) Now we can run queries against the indices by using requests like this:<pre>``` GET house-prices-*/_search { "query": { "range": { "date": { "gte": "2013-09-01", "lt": "2016-03-01" } } } } ``` </pre>The figure below shows three of these such queries overlaid on the yearly indices. These queries are typical for dashboard style use cases in that they differ only by small amounts (imagine a refreshing dashboard)<img src="https://api.contentstack.io/v2/assets/57d6e0bf39cce73c4a091058/download?uid=blt1a2b92ef4097f1ff" height="325" width="850" style="width: 850px; height: 325px;"/>A couple of things stand out from this diagram:<ul><li>All three queries match no documents in house-prices-2012 (highlighted red on the diagram)</li><li>All three queries will match all documents in house-prices-2014 and house-prices-2015 (highlighted green on the diagram)</li></ul>So the only indices which affect the matching documents between the three queries are house-prices-2013 and house-prices-2016.If we could rewrite the queries on each shard based on the range of values present in that index we could make the queries able to actually utilize the request cache. Below is the diagram with the same three queries rewritten to make them more cachable in the search request cache:<img src="https://api.contentstack.io/v2/assets/57d6e1d039cce73c4a0910ad/download?uid=blte0f8b865a8d465c8" height="325" width="850" style="width: 850px; height: 325px;"/>You can see that in the diagram above, the first query is rewritten and run as a `match_none` query on the `house-prices-2012` indexes shard and a `match_all` query on the `house-prices-2014` and `house-prices-2015` indices shards. This means that when the second and third query is run it can use the cached results of the search on the `house-prices-2012`, `house-prices-2014` and `house-prices-2015` indices shards instead of actually running a search on those shards. So for the second and third queries we only need to actually search the shards on the `house-prices-2013` and `house-prices-2016` indices.Also, even for the first query, running a `match_none` query instead of a range query will be faster since it will not need to try to lookup the date range in the index.So how does this work in practice?This feature not only relies on the search request cache mentioned at the beginning of this post, but it is also heavily based on the query refactoring that we described in a recent <a href="/blog/the-great-query-refactoring-thou-shalt-only-parse-once">blog post</a>. The reason for this is that in order to add the rewrite logic described above we need objects that represent the query and the search request that we can actually rewrite.When the search request is received by the shard, we rewrite the entire request including `query` and `post_filter` QueryBuilder objects. Each type of query has it’s own implementation of QueryBuilder which will rewrite according to it’s own rules.Compound queries, queries that themselves contain queries (such as `bool` and `constant_score`) will call rewrite on the queries they wrap. Most leaf queries, queries that do not contain other queries, currently do not contain any rewrite logic so just return themselves (to indicate they did not change).The range query however, will check the minimum and maximum value of the field (we will call this the field range) and compare this to the range it contains. There are three cases that we care about when evaluating the rewrite for the range:<ul><li>The query range and the field range do not overlap at all - In this case we can rewrite this range as a `match_none` query so we return a `MatchNoneQueryBuilder`</li><li>The query range contains the entire field range - In this case all documents which contain a value for this field will match the range so we can rewrite the range query as an unbounded range query (not a match_all query) and return it</li><li>The query range partially overlaps the field range. There’s not much we can do to help in this case so we don’t rewrite and return the original range query.</li></ul>Now that the search request has been rewritten we can check the cache with the rewritten version and either retrieve the cached result or execute the search and add the result to the cache, keyed on the rewritten search request. This has a nice side effect since the rewritten queries are “normalized” search requests that are semantically equivalent but differ in the order of keys in the json will now also produce cache hits.Why not use `match_all` ?In the case that the query range contains the entire field range you might think we could rewrite the `range` query as a `match_all` query. We can’t do this because we can’t assume that all documents have a value for the field. If we rewrite to a `match_all` query we would incorrectly match documents that have no value for the field. For this reason we instead rewrite the range to an unbounded range query (effectively [* TO *]) which still means the query is much more useful to the search request cache.Is this all worth the trouble?To answer this question we’ll go back to our yearly house price indices. This dataset contains 21 yearly indices containing 21,304,688 residential UK house sales from 1995 to 2016. I ran this fairly unscientific test on my Macbook Pro. Each index has a single shard. I created a Kibana dashboard showing 14 different visualisations relevant to the data mixing simple and complex visualisations. The top of the dashboard looks like the following:<img src="https://api.contentstack.io/v2/assets/57e02db9acc34b3254b8af0b/download?uid=bltf740e6e1aec8ca2b" height="469" width="850" style="width: 850px; height: 469px;"/>With the request cache disabled, requests to elasticsearch for the dashboard to refresh takes 12s-14s. When the request cache is enabled this drops to ~100ms. The same request is now 100x faster!But this is on completely static data so what happens when we are indexing data?To test this I deleted the data from 2010 to 2016 and loaded it in date order whilst refreshing the dashboard:<img src="https://api.contentstack.io/v2/assets/57d6e20f39cce73c4a0910cb/download?uid=blt7d49d71a4510bee5" height="502" width="850" style="width: 850px; height: 502px;"/>Now the request to Elasticsearch for the dashboard refresh takes 60-200ms. So the query is still at least 50x faster than our original un-cached query! The refresh time varies depending on how much data is present in the changing index since the search on the latest index does not hit the cache. This is because as new data is indexed, the cache on the shards of the latest index is constantly being invalidated.The Instant Aggregations feature enables much better caching of search requests by rewriting the query based on the data present on the shard. As of 5.0.0 the query is only rewritten for date range queries, but with this infrastructure in place it opens the door to the potential of rewriting other types of query to improve the request cache utilization. We even have the potential to rewrite aggregations to make them more cacheable! We have shown in this post that the potential performance improvements when we use this technique can be huge, so watch this space for more improvements in the future.

instant-aggregations-elasticsearch-colin-goodheart-smithe-request-cache-full-bleed.jpg

instant-aggregations-elasticsearch-rewriting-queries-thumbnail.jpeg

Instant Aggregations: Rewriting Queries for Fun and Profit

<html><head></head><body>
	One of the most visible features coming in 2.0 are the Pipeline Aggregations. This is an extension of the current Aggregations framework, to allow additional computations to be performed on top of the results of aggregations. This allows users to ask questions such as &#x201C;What is the maximum average monthly price?&#x201D; from a date histogram and &#x201C;How many new users are signing up each day?&#x201D; from a date histogram showing total user count each day.

	Internally these aggregation are run after the other aggregations have completed on the coordinating node. This means Pipeline Aggregators are able to use the final results of their sibling aggregations but are not able to go back to the shards to query the index. The first of these new types are:
<ul>
	<li><a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/search-aggregations-pipeline-derivative-aggregation.html">Derivative Aggregation</a></li>
	<li><a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/search-aggregations-pipeline-max-bucket-aggregation.html">Max Bucket Aggregation</a></li>
	<li><a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/search-aggregations-pipeline-min-bucket-aggregation.html">Min Bucket Aggregation</a></li>
	<li><a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/search-aggregations-pipeline-avg-bucket-aggregation.html">Average Bucket Aggregation</a></li>
	<li><a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/search-aggregations-pipeline-sum-bucket-aggregation.html">Sum Bucket Aggregation</a></li>
	<li><a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/search-aggregations-pipeline-bucket-script-aggregation.html">Bucket Script Aggregation</a></li>
	<li><a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/search-aggregations-pipeline-cumulative-sum-aggregation.html">Cumulative Sum Aggregation</a></li>
	<li><a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/search-aggregations-pipeline-movavg-aggregation.html">Moving Average Aggregation</a></li>
</ul>
	In this post I will show some of these new aggregations in action. To help demonstrate, I have downloaded spacecraft trajectory data from <a href="http://omniweb.gsfc.nasa.gov/coho/helios/heli.html" target="_blank">NASA&#x2019;s Helioweb site</a> for the Voyager 1 and Voyager 2 spacecraft. Each document in my index represents the <a href="https://en.wikipedia.org/wiki/Ecliptic_coordinate_system" target="_blank">Solar Ecliptic</a> position of one of the spacecraft on a particular day. The data spans from the launch of the Voyager missions in September 1977 to the present day and also includes projected trajectories up to 2020. Below is an example of a document in Elasticsearch:
<pre class="prettyprint">{
 &quot;_index&quot;: &quot;helioweb&quot;,
 &quot;_type&quot;: &quot;voyager1&quot;,
 &quot;_id&quot;: &quot;1977-257&quot;,
 &quot;_score&quot;: 1,
 &quot;_source&quot;: {
 &quot;seLon&quot;: 353.8,
 &quot;objectName&quot;: &quot;voyager1&quot;,
 &quot;seLat&quot;: 0.2,
 &quot;year&quot;: 1977,
 &quot;date&quot;: &quot;1977-09-14T10:28:25.178Z&quot;,
 &quot;radAU&quot;: 1.02,
 &quot;dayOfYear&quot;: 257
 }
}
</pre>
	<code>seLat</code> and
	<code>seLon</code> are the latitude and longitude of the object in the 
	<a href="https://en.wikipedia.org/wiki/Ecliptic_coordinate_system" target="_blank">Solar Ecliptic Coordinate System</a> respectively, and
	<code>radAU</code>
	is the radial distance of the object from the Sun measured in <a href="https://en.wikipedia.org/wiki/Astronomical_unit" target="_blank">Astronomical Units</a>. In this post we will mainly be concentrating on the <code>date</code>,
	<code>objectName</code>, and 
	<code>radAU</code> fields.

	So first let&#x2019;s plot the average radial distance of Voyager 1 over time. This can be done with the existing aggregations by defining the following aggregations:
<pre class="prettyprint">{
 ...
 &quot;aggs&quot;: {
 &quot;histo&quot;: {
 &quot;date_histogram&quot;: {
 &quot;field&quot;: &quot;date&quot;,
 &quot;interval&quot;: &quot;month&quot;
 },
 &quot;aggs&quot;: {
 &quot;avg_distance&quot;: {
 &quot;avg&quot;: {
 &quot;field&quot;: &quot;radAU&quot;
 }
 }
 }
 }
 }
}
</pre>
	The graph we get from the results looks pretty uninteresting:
<img class="img-responsive" src="https://api.contentstack.io/v2/assets/575e4c83d8edd48f76935bf6/download?uid=blt5913aeb0da25eab5" data-sys-asset-uid="blt5913aeb0da25eab5" alt="voyager-1-radial-distance.png">

	Basically all we can find out from this is that since launch Voyager 1 has been travelling further and further away from the Sun. Not exactly surprising for a long distance space probe!

	But what does Voyager 1&#x2019;s radial speed over time look like? This isn&#x2019;t something you can currently do in Elasticsearch. The indexed documents only contain the radial distance of Voyager 1 so its speed cannot be plotted directly. With the new Derivative Aggregation we can take the derivative of that distance to calculate the radial speed each month:
<pre class="prettyprint">{
 ...
 &quot;aggs&quot;: {
 &quot;histo&quot;: {
 &quot;date_histogram&quot;: {
 &quot;field&quot;: &quot;date&quot;,
 &quot;interval&quot;: &quot;month&quot;
 },
 &quot;aggs&quot;: {
 &quot;avg_distance&quot;: {
 &quot;avg&quot;: {
 &quot;field&quot;: &quot;radAU&quot;
 }
 },
 &quot;speed&quot;: {
 &quot;derivative&quot;: {
 &quot;buckets_path&quot;: &quot;avg_distance&quot;
 }
 }
 }
 }
 }
}
</pre>
	Pipeline aggregations look very similar to the other aggregations in the request, but instead of having a <code>field</code> parameter to reference which 
	<code>field</code> in the document they will work on, they have a 
	<a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/search-aggregations-pipeline.html#bucket-path-syntax">
	<code>bucket_path</code>
	parameter</a> which references which aggregation to use in their calculation. The resulting aggregation tree for the above request looks like this:
<pre class="prettyprint">{
 ...
 &quot;aggregations&quot;: {
 &quot;histo&quot;: {
 &quot;buckets&quot;: [
 {
 &quot;key_as_string&quot;: &quot;1977-09-01T00:00:00.000Z&quot;,
 &quot;key&quot;: 241920000000,
 &quot;doc_count&quot;: 25,
 &quot;avg_distance&quot;: {
 &quot;value&quot;: 1.0328
 }
 },
 {
 &quot;key_as_string&quot;: &quot;1977-10-01T00:00:00.000Z&quot;,
 &quot;key&quot;: 244512000000,
 &quot;doc_count&quot;: 31,
 &quot;avg_distance&quot;: {
 &quot;value&quot;: 1.1867741935483873
 },
 &quot;speed&quot;: {
 &quot;value&quot;: 0.15397419354838737
 }
 },
 &#x2026;
 ]
 }
 }
}
</pre>
	You can see that the Derivative Aggregation has added a new value <code>speed</code> to the all but the first bucket. The first bucket is left empty as we require two values to compute the derivative, the current value and the previous value. Since there is no previous value for the first bucket, we can&#x2019;t compute a derivative for it.

	Plotting the speed against time gives us a much more interesting graph:
<img class="img-responsive" src="https://api.contentstack.io/v2/assets/575e4c840342dfd738262f75/download?uid=blted382364b4175616" data-sys-asset-uid="blted382364b4175616" alt="voyager-1-radial-speed.png">

	Here we can see that Voyager 1&#x2019;s radial speed dropped significantly twice, once around 1979 and once around 1981. Looking at the <a href="http://voyager.jpl.nasa.gov/mission/timeline.html" target="_blank">timeline for the Voyager mission</a> we can see that these points coincide with the closest approach of Voyager 1 with Jupiter and Saturn.

	We can actually use the Min Bucket Aggregation to determine which month Voyager 1 was travelling at its slowest radial speed using the following:
<pre class="prettyprint">{
 ...
 &quot;aggs&quot;: {
 &quot;histo&quot;: {
 &quot;date_histogram&quot;: {
 &quot;field&quot;: &quot;date&quot;,
 &quot;interval&quot;: &quot;month&quot;
 },
 &quot;aggs&quot;: {
 &quot;avg_distance&quot;: {
 &quot;avg&quot;: {
 &quot;field&quot;: &quot;radAU&quot;
 }
 },
 &quot;speed&quot;: {
 &quot;derivative&quot;: {
 &quot;buckets_path&quot;: &quot;avg_distance&quot;
 }
 }
 }
 },
 &quot;min-speed&quot;: {
 &quot;min_bucket&quot;: {
 &quot;buckets_path&quot;: &quot;histo &gt; speed&quot;
 }
 }
 }
}
</pre>
	Which returns a new aggregation alongside the histogram showing the minimum value for the slowest radial speed and the bucket keys of the bucket which have this minimum value:
<pre class="prettyprint">{
 ...
 &quot;aggregations&quot;: {
 &quot;histo&quot;: {
 &quot;buckets&quot;: [
 ...
 ]
 },
 &quot;min-speed&quot;: {
 &quot;value&quot;: 0.10212903225806436,
 &quot;keys&quot;: [
 &quot;1979-04-01T00:00:00.000Z&quot;
 ]
 }
 }
}
</pre>
	So the slowest radial speed was in April 1979 which matches the Voyager timeline as the closest approach to Jupiter was during March 1979. Previously this would have required the client application to parse all the buckets, keeping track of the minimum value.

	We can show the radial speed of both Voyager 1 and Voyager 2 in the same response by using the filter aggregation to show the average radial distance of Voyager 1 and Voyager 2 and then use two derivative aggregations, one referencing the Voyager 1 distance and the other referencing the Voyager 2 distance:
<pre class="prettyprint">{
 &quot;aggs&quot;: {
 &quot;histo&quot;: {
 &quot;date_histogram&quot;: {
 &quot;field&quot;: &quot;date&quot;,
 &quot;interval&quot;: &quot;month&quot;
 },
 &quot;aggs&quot;: {
 &quot;voyager_1&quot;: {
 &quot;filter&quot;: {
 &quot;term&quot;: {
 &quot;objectName&quot;: &quot;voyager1&quot;
 }
 },
 &quot;aggs&quot;: {
 &quot;avg_distance&quot;: {
 &quot;avg&quot;: {
 &quot;field&quot;: &quot;radAU&quot;
 }
 }
 }
 },
 &quot;voyager_2&quot;: {
 &quot;filter&quot;: {
 &quot;term&quot;: {
 &quot;objectName&quot;: &quot;voyager2&quot;
 }
 },
 &quot;aggs&quot;: {
 &quot;avg_distance&quot;: {
 &quot;avg&quot;: {
 &quot;field&quot;: &quot;radAU&quot;
 }
 }
 }
 },
 &quot;voyager_1_speed&quot;: {
 &quot;derivative&quot;: {
 &quot;buckets_path&quot;: &quot;voyager_1&gt;avg_distance&quot;
 }
 },
 &quot;voyager_2_speed&quot;: {
 &quot;derivative&quot;: {
 &quot;buckets_path&quot;: &quot;voyager_2&gt;avg_distance&quot;
 }
 }
 }
 }
 }
}
</pre>
	Now, the <code>buckets_path</code> references the 
	<code>avg_distance</code>
	metric inside each of the filter aggregations using <a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/search-aggregations-pipeline.html#bucket-path-syntax">the 
	<code>buckets_path</code>
	syntax</a>. We can now plot the radial speed of Voyager 1 (blue line) and Voyager 2 (red line):
<img class="img-responsive" src="https://api.contentstack.io/v2/assets/575e4c840342dfd738262f6d/download?uid=bltd0cbe9bc1e7ab546" data-sys-asset-uid="bltd0cbe9bc1e7ab546" alt="voyager-1-and-2-radial-speed.png">

	Again from looking at the <a href="http://voyager.jpl.nasa.gov/mission/timeline.html" target="_blank">timeline for the Voyager mission</a> we can see that the drops in radial speed of Voyager 2 coincide with its closest encounters with Jupiter, Saturn, Uranus and Neptune.

	Since pipeline aggregations happen right at the end of the aggregation phase, they can be chained together (hence the name pipeline). So to calculate the radial acceleration of the Voyager 1 spacecraft we can just calculate the derivative of the speed (which we calculated in the previous pipeline aggregation) by adding the following aggregation to the request:
<pre class="prettyprint">{
 ...
 &quot;voyager_1_acceleration&quot;: {
 &quot;derivative&quot;: {
 &quot;buckets_path&quot;: &quot;voyager_1_speed&quot;
 }
 }
 &#x2026;
}
</pre>
	Here, instead of referencing a metric aggregation we are referencing the derivative aggregation <code>voyager_1_speed</code>. 
This will add an aggregation called 
	<code>voyager_1_acceleration</code> to the response for all but the first 2 buckets (since we need two values for
	<code>voyager_1_speed</code> to calculate the acceleration).

	These are just the first pipeline aggregations. We are currently working to add more pipeline aggregations to <a href="https://github.com/elastic/elasticsearch/issues/9876" target="_blank">this list</a> and there is a growing list of other ideas for possible pipeline aggregators including one that can be used to filter out buckets which do not meet a specified criteria (using this aggregation you could, for example, ask for only histogram buckets where the average speed is greater than a threshold value). We would also appreciate any feedback you have on the current pipeline aggregations and your suggestions for other pipeline aggregations that we could add in the future.

	Happy exploring!
</body></html>

Out of this world aggregations

Start free trial

Blog Footer CTA

Sign up for Elastic Cloud free trial

Senior Manager, Engineering

Colin Goodheart-Smithe

By submitting you acknowledge that you've read and agree to our <a href="/legal/elastic-cloud-account-terms" target="_self">Terms of Service</a>, and you agree to receive the <a href="/legal/privacy-statement#how-we-use-the-information" target="_self">selected communications</a> at the contact details you provided above. See <a href="/legal/privacy-statement/" target="_self">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.

Communication Preferences - ONLY for /communication-preferences

提交即表示您确认您已阅读并同意我们的<a href="/cn/legal/elastic-cloud-account-terms" target="_self">服务条款</a>，并且您同意通过您提供的上述联系方式接收<a href="/cn/legal/privacy-statement#how-we-use-the-information" target="_self">所选的通信</a>。如需了解更多信息，或想随时取消订阅，请参阅 <a href="/cn/legal/privacy-statement/" target="_self">Elastic 的隐私声明</a>。

By submitting you acknowledge that you've read and agree to our <a href="/legal/serverless-preview-terms" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.

Serverless GDPR Text

提交即表示您确认您已阅读并同意我们的<a href="/cn/legal/serverless-preview-terms" target="_self">服务条款</a>，并且 Elastic 可以使用您提供的上述详细信息与您联系，以向您介绍我们相关的<a href="/cn/legal/privacy-statement#how-we-use-the-information" target="_self">产品和服务</a>。如需了解更多信息，或想随时取消订阅，请参阅 <a href="/cn/legal/privacy-statement/" target="_self">Elastic 的隐私声明</a>。

By submitting you agree to <a href="/agreements/global/cloud-services-monthly" rel="nofollow">Elastic Cloud Terms of Service</a>. Your personal data will be processed in accordance with <a href="/legal/privacy-statement">Elastic's Privacy Statement</a>.

Cloud Trial GDPR Text

提交即表示您同意 <a href="/cn/agreements/global/cloud-services-monthly" rel="nofollow">Elastic Cloud 服务条款</a>。我们将会按照 <a href="/cn/legal/privacy-statement">Elastic 的隐私声明</a>处理您的个人数据。

By submitting you acknowledge that you've read and agree to our <a href="/legal/terms-of-use" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.

Newsletter GDPR Text

提交即表示您确认您已阅读并同意我们的<a href="/cn/legal/terms-of-use" target="_self">服务条款</a>，并且 Elastic 可以使用您提供的上述详细信息与您联系，以向您介绍我们相关的<a href="/cn/legal/privacy-statement#how-we-use-the-information" target="_self">产品和服务</a>。如需了解更多信息，或想随时取消订阅，请参阅 <a href="/cn/legal/privacy-statement/" target="_self">Elastic 的隐私声明</a>。

Explore similar demos

Overview

Speakers

Close

See more insights

The content on this page is not available in the selected language. As Elastic grows globally, we continue to support content in multiple languages.

The content on this page is not available in the selected language.

本页内容尚不支持所选语言。Elastic 正在不断努力，以实现对多种语言内容的支持。感谢您在此期间给予的耐心与陪伴！

Author

Articles by

Learn more

Watch now (no PT)

Watch now

See all top stories

All (no PT translation)

Contact information

Press Release

Share on Reddit

Share this story

Share by Email

Thank you for your interest!

Contact Info

Follow us on Youtube

Load More

Share on LinkedIn

Follow us on LinkedIn

Search Integrations

All Solutions

Video for

Follow us on Twitter

See when this webinar starts in my time zone

查看本次网络研讨会在我的时区的开始时间

Register to Watch

Register now

See All Posts

Can't make it? Register and we'll send you the recording. You'll also receive an email with related content

无法实时参加？注册后我们会给您发送录像。您还将收到相关内容的电子邮件。

Author

Articles by Colin Goodheart-Smithe

Senior Manager, Engineering, Elastic

Elastic Stack 7.13.4 released

This Week in Elasticsearch - 2020-02-28

Instant Aggregations: Rewriting Queries for Fun and Profit

Out of this world aggregations