Strategien um die Datenintegrität zu überprüfen, was notwendig sein kann, wenn Daten zwischen Elasticsearch und anderen Datenspeichern synchronisiert werden.

<html><head></head><body><p>Elasticsearch wird manchmal gemeinsam mit anderen Datenbanken genutzt. In solchen Szenarien ist es oft schwierig, L&#xF6;sungen zu implementieren, die <a href="https://en.wikipedia.org/wiki/Two-phase_commit_protocol">Two-Phase-Commits</a> unterst&#xFC;tzen, was haupts&#xE4;chlich an einer fehlenden Transaktionsunterst&#xFC;tzung &#xFC;ber alle Systeme hinweg liegt. Abh&#xE4;ngig von deinem individuellen Fall kann es notwendig sein, die Daten, die sich in beiden Datenspeichern befinden, zu verifizieren, wobei einer als die sogenannte &#x201E;Source of Truth&#x201C; fungiert.
</p><p>Als Support-Engineer bei Elastic erhalten wir regelm&#xE4;&#xDF;ig Anfragen, die sich um Aspekte wie die beste Vorgehensweise bei der Strukturierung von Daten f&#xFC;r die Verifizierung oder auch einfach um ein effizientes Strukturieren an sich drehen. Dieser Blogbeitrag wird dich durch einige Beispiele f&#xFC;hren, die wir selbst erlebt und dementsprechend bearbeitet haben. Die Beispiele reichen von einfach bis fortgeschritten und befassen sich mit der Verifizierung, dass Elasticsearch alle notwendigen Daten aus einer Datenbank wie beispielsweise PostgreSQL enth&#xE4;lt.
</p><h2>Modellierung der Daten f&#xFC;r die Verifizierung</h2><p>Die Art und Weise, wie deine Daten gespeichert sind, sowohl in als auch au&#xDF;erhalb von Elasticsearch, macht einen gro&#xDF;en Unterschied in Bezug auf die Verifizierung. Zun&#xE4;chst musst du dich entscheiden, wie viel tats&#xE4;chlich verifiziert werden muss:</p><ul>
	<li>Ist die blo&#xDF;e Existenz eines Dokuments bereits ausreichend?</li>
	<li>Oder macht ein interner Prozess die Verifizierung ganzer Dokumente n&#xF6;tig?</li>
