<p><strong>AKTUALISIERUNG:</strong> In diesem Artikel wird für unser gehostetes Elasticsearch-Angebot noch sein früherer Name „Found“ verwendet. „Found“ heißt heute „Elastic Cloud“.</p>
<p>Elasticsearch wird für viele verschiedene Anwendungsfälle verwendet: „klassische“ Volltextsuche, Analytics-Speicher, Autovervollständigung, Rechtschreibkorrektur, Alerting-Engine und als allgemeiner Dokumentenspeicher. Dieser Artikel gibt Ihnen einen kurzen Überblick zu verschiedenen Verwendungsarten und zu beachtenden Punkten, einschließlich Hinweisen dazu, wo Sie mehr darüber erfahren.</p>
<section id="introduction" class="level2">
  <h2><a href="#introduction">Einführung</a></h2>
  <p>Wir bei Found sehen <em>viele</em> verschiedene Anwendungsfälle von Elasticsearch. Häufig werden wir gefragt: „Was ist euer typischer Kunde?“ Doch auf diese Frage können wir keine klare Antwort geben, abgesehen von „Unsere Kunden bauen sich lieber etwas auf, als mit Clustern zu arbeiten!“ Wir stellen fest, dass Elasticsearch für viele unterschiedliche großartige und auch einige außergewöhnliche Zwecke verwendet wird.</p>
  <p>Elasticsearch ist noch relativ neu, und unsere Kunden beginnen in der Regel mit der Verwendung von Elasticsearch für ein bestimmtes Projekt, und fahren später mit weiteren Clustern für Logging und Analytics fort.</p>
  <p>Eine gewöhnliche Entwicklung beginnt mit einer einfachen Suche nach einer Website oder einer Sammlung von Dokumenten. Als nächstes kommt unter Umständen die Facettennavigation hinzu, sowie die Rechtschreibkorrektur oder Antworten wie „Meinten Sie&nbsp;…?“. Möglicherweise wird eine unscharfe Suche und auch Autovervollständigung durchgeführt, vielleicht sogar „Search-as-you-type“. Und weil Relevanz wichtig ist, werden schließlich fortschrittlichere Rankings hinzugefügt&nbsp;– beispielsweise basierend darauf, wer der Nutzer ist, wo er sich befindet oder wen er kennt. Und damit klar ist, was die Nutzer genau tun, muss die Verwendung protokolliert und die Metriken gespeichert werden, damit wir wissen, dass alles gut funktioniert.</p>
  <p>Elasticsearch kann für all das und noch mehr verwendet werden, doch die unterschiedlichen Anwendungsfälle zeichnen sich durch ganz verschiedene Level an Komplexität und erforderlichen Ressourcen aus.</p>
</section>
<section id="you-know-for-search-and-counting" class="level2">
  <h2><a href="#you-know-for-search-and-counting">You Know, for Search! (und mehr!)</a></h2>
  <p>Es ist nicht überraschend, dass Elasticsearch häufig zur Implementierung einer „Suche“ verwendet wird, was in der Regel bedeutet, dass es ein Eingabefeld und ein zugehöriges Lupensymbol gibt. Was wir mit „Suche“ meinen, ist in diesem Fall mehrdeutig, und daher werde ich auf verschiedene <em>Arten</em> von Suchen eingehen, z.&nbsp;B. „einfache Suche“, „unscharfe Suche“, „Aggregationen“&nbsp;– dabei bezieht sich <em>einfach</em> auf die Möglichkeiten einer simplen match-Abfrage.</p>
  <p>Viele sind überrascht davon, dass <em>einfaches</em> Suchen zu den am wenigsten ressourcenintensiven Aufgaben von Elasticsearch gehört. Wenn Sie einfach nur die zehn besten Ergebnisse für eine reguläre, exakte match-Abfrage benötigen, können Sie Hunderte von Suchen pro Sekunde in Sammlungen mit zig Millionen von Dokumenten auf kostengünstiger Hardware durchführen. Wenn jedoch eine unscharfe Suche oder Facettennavigation zu Ihren Anforderungen gehören, müssen die CPU und der Arbeitsspeicher <em>deutlich</em> besser sein.</p>
  <p>Von modernen Suchoberflächen wird in der Regel eine Art Facettennavigation erwartet, mithilfe derer der Nutzer die Distribution der Suchergebnisse schnell versteht. Wie viele Bücher stammen von einem bestimmten Autor, liegen in einer bestimmten Preisspanne und haben eine bestimmte Bewertung? Diese werden mithilfe von Aggregationen in Elasticsearch implementiert, und es gibt sie in vielen Varianten. Sie können Begriffe, Zahlenbereiche, Datumsbereiche, Geodaten und Vieles mehr zum Aggregieren verwenden.</p>
  <p>Es erscheint vielen unlogisch, dass die Suche nach Treffern in Millionen von Dokumenten im Vergleich zum Zählen und Aggregieren von Treffern auf verschiedene Arten einen geringeren Aufwand bedeutet. Nichtsdestotrotz ist das Aggregieren kostspielig, wenn man es mit der Schwierigkeit beim Informationsabruf vergleicht: „Welche zehn Dokumente stimmen mit diesen Bedingungen überein (und sind am relevantesten)?“ Auf der Suche nach den besten Dokumenten verwendet Lucene Tricks wie „Dieser Dokumentensatz stimmt im Vergleich zu diesen Dokumenten nicht mit allen Punkten überein, also kann er nicht der passendste sein, also einfach überspringen.“ Beim Filtern <a href="/de/blog/found-optimizing-elasticsearch-searches#find-a-friend-in-filters">nutzt Elasticsearch den Filter-Cache</a> sehr häufig. Elasticsearch und Lucene sind gut darin, Arbeit zu <em>vermeiden</em>, wo es möglich ist, doch was Aggregationen betrifft, <a href="/de/blog/found-optimizing-elasticsearch-searches#aggregation-abundance">müssen sie stets alle Übereinstimmungen zählen</a>.</p>
  <p>In <a href="/de/blog/found-elasticsearch-from-the-bottom-up">Elasticsearch von unten nach oben</a> erklären wir, wie der invertierte Index funktioniert, und wie das Wörterbuch und Posting-Listen für eine einfache Suche verwendet werden. Dieser Artikel und unsere Artikel zur Textanalyse sollen verdeutlichen, weshalb die korrekte Verarbeitung von Text bei der Suche sehr wichtig ist. <a href="/de/blog/found-sizing-elasticsearch#searching">Dimensionierung von Elasticsearch</a> und <a href="/de/blog/found-elasticsearch-in-production#a-typical-search-request">Elasticsearch in der Praxis</a> enthalten Einzelheiten dazu, welche Art von Arbeitsspeicher Sie erwarten können.</p>
