Our hosted Elasticsearch and Kibana offering is moving from forum-based support to ticket-based support backed by Elastic engineers.

<table style="background: #FFFFD2;">
<tbody>
<tr>
<td>Wow, 2017 was a long time ago and a lot has changed since then! Check out our <a href="/support/welcome/cloud">Working with Elastic Cloud Support: Best Practices</a> FAQ for the latest and most accurate&nbsp;information about Elastic Cloud Support.</td>
</tr>
</tbody>
</table>Starting May 1, 2017, we will be moving support for our <a href="/cloud/as-a-service/subscriptions">Elastic Cloud Standard</a> customers from the public Discuss forum to a ticket-based system backed by a team of dedicated Elastic Cloud engineers.
Before diving into the details, we’d like to thank all our customers for helping us evolve and enhance our Elastic Cloud service with your feedback. Everything we do, we do for you.
When we launched Elastic Cloud in July 2015, we decided to offer support for Standard via an open forum. Our experience in community building is deep, but we knew that offering a forum around a service like Elastic Cloud would be a learning opportunity. And we learned a lot!
As we worked with you, we learned about the kind of help you needed, the size and shape of your questions and concerns, and ultimately how you wished to be treated. You spoke. We listened. We thank you for your feedback.
We feel this move from open forum support to a ticket-based system is the best path forward toward providing the quality of services our growing customer base deserves.
Here’s why we chose to move to a private system:
<dl>
	<dt>1. Ease of use</dt>
	<dd>While we have a portal you can log into, with the new system, help from a dedicated team of engineers is just an email away.</dd>
	<dt>2. An easier, safer way to share your information with us</dt>
	<dd>In the public forum, if we needed sensitive information, we had to go private anyway, via private messages. Now, there's no interruption in workflow - all communications are private from the start.</dd>
	<dt>3. Consistency</dt>
	<dd>At Elastic, we want to provide only the best products and services. The private system will allow for the consistent, one-on-one attention that you deserve.</dd>
	<dt>4. History</dt>
	<dd>While we had archived threads in the forum, finding or following the history of a single customer was difficult. Now, we can see previous cases opened by a customer, which helps lend context to new cases. We can see where we've been before, which will help as we choose where we need to go next when troubleshooting an issue, which makes for a better experience for everyone.</dd>
</dl>Here’s how it will work: On Monday, May 1, 2017, emails will go out with support portal login instructions to all current Elastic Cloud standard customers with active clusters. This will allow you to log into the support portal, where you can see and track both current and archived cases. If you had a cluster with us before, don’t worry - if you decide to give us a try again, your accounts will be provisioned as soon as you start up a new cluster. But if you have questions in the meantime, you can always <a href="https://www.elastic.co/contact">reach out to us</a>.
Every day is humbling at Elastic, as our assumptions are challenged and replaced with new information. And working with you makes all the difference.
PS! On the note of listening to our customer base, we’ve just launched <a href="https://aws.amazon.com/marketplace/pp/B01N6YCISK">Elastic Cloud on the AWS SaaS Marketplace</a>. This means you can pay for Elastic Cloud through AWS, so <a href="/cloud/as-a-service/signup">give us a try today.</a>

blog-cloud-standard-fb.jpg

blog-cloud-standard-thumb.jpg

Announcing Support for Elastic Cloud Standard, Our Hosted Elasticsearch Offering

This article outlines several approaches to migrate to Elastic's very own Elastic Cloud.