</ul><p>Diese Entscheidung wird Auswirkungen auf den f&#xFC;r die Verifizierung n&#xF6;tigen Arbeitsumfang haben.
</p><h2>Die Evolution der Existenzverifizierung</h2><p>Gl&#xFC;cklicherweise geht es hier nicht um eine tiefgr&#xFC;ndige philosophische Fragestellung. Stattdessen ist es einfach die Frage: &#x201E;Existieren s&#xE4;mtliche Dokumente in Elasticsearch?&#x201C;
</p><p>So lange du wirklich verstehst, was genau passiert, bietet Elasticsearch viele M&#xF6;glichkeiten der Existenzverifizierung. Denke daran, dass <a href="https://www.elastic.co/guide/en/elasticsearch/guide/current/near-real-time.html">Elasticsearch nahezu in Echtzeit  <em>sucht</em></a>, dabei jedoch Dokumente direkt und in Echtzeit abrufen kann. Dies bedeutet, dass ein Dokument direkt nach seiner Indexierung im Rahmen von Suchanfragen nicht sichtbar ist, jedoch per Direktabfrage (Get Request) verf&#xFC;gbar sein wird.</p><h3>Eins nach dem anderen</h3><p>F&#xFC;r Entwicklungen in kleinerem Umfang ist der einfachste Ansatz, Head-Anfragen (<code>HEAD</code>) auf einzelne Dokumente auszuf&#xFC;hren und dann sicherzustellen, dass der HTTP-Antwortcode keine 404-Meldung ist (Seite &#x2013; oder in diesem Fall Dokument &#x2013; nicht gefunden).
</p><pre class="prettyprint">HEAD /my_index/my_type/my_id1
</pre><p>Eine beispielhafte Antwort w&#xE4;re, dass ausschlie&#xDF;lich Header im Erfolgsfall &#xFC;bertragen werden:
</p><pre class="prettyprint">HTTP/1.1 200 OK
Content-Type: text/plain; charset=UTF-8
Content-Length: 0
</pre><p>Bei der Nicht-Existenz s&#xE4;he es praktisch genauso aus, abgesehen vom Antwortcode:
</p><pre class="prettyprint">HTTP/1.1 404 Not Found
Content-Type: text/plain; charset=UTF-8
Content-Length: 0
</pre><p>Dies erfordert, dass du <code>N</code> Anfragen gegen einen Index ausf&#xFC;hrst, der erwartungsgem&#xE4;&#xDF; N Dokumente enthalten sollte. Wie du dir vielleicht vorstellen kannst, l&#xE4;sst sich dieser Ansatz nicht wirklich gut skalieren.
</p><h3>Batch-Processing</h3><p>Im weiteren Verlauf entscheidest du dich vielleicht, das Ganze &#xFC;ber Batch-Requests mittels der Multi-GET-API durchzuf&#xFC;hren: <code>_mget</code>.
</p><pre class="prettyprint">GET /my_index/my_type/_mget
{
  &quot;ids&quot;: [ &quot;my_id1&quot;, &quot;my_id2&quot; ]
}
</pre><p>Ein weiterer vergleichbarer Ansatz hierf&#xFC;r ist, einfach nach den IDs zu suchen und die erwartete Nummer zur&#xFC;ckzugeben.
</p><pre class="prettyprint">GET /my_index/_refresh
GET /my_index/my_type/_search
{
  &quot;size&quot;: 2,
  &quot;query&quot;: {
    &quot;ids&quot;: {
      &quot;values&quot;: [ &quot;my_id1&quot;, &quot;my_id2&quot; ]
    }
  }
}
</pre><p>Zuerst wird der Endpunkt <code>_refresh</code> aufgerufen, um sicherzustellen, dass alle indizierten Inhalte auch durchsuchbar sind. Dies beseitigt den erw&#xE4;hnten &#x201E;Fast-Echtzeit-Aspekt&#x201C; der Suche. Unter normalen Suchbedingungen solltest du dies nicht tun &#x2013; in diesem Fall macht es jedoch absolut Sinn. Vermutlich wird die Verarbeitung deiner Verifizierung komplett auf einmal durchgef&#xFC;hrt. Ist das der Fall, ist der Aufruf von <code>_refresh</code> <em>einmalig</em> und zu Beginn eines Jobs f&#xFC;r alles Folgende ausreichend. Dies gilt jedoch nur, sofern du nicht auf neue Daten pr&#xFC;fst, die nach dem Starten des Prozesses hinzugef&#xFC;gt wurden.
</p><p>Dieses Vorgehen bietet ein besseres Request-Handling, vermeidet jedoch nicht die Arbeit im Hintergrund, die hier unver&#xE4;ndert bleibt. Auch bedeutet es, dass jedes Dokument ebenfalls zur&#xFC;ckgegeben wird, was einen entsprechenden zus&#xE4;tzlichen Mehraufwand verursacht.
</p><h3>Suchen, dann batchen</h3><p>Ausgehend vom Batch-Processing, gehen viele Anwender dazu &#xFC;ber, das Problem durch eine Unterteilung l&#xF6;sen zu wollen. Zuerst f&#xFC;hren sie dabei eine Suche durch, um festzustellen, was genau fehlt. Erst danach beginnen sie mit der Suche nach dem fehlenden Dokument.
</p><pre class="prettyprint">GET /my_index/_refresh
GET /my_index/my_type/_search
{
  &quot;size&quot;: 0,
  &quot;query&quot;: {
    &quot;ids&quot;: {
      &quot;values&quot;: [ &quot;my_id1&quot;, &quot;my_id2&quot; ]
    }
  }
}
</pre><p>Wenn du den Wert <code>hits.total</code> der Antwort pr&#xFC;fst, dann sollte dieser der von dir erwarteten Zahl entsprechen. In diesem vereinfachten Beispiel sollte es <code>2</code> sein. Falls es nicht 2 ist, musst du einen Gang hochschalten und entweder:
</p><ol>
	<li>Nach s&#xE4;mtlichen IDs suchen, sie durch die Angabe einer entsprechenden Gr&#xF6;&#xDF;e zur&#xFC;ckgeben und dann die fehlende(n) Nadel(n) im Heuhaufen finden.</li>
	<li>Auf das Beispiel mit der Funktion <code>_mget</code> von oben zur&#xFC;ckgreifen und das Gleiche tun: Bestimmen, welche ID fehlt.</li>