</section>
<section id="analytics" class="level2">
  <h2><a href="#analytics">Analytics</a></h2>
  <p>Analytische Workloads tendieren dazu, Elemente zu zählen und fassen Ihre Daten zusammen&nbsp;– viele Daten, vielleicht sogar Big Data, was auch immer das heißt! Diese basieren auf den <a href="/de/blog/found-elasticsearch-aggregations">Aggregationen von Elasticsearch</a>, und die Aggregationen werden häufig mit Tools wie <a href="/de/kibana">Kibana</a> generiert.</p>
  <p>Wir haben bereits erwähnt, dass diese Aggregationen relativ kostspielig sein können, sowohl im Hinblick auf die CPU als auch den Arbeitsspeicher. Die Anforderungen an den Arbeitsspeicher sind hoch, da Elasticsearch einen Wert schnell in einem Dokument suchen muss, was bedeutet, dass alle Daten für alle Dokumente in einem „Feld-Cache“ im Arbeitsspeicher geladen werden müssen. Dies gelingt leichter mithilfe von <a href="/de/blog/disk-based-field-data-a-k-a-doc-values">„Dokumentwerten“</a>, die Sie vor dem Indexieren von Dokumenten in Ihrem Mapping aktivieren müssen.</p>
  <p>Darüber hinaus laufen analytische Suchen häufig auf <a href="/de/blog/found-sizing-elasticsearch#timestamped-data">mit Zeitstempel versehenen Daten, bei denen es sinnvoll sein kann, diese beispielsweise in tägliche oder monatliche Indizes zu unterteilen</a>. Mit je einem Index pro Zeiteinheit können Sie Ihren Suchraum ganz leicht reduzieren und <a href="/de/blog/curator-tending-your-time-series-indices">veraltete Daten aufräumen und archivieren</a>.</p>
</section>
<section id="fuzzy-searching" class="level2">
  <h2><a href="#fuzzy-searching">Unscharfe Suche</a></h2>
  <p>Eine unscharfe Suche verzeiht Rechtschreibfehler. Hier ein Beispiel: Sie finden Levenshtein, wenn Sie nach Levenstein suchen. Unser Artikel zur <a href="/de/blog/found-fuzzy-search/">unscharfen Suche</a> enthält weitere Einzelheiten zur Verwendung und Funktionsweise der unscharfen Suche.</p>
  <p>Unscharfe Suchen sind einfach umzusetzen und können die Trefferquote deutlich verbessern, doch sie können auch kostspielig werden. Standardmäßig kann ein Begriff im Eingabefeld zu einem ODER mit 50 Begriffen pro Feld umgeschrieben werden, was in Verbindung mit multi_field für eine kombinatorische Explosion von Begriffen in der resultierenden <a href="/de/blog/found-elasticsearch-top-down#query-rewriting">umgeschriebenen Abfrage</a> sorgen kann.</p>
  <p>Es ist immer wichtig, Änderungen und Verbesserungen an Ihrer Suche mit einer realistischen Menge an Daten zu testen, bevor Sie sie in der Praxis verwenden. Das trifft vor allem dann zu, wenn der fuzziness-Parameter hinzugefügt wird. Diese Option ist einfach umzusetzen, doch sie wird Ihre Suchen bedeutend kostspieliger machen.</p>
  <blockquote>Unscharfe Suchen sind CPU-intensiv. Fügen Sie diese mit Bedacht hinzu, und besser nicht für jedes Feld.</blockquote>