Whether you’re trying to reduce operational costs, maintain uptime or generally simplify things, consider <a href="https://www.elastic.co/cloud">Elastic Cloud</a>, Elastic’s very own hosted Elasticsearch and Kibana offering. Elastic Cloud offers ease-of-use and provides the latest Elasticsearch and Kibana releases, version 5.1 at the time this was written, with the newest features, enhancements and performance improvements. Also included are X-Pack features, such as security, monitoring, alerting & notification, Graph, and reporting. Elastic Cloud is backed by Elastic’s excellent support team and by the engineers who develop Elasticsearch and Kibana. Interested in trying out Elastic Cloud? Let us show you how you can migrate your data to our hosted offering, regardless of whether you currently self-host Elasticsearch on your own metal, run Elasticsearch in some other cloud offering, such as EC2, or use one of the many Elasticsearch hosting services that exist, such as the Amazon Elasticsearch Service.
<h2>Migration Approaches</h2>If you have existing Elasticsearch indexes and are considering migrating to Elastic Cloud, there are a few approaches to consider. Regardless of the approach, keep in mind that you first have to configure your Elastic Cloud target cluster. Creating a new cluster is very easy, but cluster settings like scripts and index settings like custom analyzers and mappings aren’t automatically copied over and must be configured prior to migrating index data.
<h3>Feed From The Source</h3>If you have a copy of the original data some place other than your Elasticsearch cluster, then it might be simplest to load from there. Create an Elastic Cloud cluster, configure it, and feed away. Ingesting into an Elastic Cloud cluster is no different than feeding a cluster running on your own servers. You can use <a href="https://www.elastic.co/products/logstash">Logstash</a>, <a href="https://www.elastic.co/products/beats">Beats</a>, the <a href="https://www.elastic.co/guide/en/elasticsearch/client/index.html">Elasticsearch Clients</a> or any other means at your disposal.
If the original source isn’t available, is cumbersome to access, has changed, or is no longer up to date, then two other migration approaches are available: reindexing from remote or snapshotting and restoring.
<h3>Reindex From A Remote Cluster</h3>Elasticsearch 5.x provides the ability to index from a remote cluster with the <a href="https://www.elastic.co/guide/en/elasticsearch/reference/5.0/docs-reindex.html#reindex-from-remote">reindex API</a>. With reindexing, it’s possible to spin up a cluster in Elastic Cloud and index data from an existing remote cluster. First create the destination index on the cluster in Elastic Cloud and then use reindex with the `remote` option to pull data from your old cluster and index it into the current cluster, taking advantage of the latest <a href="https://www.elastic.co/blog/elasticsearch-5-0-0-released#data-structures">data structures</a>, <a href="https://www.elastic.co/blog/elasticsearch-5-0-0-released#resiliency">resiliency</a> and <a href="https://www.elastic.co/blog/elasticsearch-5-0-0-released#indexing">indexing performance</a> Elasticsearch 5.1 improvements.
Reindexing effectively rebuilds the index from scratch so it is more expensive to run than _snapshot, which simply copies complete indexes. The tradeoff is that restored indexes can't take advantage of those nice data structures because they are not rebuilt.
<h3>Restore Snapshots From S3</h3>It’s also possible to <a href="https://www.elastic.co/guide/en/cloud/current/snapshot-restore.html">restore Elasticsearch snapshots sitting in S3 buckets</a>. With this approach, snapshot to an S3 bucket from an existing Elasticsearch cluster, spin up an Elasticsearch cluster in Elastic Cloud, and then restore the snapshot from S3 into Elastic Cloud.
Bear in mind that you’re not limited to restoring snapshots from S3 buckets. Snapshots that exist on any addressable external storage can be restored into Elastic Cloud.
<h2>How to Reindex from Remote</h2><h3>Reindex from Elasticsearch on EC2 into Elastic Cloud</h3>Log into <a href="https://www.elastic.co/cloud">Elastic Cloud</a> and create a new cluster, minimally the same size as your Elasticsearch on EC2 cluster or larger if you anticipate growth. Be sure to enable Kibana so you have access to the console.
From your Elastic Cloud cluster, you can issue the reindex command to index data stored remotely in Elasticsearch on EC2. The reindex command requires access to port 9200 or 9243, so you should <a href="http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/authorizing-access-to-an-instance.html">update the Security Group</a> associated with the EC2 Elasticsearch cluster and add an inbound custom TCP entry for port 9200 or 9243, allowing access to the Elastic Cloud clusters.
Issue the reindex command:
<pre class="prettyprint">POST reindex
{
 "source": {
 "remote": {
 "host": "http://[ec2 public hostname]:9200"
 },
 "index": "bank",
 "query": {
 "match_all": {}
 }
 },
 "dest": {
 "index": "bank"
 }
</pre>Verify that your documents were indexed:
<pre class="prettyprint">GET /bank/accounts/_search?pretty
</pre><h3>Reindex from the Amazon Elasticsearch Service into Elastic Cloud</h3>Presently, the most recent Elasticsearch version available on the Amazon Elasticsearch Service is 2.3, a major version behind the current Elasticsearch release. If you would like to take advantage of the most recent Elasticsearch 5.1 features, you can reindex directly into Elastic Cloud from the Amazon Elasticsearch Service.
The reindex command is the same used in the Elasticsearch on EC2 example, with one minor change. The Amazon Elasticsearch Service proxies requests to port 9200 or 9243, so it’s necessary to specify port 80 (HTTP) or port 443 (HTTPS) with the host. Not providing the port will result in an error.
<h3>HTTPS Example</h3><pre class="prettyprint">POST reindex
{
 "source": {
 "remote": {
 "host": "https://[aws es public hostname]:443"
 },
 "index": "bank",
 "query": {
 "match_all": {}
 }
 },
 "dest": {
 "index": "bank"
 }
}
</pre><h2>How to Restore Snapshots to An Elastic Cloud Cluster</h2>In this example, we’ll show you how to snapshot an index from EC2 into an S3 bucket and then restore the snapshot from the S3 bucket into an Elastic Cloud cluster. One thing to note is that S3 buckets shared between EC2 and Elastic Cloud clusters need to reside in the same region.
<h3>Step I - Snapshot from Elasticsearch on EC2 into S3</h3>First you’ll need to create an S3 bucket using AWS. In this example, we’ve created an S3 bucket using the name for the region "US Standard". “US Standard” is synonymous with “US-East”.
You’ll need to edit the bucket policy and should use these <a href="https://www.elastic.co/guide/en/elasticsearch/plugins/current/repository-s3-repository.html#repository-s3-permissions">recommended S3 permissions</a>:
<pre class="prettyprint">{
 "Id": "Policy1477318346906",
 "Version": "2012-10-17",
 "Statement": [
 {
 "Sid": "Stmt1477318310202",
 "Action": "s3:*",
 "Effect": "Allow",
 "Resource": "arn:aws:s3:::[bucket name]/*",
 "Principal": "*"
 }
 ]
}
</pre>Next, we’ll need to create a snapshot repository within the Elasticsearch cluster running on EC2:
<pre class="prettyprint">curl -XPUT 'localhost:9200/_snapshot/[repository name]?verify=false&pretty' -d'
{
 "type": "s3",
 "settings": {
 "access_key": "[access key]",
 "secret_key": "[secret key]",
 "bucket": "[bucket name]"
 }
}'
</pre>Now, let’s go ahead and snapshot the EC2 index into the repository:
<pre class="prettyprint">curl -XPUT 'localhost:9200/_snapshot/[repository name]/snapshot_1?pretty' -d'
{
 "indices": "*",
 "ignore_unavailable": true,
 "include_global_state": true
}'
</pre>Now, verify the index snapshot exists in S3 by going into the AWS S3 console and viewing the contents of the bucket.
<h3>Step II - Restore Snapshot from S3 into Elastic Cloud</h3>First, we’ll need to create the Snapshot Repository for the Elasticsearch cluster running in Elastic Cloud:
<pre class="prettyprint">curl -u "elastic:ViOpqfQUW2KeU5n5SF1qzW7g" -XPUT '[elastic cloud instance host]:9200/_snapshot/[repository name]?verify=false&pretty' -d'
{
 "type": "s3",
 "settings": {
 "access_key": "[access key]",
 "secret_key": "[secret key]",
 "bucket": "[bucket name]"
 }
}'
</pre>Next, we’ll restore the snapshot on S3 into Elastic Cloud. If an index already exists with the name of the index being restored into, delete the index before restoring the snapshot.
<pre class="prettyprint">curl -u "elastic:[user id]" -XDELETE '[elastic cloud instance host]:9200/bank’
</pre>Now, restore the snapshot:
<pre class="prettyprint">curl -u "elastic:[user id]" -POST '[elastic cloud instance host]:9200/_snapshot/[repository name]/snapshot_1/_restore?pretty' -d'
{
 "indices": "*",
 "ignore_unavailable": true,
 "include_global_state": true
}'
</pre>Finally, verify the index has been restored into Elastic Cloud by running a query:
<pre class="prettyprint">curl -u "elastic:[user id]" -GET '[elastic cloud instance host]:9200/bank/_search?pretty'
</pre>While it’s possible to restore a snapshot from 2.4.1 into 5.1, if there are any index features that changed or were breaking changes, the restore will fail. Also, if they have any indices created in 1.x, those can’t be restored into 5.1.
The safest approach is to restore into the same version, then upgrade to 5.1.
<h2>Summary</h2>Ready to give it a try? A <a href="https://www.elastic.co/elasticsearch/service">free 14 day trial</a> is available on us. No credit card required.
Ready to make the switch but not sure about pricing? Pricing is a snap with the <a href="https://www.elastic.co/cloud/as-a-service/pricing">pricing calculator</a>. Select cluster size, region and high availability preferences and the price is calculated instantly.

elastic-cloud-tutorial-full-bleed.jpg

elastic-cloud-thumb.jpg

Migrating to Elastic Cloud

<html><head></head><body>With <a href="https://www.elastic.co/v5">5.0</a> on the horizon, a number of query types deprecated in 2.x will be removed. Many of those are replaced by functionality of the bool query, so here&#x2019;s a quick guide on how to move away from <a href="https://www.elastic.co/guide/en/elasticsearch/reference/2.3/query-dsl-filtered-query.html">filtered queries</a>; <a href="https://www.elastic.co/guide/en/elasticsearch/reference/2.3/query-dsl-and-query.html">and</a>, <a href="https://www.elastic.co/guide/en/elasticsearch/reference/2.3/query-dsl-or-query.html">or</a>, <a href="https://www.elastic.co/guide/en/elasticsearch/reference/2.3/query-dsl-not-query.html">not</a> queries; and a general look into how to parse boolean logic with the bool query.
For the examples used in this article, let&apos;s assume this scenario: A school surveyed its students on their preferences for fruit snacks. Now you&apos;re putting together an application so administrators can view this data. Because of the many grades, categories, and other features of the data, you may find you have some arbitrarily complex boolean logic to deal with.
<h3>Matching Boolean Operations with the Bool Query Fields</h3>Let&apos;s get to the heart of these boolean operations and how they&apos;d look without the and, or, not queries. In the bool query, we have the following fields:
<ul>
	<li>must</li>
	<li>must_not</li>
	<li>should</li>
	<li>filter</li>
</ul>Must is analogous to the boolean AND, must_not is analogous to the boolean NOT, and should is roughly equivalent to the boolean OR. Note that should isn&apos;t exactly like a boolean OR, but we can use it to that effect. And we&#x2019;ll take a look at filter later on.
Boolean AND and NOT are easy, so let&apos;s look at those two first. If you want documents where preference_1 = Apples AND preference_2 = Bananas the bool query looks like this:
<pre class="prettyprint">{
 &quot;query&quot; : {
 &quot;bool&quot; : {
 &quot;must&quot;: [{
 &quot;match&quot;: {
 &quot;preference_1&quot;: &quot;Apples&quot;
 }
 }, {
 &quot;match&quot;: {
 &quot;preference_2&quot;: &quot;Bananas&quot;
 }
 }]
 }
 }
}
</pre>If you want documents where preference_1 != Apples:
<pre class="prettyprint">{
 &quot;query&quot; : {
 &quot;bool&quot; : {
 &quot;must_not&quot;: {
 &quot;match&quot;: {
 &quot;preference_1&quot;: &quot;Apples&quot;
 }
 }
 }
 }
}
</pre>But what about OR? That&apos;s where the should parameter comes in. If you want the set of documents where preference_1 = Apples OR preference_1 = Raspberries:
<pre class="prettyprint">{
 &quot;query&quot; : {
 &quot;bool&quot; : {
 &quot;should&quot;: [{
 &quot;match&quot;: {
 &quot;preference_1&quot;: &quot;Apples&quot;
 }
 }, {
 &quot;match&quot;: {
 &quot;preference_1&quot;: &quot;Raspberries&quot;
 }
 }]
 }
 }
}
</pre>So these, then, can all be combined into much more complex boolean logic, because we can easily nest bool queries. So let&apos;s look at this boolean logic: <code>(preference_1 = Apples AND preference_2=Bananas) OR (preference_1 = Apples AND preference_2 = Cherries) OR preference_1 = Grapefruits</code>
So in this case, you are searching for documents that match this set of rules, so documents where preference_1 is Apples and term 2 is either Bananas or Cherries, OR preference_1 is grapefruit, regardless of what term 2 equals.
That logic translates into a query that looks like this:
<pre class="prettyprint">{
 &quot;query&quot;: {
 &quot;bool&quot;: {
 &quot;should&quot;: [{
 &quot;bool&quot;: {
 &quot;must&quot;: [{
 &quot;match&quot;: {
 &quot;preference_1&quot;: &quot;Apples&quot;
 }
 }, {
 &quot;match&quot;: {
 &quot;preference_2&quot;: &quot;Bananas&quot;
 }
 }]
 }
 }, {
 &quot;bool&quot;: {
 &quot;must&quot;: [{
 &quot;match&quot;: {
 &quot;preference_1&quot;: &quot;Apples&quot;
 }
 }, {
 &quot;match&quot;: {
 &quot;preference_2&quot;: &quot;Cherries&quot;
 }
 }]
 }
 }, {
 &quot;match&quot;: {
 &quot;preference_1&quot;: &quot;Grapefruit&quot;
 }
 }]
 }
 }
}
</pre>To break this down a bit further:
Note that the whole of this query is wrapped in a should which satisfies the three OR clauses, and each individual piece is its own nested bool query.
So the <code>(preference_1 = Apples AND preference_2=Bananas)</code> piece is
<pre class="prettyprint">{
 &quot;bool&quot;: {
 &quot;must&quot;: [{
 &quot;match&quot;: {
 &quot;preference_1&quot;: &quot;Apples&quot;
 }
 }, {
 &quot;match&quot;: {
 &quot;preference_2&quot;: &quot;Bananas&quot;
 }
 }]
 }
}
</pre>And because this is all wrapped in a should, the next in the chain would be an OR
So the <code>preference_1 = Apples AND preference_2 = Cherries</code> piece would be another bool:
<pre class="prettyprint">{
 &quot;bool&quot;: {
 &quot;must&quot;: [{
 &quot;match&quot;: {
 &quot;preference_1&quot;: &quot;Apples&quot;
 }
 }, {
 &quot;match&quot;: {
 &quot;preference_2&quot;: &quot;Cherries&quot;
 }
 }]
 }
}
</pre>And then finally the single term:
<pre class="prettyprint">{
 &quot;match&quot;: {
 &quot;preference_1&quot;: &quot;Grapefruits&quot;
 }
}
</pre>The query can be arbitrarily complex, to fit your particular boolean requirement. Each piece can be broken down and turned into its elementary boolean expressions, then chained together as shown above, to make sure you&apos;re retrieving the right documents. It&#x2019;s also worth noting here that you can set <code>minimum_should_match</code> to a value you choose. This is the prime difference of the should function from the boolean OR. By default , <code>minimum_should_match</code> defaults to 1, but if you would like for more than one should clause to match for a document to be returned, you can increase this value.
<h3>Filtered Queries</h3>Because filtered queries have also been deprecated in 2.x, the new method is the <code>filter</code> field in the bool query. So let&apos;s take our boolean logic from before: <code>(preference_1 = Apples AND preference_2=Bananas) OR (preference_1 = Apples AND preference_2 = Cherries) OR preference_1 = Grapefruits</code>.
Let&#x2019;s say an administrator is focusing on grade 2, so they want to see only the results for that grade. It would just be a matter of adding a <code>filter</code> to the bool to get only those documents. If you are filtering documents, keep in mind that the relevance score for the returned results is only affected by the query, not by the filter, so it&#x2019;s possible that your relevance scoring may not be what you expect, since it&#x2019;s the query that sets the score, not the filter.
Here&#x2019;s what the filter looks like:
<pre class="prettyprint">&quot;filter&quot; : {
 &quot;term&quot;: {
 &quot;grade&quot;: &quot;2&quot;
 }
}
</pre>So the whole query looks like this:
<pre class="prettyprint">{
 &quot;query&quot;: {
 &quot;bool&quot;: {
 &quot;should&quot;: [{
 &quot;bool&quot;: {
 &quot;must&quot;: [{
 &quot;match&quot;: {
 &quot;preference_1&quot;: &quot;Apples&quot;
 }
 }, {
 &quot;match&quot;: {
 &quot;preference_2&quot;: &quot;Bananas&quot;
 }
 }]
 }
 }, {
 &quot;bool&quot;: {
 &quot;must&quot;: [{
 &quot;match&quot;: {
 &quot;preference_1&quot;: &quot;Apples&quot;
 }
 }, {
 &quot;match&quot;: {
 &quot;preference_2&quot;: &quot;Cherries&quot;
 }
 }] 
 }
 }, {
 &quot;match&quot;: {
 &quot;preference_1&quot;: &quot;Grapefruit&quot;
 }
 }],
 &quot;filter&quot; : {
 &quot;term&quot;: {
 &quot;grade&quot;: &quot;2&quot;
 }
 }
 }
 }
}
</pre>As you can see, the bool query is quite versatile, but sometimes parsing out the complex boolean operations into the bool query syntax can be a challenge. Hopefully, this has given you a better idea of how each of the bool query fields map to traditional boolean operators, and how you can chain those together for complex boolean logic for better search results.
Also, this hopefully has given you some ideas as you work to remove filtered and and, or, not queries using the bool query to make sure you are ready for 5.0 when it is released. As ever, please make sure you review all <a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/breaking-changes.html">breaking changes</a> and thoroughly test against your specific use case prior to upgrading.
</body></html>

switching-to-the-bool-query-for-boolean-operations.jpg

using-the-bool-query-for-boolean-operations.jpg

Lost in Translation: Boolean Operations and Filters in the Bool Query

Start free trial

Blog Footer CTA

Sign up for Elastic Cloud free trial

Tyler Fontaine

Register to Attend

Register to Watch

Надсилаючи цю форму ви погоджуєтеся з <a href="/legal/terms-of-use">Умовами надання послуг Elastic</a>. Ваші особисті дані будуть опрацьовані відповідно з <a href="/legal/privacy-statement">Положеннями про конфіденційність Elastic</a>.

Newsletter GDPR Text - Ukrainian

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

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

Intentionally Blank

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="/legal/elastic-cloud-account-terms" target="_blank">服務條款</a>，且同意 Elastic 使用您在上方提供的個人資料<a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">與您聯絡</a>，為您提供相關產品和服務的資訊。如需詳細說明或隨時想停止收到產品和服務資訊，請參閱 <a href="/legal/privacy-statement/" target="_blank">Elastic 的隱私聲明</a>。

Newsletter GDPR Text - TW

By submitting you acknowledge that you've read and agree to our <a href="/legal/elastic-cloud-account-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.By submitting this form, I agree to Elastic sharing my contact information with Google Cloud. I also agree to Elastic giving my information to the vendor for the purpose of shipping my food package.

GDPR Text + Google Cloud

Inviando la registrazione (1) esprimi il consenso ai <a href="/legal/terms-of-use">termini e condizioni di Elastic</a> e <a href="/legal/privacy-statement">all’informativa sulla privacy</a>, nonché (2) a ricevere saltuarie e-mail.

Newsletter GDPR Text - Italian

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

Load more

Overview

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

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

You'll also receive an email with related content.

You'll also receive an email with related content

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.

Author

Articles by Tyler Fontaine

Announcing Support for Elastic Cloud Standard, Our Hosted Elasticsearch Offering

Migrating to Elastic Cloud

Lost in Translation: Boolean Operations and Filters in the Bool Query