</ol><h3>Es muss einen besseren Weg geben</h3><p>Die langwierige oder zweistufige Verarbeitung kann umst&#xE4;ndlich zu skalieren sein und unterstellt, dass du eine teure Frage stellst, aber auch, dass du eventuell einfach die falsche Frage stellst.
</p><p>Was w&#xE4;re, wenn du die Anfrage oder die allgemeine Frage auf den Kopf stellen w&#xFC;rdest; wenn du anstatt der Anfrage &#x201E;Finde alles, was existiert&#x201C; eher die Frage &#x201E;Was fehlt?&#x201C; stellen w&#xFC;rdest? Es ist schwierig, Dinge abzufragen, die nicht vorhanden sind. Tats&#xE4;chlich ist es regelrecht unm&#xF6;glich, da die Daten nicht existieren. Mit Hilfe von Aggregationen l&#xE4;sst sich die Frage trotzdem beantworten &#x2013; dies jedoch nur, <em>sofern</em> du Daten passend strukturieren kannst.
</p><p>Die meisten Fallbeispiele im Bereich Verifizierung kommen aus der SQL-Welt, in der ganzzahlige Schl&#xFC;ssel f&#xFC;r Prim&#xE4;r- und Fremdschl&#xFC;ssel sehr h&#xE4;ufig sind. Auch wenn du diese numerischen IDs nicht als Elasticsearch <code>_id</code> nutzt, solltest du sie als ganzzahlige Werte mit <a href="/blog/support-in-the-wild-my-biggest-elasticsearch-problem-at-scale">aktivierten Doc-Values</a> indizieren (standardm&#xE4;&#xDF;ig eingestellt in ES2.x und aktueller). Zum Beispiel:
</p><pre class="prettyprint">POST /my_index/my_type/my_id1
{
  &quot;id&quot;: 1,
  &#x2026;
}
</pre><p>Der Name des Feldes ist irrelevant. Beachte jedoch, dass es nicht <code>_id</code>,ist, was in Elasticsearch ein reserviertes Metadaten-Feld ist. Sobald du mit der Indizierung dieses Wertes beginnst, wird das Auffinden <em>fehlender</em> Daten mit Hilfe von Histogrammen sehr einfach.
</p><pre class="prettyprint">GET /my_index/my_type/_search
{
  &quot;size&quot;: 0,
  &quot;aggs&quot;: {
    &quot;find_missing_ids&quot;: {
      &quot;histogram&quot;: {
        &quot;field&quot;: &quot;id&quot;,
        &quot;interval&quot;: 1,
        &quot;min_doc_count&quot;: 0
      },
      &quot;aggs&quot;: {
        &quot;remove_existing_bucket_selector&quot;: {
          &quot;bucket_selector&quot;: {
            &quot;buckets_path&quot;: {
              &quot;count&quot;: &quot;_count&quot;
            },
            &quot;script&quot;: {
              &quot;inline&quot;: &quot;count == 0&quot;,
              &quot;lang&quot;: &quot;expression&quot;
            }
          }
        }
      }
    }
  }
}
</pre><p>Dies sorgt f&#xFC;r zwei Dinge:
</p><ol>
	<li>Es wird ein Histogramm &#xFC;ber das numerische Feld <code>id</code> erstellt. Dabei wird ein Schritt von <code>1</code> zwischen jedem Wert verwendet, was bedeutet, dass f&#xFC;r alle <code>id</code> s&#xA0;s&#xE4;mtliche dazwischenliegenden und ganzzahlig-basierten Werte gefunden werden (z. B. 1&#x2013;5 w&#xFC;rden als ein Histogramm aus 1, 2, 3, 4, 5 dargestellt werden).</li>
	<li>Alle Histogramm-Buckets, die tats&#xE4;chlich Daten enthalten, werden durch die Anwendung eines Bucket-Selektors entfernt. Dieser ist jedoch ausschlie&#xDF;lich in Elasticsearch 2.0 und neueren Versionen verf&#xFC;gbar.</li>