</section>
<section id="autocompletion-and-instant-search" class="level2">
  <h2><a href="#autocompletion-and-instant-search">Autovervollständigung und Sofortsuche</a></h2>
  <p>Die Suche, während der Nutzer tippt, gibt es in vielen Varianten. Sie kann aus einfachen Vorschlägen bestehen, z.&nbsp;B. bestehende Tags, die auf Basis der Suchhistorie eine Suche prognostizieren, oder eine komplett neue Suche für jeden (gedrosselten) Tastenanschlag durchführen.</p>
  <p>Es gibt viele verschiedene Funktionen in Elasticsearch, die Unterstützung bei der Erstellung dieser Features bieten, z.&nbsp;B. prefix-Abfragen, match_phrase_prefix, Indexieren von ngrams, und eine Reihe <a href="/de/blog/you-complete-me/">verschiedener Suggester</a>.</p>
  <p>Suchen wie diese sind sehr latenzempfindlich. Die Grenze dessen, was nicht mehr als „sofort“ empfunden wird, liegt in der Regel bei 100 Millisekunden. Die Suche bei nahezu jedem Tastenanschlag bringt auch einen höheren Suchdurchsatz mit sich. Daher ist es maßgeblich, dass die Suchen kostengünstig sind und diese Indizes zum Arbeitsspeicher passen.</p>
  <p>Die Autovervollständigung von Suchen und die parallele Anzeige der Ergebnisse für die am wahrscheinlichsten durchgeführte Suche, etwa so, wie Google es tut, sollten als zwei unterschiedliche Problematiken der Suche betrachtet werden. Die Menge an Daten, die bei der Autovervollständigung vorheriger Suchen durchsucht wird, ist vermutlich deutlich kleiner als die durchsuchten Inhalte, wodurch die Speicherung im Arbeitsspeicher und unscharfe Suchen leichter umzusetzen sind. Da eine autovervollständigte Suche eine deutlich höhere Suchlast als die Vollsuche mit sich bringt, ist es durch die Trennung der beiden möglich, sie separat zu skalieren, gegebenenfalls in komplett getrennten Elasticsearch-Clustern.</p>
  <p>Als Soundcloud seine Sucherfahrung umgestaltete, wurde viel an Suchvorschlägen gearbeitet. Die Implementierung wurde gut umgesetzt, und so stellten sie nicht nur eine Steigerung der Suchgenauigkeit fest, sondern auch eine deutliche Lastreduktion in der Infrastruktur bei der Vollsuche. Wonach Nutzer suchen, folgt häufig einer Zipfschen Verteilung: In der Regel machen 10&nbsp;% der eindeutigen Suchen 90&nbsp;% des Suchvolumens aus. Daher ist es sehr wahrscheinlich, dass die vollständigen Ergebnisse für den besten Suchvorschlag bereits im Cache (in Ihrer Anwendungsebene) gespeichert sind und „sofort“ angezeigt werden können.</p>
  <p>Ein großer Teil der Entwicklungsarbeit hinter dem Suche-Suggester von Soundcloud führt zu den Suggester-Funktionen von Elasticsearch. Es gibt eine tolle Präsentation von Muir und Willauer zu <a href="https://www.youtube.com/watch?v=XrssyUPQcG4">Abfragevorschläge bei Lucene</a>, die weitere Informationen enthält.</p>
</section>
<section id="multi-tenancy" class="level2">
  <h2><a href="#multi-tenancy">Mehrere Instanzen</a></h2>
  <p>Häufig haben Sie mehrere Kunden oder Nutzer mit separaten Dokumentensammlungen, und ein Nutzer sollte niemals Dokumente durchsuchen können, die ihm nicht gehören. Dies führt häufig zu einem Design, bei dem jeder Nutzer seinen eigenen Index besitzt.</p>
  <p>In den meisten Fällen resultieren daraus viel zu viele Indizes. In <em>fast</em> allen Fällen wird ein Index pro Nutzer implementiert, obwohl ein großer Elasticsearch-Index in der Tat besser wäre. Eine große Anzahl an kleinen Indizes bringt erhebliche Nachteile mit sich:</p>
  <ul>
    <li>Der Arbeitsspeicher-Overhead ist nicht unerheblich. Tausende kleiner Indizes verbrauchen viel Heap-Speicher. Die Anzahl der Dateideskriptoren kann ebenfalls rasant steigen.</li>
    <li>Es kann viele Duplikate geben. Bedenken Sie, <a href="/de/blog/found-elasticsearch-from-the-bottom-up">wie der invertierte Index funktioniert</a>, und wie Lucene Inhalte in Segmente schreibt und komprimiert.</li>
    <li>Snapshot/Wiederherstellen ist aktuell ein serieller Prozess mit einem Overhead je Index. Die Snapshot-Erstellung dauert bei Tausenden kleiner Indizes erheblich länger als bei wenigen großen Indizes.</li>
  </ul>
  <p>In <a href="/de/blog/found-sizing-elasticsearch#data-flows-and-their-partitioning-strategies">Dimensionierung von Elasticsearch</a> finden Sie weitere Informationen zu Sharding- und Partitionierungsstrategien sowie einige weitere Referenzen. Die Überarbeitung einer Anwendung mit suboptimalem Index kann großen Aufwand mit sich bringen&nbsp;– daher lohnt es sich, die verschiedenen Ansätze kennenzulernen.</p>
  <blockquote>Sie sollten also für Ihre Multi-Instanz-Anwendung nicht einen Index pro Nutzer vergeben.</blockquote>
</section>
<section id="schema-free-user-defined-schemas" class="level2">
  <h2><a href="#schema-free-user-defined-schemas">Ohne Schema/Nutzerdefinierte Schemata</a></h2>
  <p>Mit vielen verschiedenen Kunden entstehen viele Anwendungsfälle, bei denen unterschiedliche Nutzer möglicherweise mit komplett unterschiedlichen Dokumenten arbeiten. Wenn Sie beispielsweise einen Dienst für Nutzerumfragen/Fragebögen anbieten, ist es wahrscheinlich, dass unterschiedliche Umfragen komplett unterschiedliche Felder haben.</p>
  <p>Daraus resultiert häufig die Verwendung des „dynamischen Mappings“ von Elasticsearch, das manchmal als schemalos beworben wird. Elasticsearch erstellt im Hintergrund ein Mapping für Sie, und es kann problematisch werden, wenn dieses zu groß wird und es zu einer „<a href="/de/blog/found-crash-elasticsearch#mapping-explosion">Mapping-Explosion</a>“ kommt. Stattdessen ist es wichtig, sicherzustellen, dass Werte in einem Dokument auch Werte bleiben&nbsp;– und nicht zu separaten Feldern werden. Darauf wird in „<a href="/de/blog/found-beginner-troubleshooting#keyvalue-woes">Schwierigkeiten mit Keys/Werten</a>“.</p>
  <p>Elasticsearch hat vielseitige Mapping-Fähigkeiten mit <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-templates.html">Indexvorlagen</a>, <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-root-object-type.html#_dynamic_templates">dynamischen Vorlagen</a>, <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-core-types.html#_multi_fields_3">Multifeldern</a> und mehr. Nutzen Sie diese!</p>
  <blockquote>Auch wenn Sie kein Mapping verwenden, sollten Sie wissen, welche Möglichkeiten das Mapping von Elasticsearch für Sie bietet.</blockquote>