</ol><p>Indem wir entfernen, was tats&#xE4;chlich existiert, bleibt nur das &#xFC;brig, was dementsprechend nicht existiert. Dies kann dann folgenderma&#xDF;en aussehen:
</p><pre class="prettyprint">{
  &quot;took&quot;: 4,
  &quot;timed_out&quot;: false,
  &quot;_shards&quot;: {
    &quot;total&quot;: 5,
    &quot;successful&quot;: 5,
    &quot;failed&quot;: 0
  },
  &quot;hits&quot;: {
    &quot;total&quot;: 5,
    &quot;max_score&quot;: 0,
    &quot;hits&quot;: []
  },
  &quot;aggregations&quot;: {
    &quot;find_missing_ids&quot;: {
      &quot;buckets&quot;: [
        {
          &quot;key&quot;: 4,
          &quot;doc_count&quot;: 0
        }
      ]
    }
  }
}
</pre><p>Aus einem winzigen Index mit f&#xFC;nf Dokumenten, gefunden mit der Funktion <code>hits.total</code>, zeigt uns dies, dass das Dokument mit der <code>id</code> 4 fehlt.
</p><p>Das ist auch schon alles: Wenn du ein Histogramm aus dem spezifischen Schl&#xFC;ssel des Dokuments erstellen kannst, dann kannst du auch eines erstellen, das nur fehlende Daten anzeigt. Du kannst dies jedoch nicht mit Strings durchf&#xFC;hren. Das bedeutet, dass dieser auf Aggregationen basierende Ansatz f&#xFC;r Elemente wie <code>&#x201E;my_id&#x201C;</code> und UUIDs (z. B. ein Globally Unique Identifier bzw. GUID) nicht angewendet werden kann! F&#xFC;r diese Art der Pr&#xFC;fung muss man auf die Strukturierung von Daten zur&#xFC;ckgreifen.
</p><h4>Vorsicht L&#xFC;cke</h4><p>Denjenigen, die nicht sehr vertraut mit sequentiellen Identifikatoren sind, sei gesagt, dass es in Systemen (z. B. SQL-Datenbanken) durchaus zu einem &#x201E;Prefetch&#x201C; ganzer Batches an Identifikatoren kommen kann. Innerhalb dieser Batches kann es aus verschiedenen Gr&#xFC;nden dazu kommen, dass bestimmte Werte &#xFC;bersprungen werden. Dazu z&#xE4;hlen fehlgeschlagene Transaktionen oder sogar einfachere Gr&#xFC;nde wie zum Beispiel nachtr&#xE4;glich gel&#xF6;schte Eintr&#xE4;ge.
</p><p>In solchen F&#xE4;llen musst du dir bewusst sein, dass diese Werte gem&#xE4;&#xDF; dem Histogramm als fehlende Dokumente erscheinen. Um dies zu vermeiden, kannst du Elasticsearch als Client auffordern, diese Werte ausdr&#xFC;cklich zu ignorieren. Daf&#xFC;r f&#xFC;ge einen sekund&#xE4;ren Bucket-Selektor hinzu, der explizit genau solche <code>id</code>s eliminiert oder sie clientseitig ignoriert.
</p><h2>Verifizierung ganzer Dokumente</h2><p>Die Verifizierung ganzer Dokumente ist eine Herausforderung jenseits der blo&#xDF;en Existenzpr&#xFC;fung. In diesem Szenario m&#xFC;ssen ganze Dokumente verifiziert werden, um sicherzustellen, dass die darin enthaltenen Daten auch die erwarteten Daten sind. Aus der Perspektive von Elasticsearch ist es genau genommen sogar einfacher. Die Arbeit auf deiner Seite ist jedoch komplizierter.
</p><h3>Durch Daten scrollen</h3><p>Der einfachste Weg, diese &#xDC;berpr&#xFC;fung durchzuf&#xFC;hren, ist, sich durchzuscrollen. Gl&#xFC;cklicherweise bedeutet das nicht, dass du deine gesamten Daten in eine HTML-Tabelle &#xFC;bertragen und dann mit dem Mausrad alles doppelt pr&#xFC;fen musst. Vielmehr geht es hier um die Nutzung der <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-scroll.html"><code>_scroll</code> API, um durch all deine Daten zu gehen</a> (<code>_doc</code>, wie unten genutzt, ist in dem Link beschrieben). Wie jede Such-API funktioniert dies auf Basis desselben Fast-Echtzeit-Prinzips wie weiter oben angemerkt.
</p><pre class="prettyprint">GET /my_index/my_type/_search?scroll=1m
{
  &quot;sort&quot;: [
    &quot;_doc&quot;
  ]
}
</pre><p>Die Scroll-Zeit ist die Zeit, die du in der Rolle als Client-Software zur Bearbeitung eines Batches ben&#xF6;tigst, bevor der n&#xE4;chste Batch abgefragt wird. Stelle sicher, dass sie lang genug ist, um die nachfolgende Antwort durchzugehen und lies die oben verlinkte Dokumentation durch!
</p><p>Indem du durch die Daten scrollst, kannst du dich Dokument f&#xFC;r Dokument vergewissern, dass alle Daten entsprechend deiner Vorgaben korrekt sind.
</p><h3>Kontrolle &#xFC;ber die Versionierung &#xFC;bernehmen</h3><p>Elasticsearch unterst&#xFC;tzt <a href="https://www.elastic.co/guide/en/elasticsearch/guide/current/optimistic-concurrency-control.html">Optimistic Concurrency Control (OCC)</a>, was nichts anderes als die Versionierung beschreibt.
</p><p>Du kannst die vollst&#xE4;ndige Kontrolle &#xFC;ber die Versionierung &#xFC;bernehmen, indem du deine eigene Versionsnummer verwendest. Wenn du dies tust, kannst du durch die Verifizierung von Versionsnummern m&#xF6;glicherweise eine vollst&#xE4;ndige Dokumentenpr&#xFC;fung vermeiden. Um Versionsnummern im Kontext von Suchantworten zu aktivieren, musst du das Versions-Flag&#xA0;setzen:
</p><pre class="prettyprint">GET /my_index/my_type/_search
{
  &quot;version&quot;: true
}
</pre><h2>Verifizierung umgehen</h2><p>Es ist m&#xF6;glich, die Verifizierung komplett zu umgehen, vorausgesetzt, dass du sicher sein kannst, dass die Daten von einem vertrauensw&#xFC;rdigen Nutzer bereitgestellt und s&#xE4;mtliche Ingestion-Fehler angemessen behoben wurden (z. B. falls Elasticsearch zum Zeitpunkt au&#xDF;er Betrieb war, als Dokument 15123 indiziert werden sollte, dann muss noch immer etwas hinzugef&#xFC;gt werden). In diesem Szenario kann eine Verifizierung &#xFC;berfl&#xFC;ssig werden.
</p><p><a href="https://www.elastic.co/guide/en/x-pack/current/index.html">X-Pack Security</a> in der Version 5.0 und <a href="https://www.elastic.co/guide/en/shield/current/index.html">Shield</a> in fr&#xFC;heren Releases k&#xF6;nnen f&#xFC;r die n&#xF6;tige Sicherheit sorgen, indem vertrauensw&#xFC;rdigen Nutzern Zugriff gew&#xE4;hrt wird und nicht-vertrauensw&#xFC;rdige Nutzer blockiert werden. Jedoch liegt es letztendlich bei dir, wie du mit Ingestion-Fehlern umgehen m&#xF6;chtest, da dies g&#xE4;nzlich davon abh&#xE4;ngt, durch was die Datenaufnahme vorgenommen wird.
</p><h2>Fazit</h2><p>Du hast es geschafft! Du hast dich durch meinen langen Blogbeitrag gearbeitet.
</p><p>Ich hoffe, dass dir die Lekt&#xFC;re zum Thema Datenverifizierung und der Frage, wie die Strukturierung deiner Daten zu drastisch vereinfachten Ans&#xE4;tzen&#xA0;beitragen kann, gefallen hat. Wenn du &#xFC;ber diese Art der Herangehensweise nachdenkst, beginne zu verstehen, wie auch andere Probleme durch eine alternative Betrachtung von Anfragen oder Daten und mit Hilfe reichhaltiger Features wie Aggregationen oder X-Pack-Security gel&#xF6;st werden k&#xF6;nnen.
</p><p>Wir sind st&#xE4;ndig auf der Suche nach kreativen Wegen, um interessante Probleme zu l&#xF6;sen. Dieses Thema ist dabei keine Ausnahme. Wie immer ermutigen wir unsere User diese Themen in unserem <a href="https://discuss.elastic.co/c/logstash">Forum</a>&#xA0;zu diskutieren und GitHub-Issues zu allen sich ergebenen Problemen zu er&#xF6;ffnen. Zudem helfen wir auch gerne &#xFC;ber <a href="https://twitter.com/elastic">Twitter</a> (<a href="https://twitter.com/pickypg">@pickypg</a> &#x2013; das bin ich) und <a href="https://webchat.freenode.net/#elasticsearch">IRC</a> weiter.
</p></body></html>