</section>
<section id="user-defined-searches" class="level2">
  <h2><a href="#user-defined-searches">Nutzerdefinierte Suchen</a></h2>
  <p>Mit nutzerdefinierten Modellen geht oft die Notwendigkeit einher, Endnutzern die Möglichkeit zu geben, ihre eigenen Suchen mit Filtern, Scoring und Aggregationen zu definieren. Ein gängiger Ansatz besteht darin, die Suchanfrage auf bestimmte Indizes zu begrenzen und/oder die Nutzerabfrage mit Filtern zu versehen.</p>
  <p>Doch auch unter diesen Umständen gibt es mehrere Wege, wie ein Nutzer mit nutzerdefinierten Suchanfragen Schaden anrichten kann, z.&nbsp;B. durch CPU-intensive Suchen, Memory Hogging oder indem Elasticsearch zum Absturz gebracht wird. Diese Themen werden in <a href="/de/blog/found-crash-elasticsearch">Sechs Wege, wie Elasticsearch zum Absturz gebracht wird</a> und <a href="/de/blog/found-elasticsearch-security">Absichern Ihrer Elasticsearch-Cluster</a> behandelt.</p>
  <blockquote>Seien Sie bei nutzerdefinierten Suchanfragen achtsam.</blockquote>
</section>
<section id="crawling-and-document-processing" class="level2">
  <h2><a href="#crawling-and-document-processing">Crawling und Verarbeitung von Dokumenten</a></h2>
  <p>Es gibt viele Wege, Ihre Daten in Elasticsearch einzuspeisen.</p>
  <p>Ein River ist ein Elasticsearch-Konzept, bei dem Elasticsearch Daten aus einer Quelle wie einer Datenbank durch JDBC, eine Nachrichtenwarteschlange, einen Twitter-Stream oder das Crawling von Websites gewinnt. Die ersten Schritte damit sind relativ einfach, doch der Ansatz ist schwer skalierbar und in der Praxis einzusetzen. River als solche sind veraltet, und diese Probleme sollten <em>außerhalb</em> von Elasticsearch gelöst werden. <a href="/de/logstash">Logstash</a> bietet Support für immer mehr Systeme und kann viele River ersetzen. Für nutzerdefinierte Anwendungen bestehen genügend Herausforderungen beim <a href="/de/blog/found-keeping-elasticsearch-in-sync">Synchronisieren von Daten zu Elasticsearch</a> und <a href="/de/blog/found-document-processing">Vorbereiten von Elasticsearch-Dokumenten</a>, sodass etwas Simples und Generisches wie River nicht als ausreichende Lösung betrachtet werden sollten. Was Crawling betrifft, werden <a href="http://blog.florian-hopf.de/2014/07/scrapy-and-elasticsearch.html">Scrapy</a> und <a href="http://nutch.apache.org/">Nutch</a> in Kombination mit Elasticsearch verwendet.</p>
  <p>Ähnliches gilt für die Verarbeitung und Konvertierung von Dokumenten wie Word-Dateien oder PDFs in einfachen Text, den Elasticsearch indexieren kann. Es gibt ein „mapper-attachments“-Plugin, das für diese Konvertierung in Elasticsearch verwendet werden kann. Doch auch wenn das Plugin für Anhänge praktisch ist, empfehlen wir, die Dokumentenkonvertierung <em>vor</em> dem Versenden der Dokumente an Elasticsearch durchzuführen. Damit haben Sie die bestmögliche <a href="/de/blog/found-document-processing#external-systems-and-pipelines">Kontrolle darüber, wie Dokumente konvertiert und ausgewählt werden</a>. Eine solche Dokumentenkonvertierung ist in der Regel einer der ersten Schritte des „Content Refinement“ in der Dokument-/Textverarbeitungspipeline. Die Dokumente, die Sie an Elasticsearch senden, sollten das Ergebnis dieses „Content Refinement“ bzw. dieser „Vorbereitung“ sein, sodass Elasticsearch die finale Textverarbeitung und das Indexieren übernehmen kann. Die Dokumentkonvertierung ist relativ CPU-intensiv, jedoch leicht parallelisierbar. Es ist empfehlenswert, Elasticsearch zunächst Zeit für das Indexieren und Suchen zu geben und „Upstream“-Kunden die Dokumentenkonvertierung zu überlassen.</p>
  <blockquote>Speisen Sie verarbeitete Daten in Elasticsearch ein, rufen Sie nichts aus Elasticsearch ab und verarbeiten Sie nichts innerhalb von Elasticsearch.</blockquote>