field-half-green-half-brown.jpg

shoes-blue-yellow-grass.jpg

Elasticsearch: Verifying Data Integrity with External Data Stores

Elasticsearch: Datenintegrität mit externen Datenspeichern überprüfen

Start free trial

Blog Footer CTA

Sign up for Elastic Cloud free trial

Support Engineer

Chris Earle

<p>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.</p>

Communication Preferences - ONLY for /communication-preferences

<p>Durch das Absenden erklären Sie, dass Sie unsere <a href="/de/legal/elastic-cloud-account-terms" target="_self">Nutzungsbedingungen</a> gelesen haben und mit ihnen einverstanden sind und dass Sie Elastic erlauben, <a href="/de/legal/privacy-statement#how-we-use-the-information" target="_self">ausgewählte Nachrichten und Informationen</a> an die oben von Ihnen bereitgestellten Kontaktangaben zu senden. Weitere Informationen, darunter auch dazu, wie Sie Ihre Einwilligung zurückziehen können, finden Sie in der <a href="/de/legal/privacy-statement/" target="_self">Datenschutzerklärung von Elastic</a>.</p>

<p>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.</p>

Serverless GDPR Text

<p>Durch das Absenden erklären Sie, dass Sie unsere <a href="/de/legal/serverless-preview-terms" target="_self">Nutzungsbedingungen</a> gelesen haben und mit ihnen einverstanden sind und dass Sie Elastic erlauben, bezüglich unserer zugehörigen Produkte und Dienstleistungen und unter Nutzung der von Ihnen oben bereitgestellten Kontaktangaben <a href="/de/legal/privacy-statement#how-we-use-the-information" target="_self">mit Ihnen in Kontakt zu treten</a>. Weitere Informationen, darunter auch dazu, wie Sie Ihre Einwilligung zurückziehen können, finden Sie in der <a href="/de/legal/privacy-statement/" target="_self">Datenschutzerklärung von Elastic</a>.</p>

<p>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>.</p>

Cloud Trial GDPR Text

<p>Beim Absenden akzeptieren Sie die <a href="/de/agreements/global/cloud-services-monthly" rel="nofollow">Nutzungsbedingungen von Elastic Cloud</a>. Die Verarbeitung Ihrer personenbezogenen Daten unterliegt der <a href="/de/legal/privacy-statement">Datenschutzerklärung von Elastic</a>.
</p>

<p>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.</p>

Newsletter GDPR Text

<p>Durch das Absenden erklären Sie, dass Sie unsere <a href="/de/legal/terms-of-use" target="_self">Nutzungsbedingungen</a> gelesen haben und mit ihnen einverstanden sind und dass Sie Elastic erlauben, bezüglich unserer zugehörigen Produkte und Dienstleistungen und unter Nutzung der von Ihnen oben bereitgestellten Kontaktangaben <a href="/de/legal/privacy-statement#how-we-use-the-information" target="_self">mit Ihnen in Kontakt zu treten</a>. Weitere Informationen, darunter auch dazu, wie Sie Ihre Einwilligung zurückziehen können, finden Sie in der <a href="/de/legal/privacy-statement/" target="_self">Datenschutzerklärung von Elastic</a>.</p>

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.

Der Inhalt dieser Seite ist in der ausgewählten Sprache nicht verfügbar. Wir bei Elastic arbeiten daran, die bereitgestellten Inhalte in verschiedenen Sprachen anzubieten. Bis dahin bitten wir Sie um etwas Geduld und hoffen auf Ihr Verständnis!

Author

Watch now (no PT)

Watch now

See all top stories

All (no PT translation)

Contact information

Press Release

Share on Reddit

Articles by

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

Sie können nicht dabei sein? Registrieren Sie sich, damit wir Ihnen die Aufzeichnung zukommen lassen können. Außerdem erhalten Sie eine E‑Mail mit Begleitmaterial.

Small image for

On-demand webinar

Featured webinar

Register to Attend

Share on Facebook

Reset all

Upcoming webinar

View more posts

Print

Hosted by

Sign In to Attend

View next

Follow us on Facebook

Share

Highlights

Learn More

Read less

You'll also receive an email with related content

Wir schicken Ihnen zudem relevante Informationen, die von Interesse sein könnten.

Thank you for registering. We will send you a confirmation email soon.

Vielen Dank für Ihre Registrierung. Sie erhalten in Kürze eine Bestätigungs-E‑Mail von uns.

Author

Articles by Chris Earle

Support Engineer, Elastic

Elasticsearch: Datenintegrität mit externen Datenspeichern überprüfen