</section>
<section id="summary" class="level2">
  <h2><a href="#summary">Zusammenfassung</a></h2>
  <p>Es gibt viel zu lernen über Elasticsearch, und manchmal ist es nicht leicht, das zu identifizieren, was man <em>braucht</em>.</p>
  <p>In diesem Artikel haben wir einige gewöhnliche Anwendungsfälle und wichtige Punkte besprochen, die es zu beachten gilt. Wir hoffen, dass Sie für Ihren Bedarf etwas Neues mitnehmen konnten und Ihre Elasticsearch-Anwendung bald in die Produktion gehen kann.</p>
</section>

Uses of Elasticsearch, and Things to Learn

Anwendungsfälle von Elasticsearch und neue Lerninhalte

Elasticsearch from the Bottom Up, Part 1

Elasticsearch von unten nach oben, Teil 1

<p><strong>AKTUALISIERUNG:</strong> In diesem Artikel wird für unser gehostetes Elasticsearch-Angebot noch sein früherer Name „Found“ verwendet. „Found“ heißt heute „Elastic Cloud“. <a href="https://www.elastic.co/de/cloud/as-a-service/signup">Sie können Elasticsearch auf Elastic Cloud 14 Tage lang kostenlos ausprobieren.</a></p><p>Kann Elasticsearch als „NoSQL“-Datenbank eingesetzt werden? Der Begriff „NoSQL“ hat je nach Kontext unterschiedliche Bedeutungen und zudem kurioserweise nicht wirklich etwas mit SQL zu tun. Unsere Antwort auf die Frage ist ein herzhaftes „vielleicht!“. Um das näher zu erläutern, sehen wir uns zunächst die verschiedenen Eigenschaften von Elasticsearch an und werfen einen Blick auf die Kompromisse, die wir eingehen mussten, um Elasticsearch zu einer der flexibelsten, skalierbarsten und performantesten Such- und Analyse-Engines zu machen.
</p><section id="what-is-a-nosql-database-anyway" class="level2">
<h2><a href="#what-is-a-nosql-database-anyway">Was ist eigentlich eine „NoSQL-Datenbank“?</a></h2>
<p><a href="http://nosql-database.org/">NoSQL-Database.org</a> definiert NoSQL als „Datenbanken der nächsten Generation, auf die <em>im Wesentlichen</em> <em>einige</em> der folgenden Punkte zutreffen: nicht-relational, verteilt, Open Source und horizontal skalierbar.“ Wie Sie sehen, ist das keine sehr präzise Definition.
</p>
<p>Es geht auch nicht um SQL im Besonderen. So ist zum Beispiel die Abfragesprache für <a href="http://hive.apache.org/">Hive</a> klar von SQL inspiriert, wie auch die Abfragesprache für <a href="http://esper.codehaus.org/">Esper</a>, die statt mit Relationen mit Streams arbeitet. Und wussten Sie schon, dass PostgreSQL ursprünglich „Postgres“ hieß und die zugehörige Abfragesprache „Quel“ war? Was einmal vor allem als ORDBMS begann, hat heute viele <a href="http://thebuild.com/blog/2013/07/02/postgresql-as-a-nosql-database/">Funktionen, die den Einsatz als schemaloser Dokumentspeicher ermöglichen</a>.
</p>
<p>Auch die ACID-Fähigkeit spielt hier keine Rolle. Ein Beispiel für eine NoSQL-Datenbank, deren Ziel es ist, ACID-Transaktionen bereitzustellen, ist <a href="http://hyperdex.org/">Hyperdex</a>. Und MySQL – unzweifelhaft eine SQL-Datenbank – hat sich in der Vergangenheit mit einer Reihe von zweifelhaften Auslegungen von ACID hervorgetan.
</p>
<p>Relationen? Während die meisten NoSQL-Datenbanken keine Unterstützung für das Verbinden von Tabellen („Joining“) in dem Sinne bieten, wie es bei herkömmlichen relationalen Datenbanken gang und gäbe ist, und die Umsetzung den eigentlichen Nutzerinnen und Nutzern überlassen, gibt es doch auch hier ein paar Ausnahmen, wie beispielsweise <a href="http://www.rethinkdb.com/">RethinkDB</a>, <a href="http://hive.apache.org/">Hive</a> und <a href="http://pig.apache.org/">Pig</a>. <a href="http://www.neo4j.org/">Neo4j</a>, eine Graphdatenbank, weiß mit Relationen umzugehen und ist besonders gut darin, Relationen (Kanten) in Graphen zu durchlaufen. Bei Elasticsearch gibt es das Konzept des Verbindens beim Abfragen mit <a href="/guide/reference/mapping/parent-field">Eltern/Kind-Relationen</a> und des Verbindens beim Indexieren mit <a href="/guide/reference/mapping/nested-type">verschachtelten Typen</a>.
</p>
<p>Verteilt? Auch wenn es ein paar verteilte SQL-Datenbanken und <a href="https://github.com/petersirka/nosql">einige wenige</a> <a href="http://ejdb.org/">Projekte</a> gibt, die so etwas wie ein NoSQLite darstellen, sind neuere Datenbanken in der Regel in irgendeiner Form verteilt konzipiert.
</p>
<p>Zusammenfassend lässt sich sagen, dass es weder viel bringt, NoSQL präzise zu definieren, noch einfach zu postulieren, dass Elasticsearch eine „Dokumentspeicher“-artige NoSQL-Datenbank sei. Während ich das hier schreibe, werden bei <a href="http://nosql-database.org/">nosql-database.org</a> mehr als 20 davon aufgeführt.
</p>
<p>In den folgenden Abschnitten sehen wir uns einige wichtige Eigenschaften an und untersuchen, wie Elasticsearch diese implementiert (oder eben nicht).
</p>
</section><section id="transactions" class="level2">
<h2><a href="#transactions">Keine Transaktionen</a></h2>
<p>Lucene, das die Grundlage für Elasticsearch bildet, arbeitet mit Transaktionen. Bei Elasticsearch kommen jedoch keine Transaktionen im herkömmlichen Sinne zum Einsatz. Es gibt keine Möglichkeit für ein „Rollback“ eines einmal gesendeten Dokuments, und es ist auch nicht möglich, eine Gruppe von Dokumenten zu senden und entweder alle oder keines von ihnen indexieren zu lassen. Es gibt jedoch ein „Write-ahead-Log“, das für die Dauerhaftigkeit der Operationen sorgt, ohne dass dafür ein aufwendiger Lucene-Commit nötig wäre. Außerdem lässt sich das Konsistenzlevel der Indexoperationen festlegen, indem angegeben wird, wie viele Replikas die Operation quittieren müssen, bevor etwas zurückgegeben wird. Standardmäßig ist dies ein Quorum, das heißt <span class="math">\(\lfloor\frac{n}{2}\rfloor + 1\)</span>.
</p>
<p>Die Sichtbarkeit von Änderungen wird über die Indexaktualisierung gesteuert, die standardmäßig sekündlich und Shard für Shard stattfindet.
</p>
<p>Die optimistische Gleichzeitigkeitssteuerung erfolgt durch Angabe der Version der gesendeten Dokumente.
</p>
<p>Elasticsearch ist geschwindigkeitsorientiert. Die Verarbeitung verteilter Transaktionen ist <em>sehr aufwendig</em>. Wenn diese Transaktionen wegfallen, wird vieles viel einfacher. Als Gegenleistung dafür, dass wir akzeptieren, dass das, was wir lesen, mitunter nicht dem allerneuesten Stand entspricht, und dass alle denselben Zeitraum sehen, kann Elasticsearch vieles aus Caches bereitstellen – und so die schwindelerregende Performance bieten, für die wir Elasticsearch lieben.
</p>
</section><section id="schema-flexible" class="level2">
<h2><a href="#schema-flexible">Schemaflexibel</a></h2>
<p>Bei Elasticsearch ist es nicht <em>erforderlich</em>, vorab ein Schema anzugeben. Wenn Sie Elasticsearch ein JSON-Dokument geben, versucht es, eigenständig den Dokumenttyp zu erkennen. Bei numerischen und booleschen Ausdrücken sowie bei Zeitstempeln funktioniert das sehr gut. Bei Zeichenfolgen (Strings) kommt der „Standard“-Analyzer zum Einsatz, der in der Regel gute Ausgangsergebnisse liefert.
</p>
<p>Natürlich ist Elasticsearch in einem gewissen Sinne „schemafrei“, weil kein Schema angegeben werden <em>muss</em>, aber wir ziehen den Begriff „schema<em>flexibel</em>“ vor. Für wirklich gute Suche- und/oder Analytics-Anwendungen kommt man nicht umhin, die Schemas entsprechend anzupassen. Elasticsearch verfügt zu diesem Zweck über ein umfangreiches Arsenal an leistungsfähigen Tools, wie dynamische Vorlagen, Mehrfeldobjekte und mehr. Das wird ausführlicher in unserem Artikel zum Thema „Mapping“ besprochen.
</p>
</section><section id="relations-and-constraints" class="level2">
<h2><a href="#relations-and-constraints">Relationen und Constraints</a></h2>
<p>Elasticsearch ist eine dokumentorientierte Datenbank. Der gesamte Objektgraph, der durchsucht werden soll, muss indexiert worden sein. Das heißt, dass Ihre Dokumente vor dem Indexieren <em>denormalisiert</em> werden müssen. Die Denormalisierung sorgt zwar für eine höhere Abfragegeschwindigkeit (denn das Verbinden beim Abfragen entfällt), erhöht aber den Platzbedarf (da Daten mehrfach gespeichert werden müssen) und erschwert es, Daten konsistent und aktuell zu halten (da jede Änderung auf alle Instanzen angewendet werden muss). Dieser Ansatz eignet sich aber ausgezeichnet für „Write-once-read-many“-Workloads.
</p>
<p>Nehmen wir zum Beispiel an, Sie haben eine Datenbank mit Kunden, Bestellungen und Produkten und Sie möchten anhand des Namens eines Produkts und eines Kunden nach Bestellungen suchen. Dies ließe sich lösen, indem die Bestellungen mit allen erforderlichen Informationen über den Kunden und die Produkte indexiert werden. Die Daten können dann unkompliziert durchsucht werden. Aber was, wenn Sie den Namen des Produkts ändern möchten? In einem relationalen Design mit richtiger Normalisierung würde es reichen, einfach das Produkt zu aktualisieren – voilà! Hier können relationale Datenbanken ihre Vorteile voll ausspielen. In einer Datenbank mit denormalisierten Dokumenten müsste jedoch jede Bestellung, die dieses Produkt enthält, einzeln aktualisiert werden.
</p>
<p>Mit anderen Worten: Bei dokumentorientierten Datenbanken, wie Elasticsearch eine ist, gestalten wir unsere Mappings und speichern wir unsere Dokumente so, dass sie leichter gefunden und abgerufen werden können.
</p>
<p>Wie bereits oben erwähnt, gibt es bei Elasticsearch das Konzept des Verbindens beim Abfragen mit <a href="/guide/reference/mapping/parent-field">Eltern/Kind-Relationen</a> und des Verbindens beim Indexieren mit <a href="/guide/reference/mapping/nested-type">verschachtelten Typen</a>. Darauf werden wir wahrscheinlich in einem späteren Artikel genauer eingehen. Bis dahin empfehlen wir <a href="/de/videos/bbuzz2013-document-relations-with-elasticsearch">Martijn van Groningens Präsentation „Document relations with Elasticsearch“</a>.
</p>
<p>Die meisten relationalen Datenbanken ermöglichen auch die Angaben von Constraints, um definieren zu können, was als konsistent zu betrachten ist und was nicht. So können Sie beispielsweise die referenzielle Integrität und Eindeutigkeit zu einer Zwangsbedingung machen und unter anderem festlegen, dass die Summe der Kontobewegungen positiv sein muss. Bei dokumentorientierten Datenbanken ist dies in der Regel nicht der Fall; Elasticsearch bildet da keine Ausnahme.
</p>
</section><section id="robustness" class="level2">
<h2><a href="#robustness">Robustheit</a></h2>
<p>Eine Datenbank sollte robust sein, vor allem dann, wenn sie als maßgebliches Datensystem dient. Im Idealfall sollte es möglich sein, eine kostenaufwendige Abfrage abzubrechen, und die Datenbank darf nicht einfach so und unaufgefordert den Dienst einstellen.
</p>
<p>Leider gibt es bei Elasticsearch (und den Komponenten, aus denen es besteht) derzeit noch Defizite beim Umgang mit <code>OutOfMemory</code>-Fehlern. Mehr zu diesem Thema finden Sie unter „<a href="/de/blog/found-elasticsearch-in-production">Elasticsearch in Produktionsumgebungen, Abstürze wegen fehlendem Arbeitsspeicher</a>“. Es ist sehr wichtig, Elasticsearch genügend Arbeitsspeicher zur Verfügung zu stellen und bei Suchanfragen mit unbekannten Arbeitsspeicheranforderungen in einem Produktions-Cluster Vorsicht walten zu lassen.
</p>
<p>Das wird sich sicherlich im Laufe der Zeit bessern, aber Sie sollten bedenken, dass Elasticsearch <em>geschwindigkeitsorientiert</em> konzipiert ist und davon ausgegangen wird, dass der Arbeitsspeicher großzügig bemessen ist.
</p>
</section><section id="distributed" class="level2">
<h2><a href="#distributed">Verteilt</a></h2>
<p>Siehe auch „<a href="/de/elasticsearch">Elasticsearch in Produktionsumgebungen, Netzwerke</a>“.
</p>
<p>Bevor Shay Banon Elasticsearch auf die Beine gestellt hat, hatte er an <a href="https://thedudeabides.com/articles/the_future_of_compass">Compass</a> gearbeitet. Da er irgendwann verstand, wie kompliziert es werden würde, Compass in eine verteilte Suchmaschine zu verwandeln, begann er ganz von vorn und entwickelte Elasticsearch<span class="citation" data-cites="future-of-compass"><a href="#fn1" class="footnoteRef" id="fnref1"><sup>1</sup></a></span>. Elasticsearch ist schon durch sein Design verteilt und einfach <em>aus</em>skalierbar, um auch mit sehr großen Datenbeständen auf Commodity-Hardware klarzukommen.
</p>
<p>Für ein verteiltes System ist das Produkt unglaublich einfach zu bedienen und zu erlernen – dennoch sind verteilte Systeme inhärent <em>kompliziert</em>. Wir besprechen das ausführlicher in „<a href="/de/blog/found-elasticsearch-in-production">Elasticsearch in Produktionsumgebungen, Netzwerke</a>“ und geben hier nur einen kurzen Überblick.
</p>
<p>Bei verteilten Systemen kann von Natur aus Etliches schieflaufen. Jedes Datenbanksystem hat seine eigenen Stärken, auf die es sich konzentriert: Einige streben nach starken Garantien, andere nach ständiger Verfügbarkeit, auch wenn das streckenweise (oder sogar meistens) mit erhöhter Fehleranfälligkeit verbunden ist. Hinzu kommt, dass das, was ein Datenbanksystem <em>vorgibt</em>, erreichen zu können, selten das ist, womit es <em>tatsächlich</em> zu tun hat, wie <a href="http://aphyr.com/">Kyle Kingsbury</a> in seiner exzellenten <a href="http://aphyr.com/posts/281-call-me-maybe-carly-rae-jepsen-and-the-perils-of-network-partitions">Artikelreihe zu den Tücken von Netzwerkpartitionen</a> dargelegt hat und in der er, kurz gesagt, feststellt, dass verteilte Datenbanken zwar bei gutem Wetter gut funktionieren, aber meistens ins Straucheln kommen, wenn <a href="http://aphyr.com/posts/288-the-network-is-reliable">das viele, was schiefgehen kann</a>, auch wirklich schiefgeht.
</p>
<p>Aus Sicht der Konsistenz, Verfügbarkeit und Partitionstoleranz ist Elasticsearch ein CP-System, legt man einen recht schwachen Maßstab für „konsistent“ an. Bei einer Read-only-Workload ermöglicht Elasticsearch AP-Verhalten, indem es die Mindestzahl von Master-Knoten lockerer handhabt, das heißt, es wird kein Quorum gefordert. In der Regel muss jedoch die Mehrzahl der Knoten im Cluster verfügbar sein. Werden Daten ohne diese Mehrheit in einen fehlerhaft konfigurierten Cluster – einen „Split-Brain“-Cluster – geschrieben, können die Daten unwiederbringlich verloren sein. Damit steht Elasticsearch in keiner Weise allein da.
</p>
<p>Aus Skalierungssicht ist ein Index in eine oder mehrere Shards aufgeteilt. Diese Aufteilung erfolgt bei der Indexerstellung und kann nachträglich nicht mehr geändert werden. Das bedeutet, dass bei der Festlegung der Shards das voraussichtliche Wachstum berücksichtigt werden muss. Wenn dem Elasticsearch-Cluster dann weitere Knoten hinzugefügt werden, werden diese automatisch neu zugeordnet und umgeschichtet. Das funktioniert recht gut. Elasticsearch ist also sehr einfach ausskalierbar.
</p>
</section><section id="security" class="level2">
<h2><a href="#security">Security</a></h2>
<p>Siehe auch „<a href="/de/security">Elasticsearch in Produktionsumgebungen, Security</a>“.
</p>
<p>Elasticsearch verfügt über keinerlei Funktionen zur Authentifizierung oder Autorisierung. Sie sollten davon ausgehen, dass jede oder jeder, der eine Verbindung mit Ihrem Elasticsearch-Cluster herstellen kann, „Superuser“-Rechte hat, vor allem dann, wenn die leistungsfähigen Scripting-Funktionen von Elasticsearch aktiviert sind.
</p>
</section><section id="summary" class="level2">
<h2><a href="#summary">Zusammenfassung</a></h2>
<p>Es ist zweifelsohne möglich, Elasticsearch als primären Speicher zu verwenden, wenn man mit den beschriebenen Einschränkungen leben kann. Ein gutes Beispiel wäre die Nutzung von <a href="/de/logstash">Logstash</a>. Logstash ist ein fantastisches Tool für die Verwaltung von Logdaten und für das Importieren dieser Daten in Elasticsearch oder auch das Archivieren an einem anderen Ort, falls erforderlich. Logdaten werden einmal geschrieben und häufig gelesen („Write once, read-many“). Sie werden nicht aktualisiert und es gibt weder Bedarf für Transaktionen noch für Integritäts-Constraints und dergleichen.
</p>
<p>Wie steht es aber mit Systemen wie Postgres, die eine <a href="http://www.postgresql.org/docs/current/static/textsearch.html">Volltextsuche</a> <em>und</em> ACID-Transaktionen mit sich bringen? (Andere Beispiele wären die Volltextfunktionen von MySQL, MongoDB, Riak und so weiter) Mit Postgres lassen sich zwar grundlegende Suchfunktionen implementieren, aber die Lücke bei der möglichen Performance und bei den Funktionen ist gewaltig. Wie im <a href="#transactions">Abschnitt zu Transaktionen</a> erwähnt, kann Elasticsearch „schummeln“ und ziemlich viel Caching betreiben, ohne dass dabei so etwas Kompliziertes wie beispielsweise die Steuerung der Gleichzeitigkeit mehrerer Versionen eine Rolle spielt. Die Suche beinhaltet mehr als das Finden eines bestimmten Suchbegriffs in einem Text: Es geht auch darum, domänenspezifisches Wissen anzuwenden, um gute Relevanzmodelle zu implementieren, einen Überblick über die Gesamtheit der Ergebnisse zu geben und Dinge wie Rechtschreibprüfung und automatische Vervollständigung durchzuführen. Und das alles <em>schnell</em>.
</p>
<p>Elasticsearch wird in der Regel <em>zusätzlich</em> zu einer anderen Datenbank verwendet. Der Master-Datensatz ist in einem Datenbanksystem mit stärkerem Fokus auf Constraints, Korrektheit und Robustheit sowie auf einfache transaktionale Aktualisierbarkeit gespeichert und wird asynchron an Elasticsearch „gepusht“. (Oder „gepullt“, wenn Sie mit einem der „Rivers“ von Elasticsearch arbeiten.) Darauf, wie das Ganze synchronisiert gehalten werden kann, werden wir in einem künftigen Artikel näher eingehen. Hier bei Found nutzen wir in der Regel PostgreSQL und ZooKeeper als <i>Keeper of Truths</i>, die wir in Elasticsearch einspeisen, um ein gutes Sucherlebnis zu ermöglichen.
</p>
<p>Wie überall im Leben gibt es aber nicht die eine Lösung, die für alles passt, nicht die eine Datenbank, die alle anderen überflüssig macht. Da sich daran wohl nie etwas ändern wird, sollten Sie die Stärken und Schwächen Ihrer Datenspeicher genau kennen!
</p>
<div class="references">
	<h2><a href="/">Referenzen</a></h2>
	<p>Banon, Shay: <em>The Future of Compass & Elasticsearch</em> – <a href="https://thedudeabides.com/articles/the_future_of_compass">https://thedudeabides.com/articles/the_future_of_compass</a>
	</p>
</div>
</section><section class="footnotes">
<hr>
<ol>
	<li id="fn1">Shay Banon, <em>The Future of Compass & Elasticsearch</em> – <a href="https://thedudeabides.com/articles/the_future_of_compass">https://thedudeabides.com/articles/the_future_of_compass</a>.<a href="#fnref1">↩</a></li>
</ol>
</section>

Elasticsearch as a NoSQL Database

Elasticsearch als NoSQL-Datenbank

Start free trial

Blog Footer CTA

Sign up for Elastic Cloud free trial

Elastic Cloud Creator & Tech Lead

Alex Brasetvik

<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 Alex Brasetvik

Elastic Cloud Creator & Tech Lead, Elastic

Anwendungsfälle von Elasticsearch und neue Lerninhalte

Elasticsearch von unten nach oben, Teil 1

Elasticsearch als NoSQL-Datenbank