Gesucht, gefunden. Elasticsearch [a] verfolgt den Ansatz der horizontalen Skalierbarkeit, Patrick Peschlow. Elasticsearch erfolgreich skalieren

Transkript

1 Elasticsearch erfolgreich skalieren Gesucht, gefunden Patrick Peschlow Der Suchserver Elasticsearch gilt als eine der Big-Data-Suchtechniken schlechthin und lockt mit Skalierung out of the box. Auf dem Weg zu einer optimalen Suchper - formance verbergen sich jedoch einige Fallstricke und Möglichkeiten zur Optimierung. Welche Fähigkeiten zur Skalierung bietet Elasticsearch und wie lässt sich damit eine performante verteilte Suchlösung realisieren? Elasticsearch [a] verfolgt den Ansatz der horizontalen Skalierbarkeit, bei dem höhere Kapazität durch das Einbinden weiterer, relativ preisgünstiger Server erreicht wird. Sie setzt voraus, dass man die bank in diesem Fall der Suchindex in disjunkte Partitionen aufteilt, die auf die verschiedenen Server verteilt werden. Elasticsearch verwendet zur Partitionierung den Sharding-Ansatz, bei dem der Index in sogenannte Shards aufgeteilt wird. Für die zu indizierenden Dokumente bestimmt ein Attribut, der Shard Key, in welchem Shard das jeweilige Dokument zu speichern ist. Standardmäßig verwendet Elasticsearch die Dokumenten-ID als Shard Key. Sharding hat folgende Vorteile: Ein Index lässt sich auf mehrere Server verteilen, wodurch man nahezu beliebig große Indizes realisieren kann. Operationen auf einzelnen Dokumenten (Indizieren, Aktualisieren, Löschen, Auslesen) werden parallelisiert, da jeder Server alle Anfragen für Dokumente seiner Shards verarbeitet. Implikationen von Sharding sind: Der Shard Key ist bei Operationen auf einzelnen Dokumenten stets mitzusenden, um den richtigen Shard zur Verarbeitung zu identifizieren. Suchanfragen werden verteilt durchgeführt, da alle Shards relevante Dokumente besitzen können. Eine fundamentale Einschränkung bei Elasticsearch ist, dass sich die Anzahl Shards eines Index nach seiner Erstellung nicht mehr verändern lässt. Es gibt also kein Shard Splitting, wie das beim Konkurrenten Apache Solrˇ[b] der Fall ist. Stattdessen empfehlen die Elasticsearch-Entwickler eine hinreichende Anzahl Shards durch Vorabmessungen mit realistischem aufkommen zu ermitteln. Die Anzahl sollte dann ein wenig höher gewählt werden, als die Messung suggeriert, um einen gewissen Spielraum für unerwartet große mengen zu haben. Ein Vorgehen bei der Messung und die Motivation für den Verzicht auf Shard Splitting sind in der Dokumentationˇ[c] erläutert. Ausfallsicherheit durch Replikation In einem verteilten System ist es wichtig, dass nicht verloren gehen, wenn nur eine oder wenige Komponenten ausfallen. Elasticsearch bietet Ausfallsicherheit durch die Replikation von Shards: Jeder Shard liegt in N-facher Ausfertigung vor. Eine der N Kopien ist als Primary Shard (kurz: Primary) ausgezeichnet und nimmt Index-Operationen entgegen, die im Anschluss auch auf den anderen Kopien, den Replica Shards (kurz: Replicas), durchgeführt werden. Fällt der Primary aus, springt einer der Replicas ein und wird zum neuen Primary befördert. Replikation hat folgende Vorteile: Bei Ausfall eines Primary ist ein Failover möglich. Suchanfragen lassen sich parallelisieren, da mehrere Kopien der vorliegen, um sie zu beantworten. Implikationen von Replikation sind: Index-Operationen beanspruchen mehr Ressourcen, da sie auf allen Kopien des jeweiligen Shards ausgeführt werden. Es können sich gegebenenfalls Inkonsistenzen bei Lesezugriffen auf verschiedene Kopien desselben Shards ergeben. 110 ix Developer 2015 Big Data

2 Cluster Die gewünschte Anzahl der Replicas wird bei Elasticsearch genau wie die der Primaries auf Index-Ebene festgelegt. Allerdings ist die Replicas-Anzahl dynamisch änderbar und lässt sich jederzeit erhöhen oder reduzieren. Nutzer (In-)Konsistenz von Suchergebnissen und Verteilung von Shards auf Server Die Indizierung auf Replicas erfolgt nicht exakt synchron zum Primary, sodass theoretisch Inkonsistenzen auftreten können, wenn Replicas an der Beantwortung von Suchanfragen teilnehmen. So könnte zu einem bestimmten Zeitpunkt Replica A das Dokument bereits indiziert haben, während Replica B noch darauf wartet. Landet nun die gleiche Suchanfrage innerhalb kurzer Zeit einmal bei Replica A und einmal bei Replica B, sieht es für den Benutzer so aus, als wäre das Dokument zunächst vorhanden und dann wieder gelöscht worden. Allerdings besteht diese Gefahr für jedes Dokument maximal so lange, wie das Refresh-Intervallˇ[d] definiert ist. Da dieses standardmäßig bei einer Sekunde liegt, werden solche Inkonsistenzen in der Praxis nur selten auffallen. Es gibt leider einen verwandten Effekt, der wesentlich unschöner ist und mit der Löschung von Dokumenten zusammenhängt. Elasticsearch verwendet intern die Information-Retrieval- Bibliothek Luceneˇ[e], die Dokumente aus Performancegründen zunächst logisch und gegebenenfalls erst viel später physikalisch löscht. Entfernte Dokumente tragen jedoch weiterhin zu bestimmten Index-Statistiken bei, die bei der Berechnung der Relevanz (Qualität eines Suchtreffers) von Dokumenten berücksichtigt werden. Für sich betrachtet stellt diese leichte Verfälschung der Relevanz durch logisch gelöschte Dokumente kein Problem dar; der Knackpunkt im Zusammenspiel mit Replicas ist jedoch, dass die physikalische Löschung auf diesen zu völlig unterschiedlichen Zeitpunkten stattfinden kann. Stellt ein Benutzer nun N-mal hintereinander die gleiche Suchanfrage, kann es passieren, dass die Antworten zwar die gleichen Treffer, aber in jeweils unterschiedlicher Reihenfolge enthalten, je nachdem bei welchem der N Replicas die Anfrage gelandet ist. Bleibt dieses Verhalten womöglich über Stunden hinweg so bestehen, kann das für Benutzer höchst irritierend sein. Glücklicherweise bietet Elasticsearch die Möglichkeit, den beschriebenen Effekt durch Nutzung des preference-parametersˇ[f] bei Suchanfragen zu umgehen. Er schränkt den Empfänger der Suchanfrage auf einen oder mehrere definierte Shards ein. Zum Beispiel kann man festlegen, dass die Suchanfrage anhand eines beliebigen String-Werts stets zum selben Shard geleitet wird, ähnlich zum Shard Key bei der Indizierung. Um zu erreichen, dass ein Benutzer konsistente Suchergebnisse erhält, Primary 1 Replica 2 Replica 3 Primary 2 Primary 3 Replica 1 Ein Index mit drei Primaries und jeweils einem Replica. Die Shards sind auf zwei Knoten verteilt, wobei sich ein Primary und der dazugehörige Replica stets auf verschiedenen Knoten befinden (Abb.ˇ1). Ein Cluster mit zwei - und drei -Knoten (Abb.ˇ2) kann man also etwa die Benutzer-ID als preference-parameter verwenden. Alle Suchanfragen des Benutzers landen dann immer beim selben Replica (bzw. bei verteilten Suchanfragen immer bei denselben Replicas aller Shards des Index). Serverprozesse bei Elasticsearch werden als Knoten bezeichnet. Ein Knoten ist einem Server fest zugewiesen und kann Shards beliebiger Indizes beherbergen. Die Zuweisung von Shards zu Knoten ist dabei flexibel und lässt sich dynamisch anpassen. Standardmäßig entscheidet Elasticsearch autonom, welcher Shard sich auf welchem Knoten befindet. Bevorzugt legt es alle Kopien eines Shard auf unterschiedlichen Knoten an, um die Ausfallsicherheit zu maximieren. Die Abbildungˇ1 zeigt einen Index bestehend aus drei Primaries mit jeweils einem Replica, die auf zwei Knoten verteilt sind. Ein Primary und der dazugehörige Replica befinden sich dabei auf verschiedenen Knoten. Optional lassen sich Regeln konfigurieren, mit denen man die Verteilung beeinflussen kann. Allocation Awarenessˇ[g] erlaubt die Definition von Knotengruppen, um zu erreichen, dass sich nicht alle Kopien eines Shards in derselben Gruppe befinden. Beispielsweise kann man vermeiden, dass alle Kopien eines Shards auf Knoten im selben Server-Rack liegen, was bei einem Ausfall des Racks zum verlust führen würde. Allocation Filteringˇ[h] ermöglicht es analog, die Zuweisung von Shards ausgewählter Indizes an bestimmte Knoten zu gestatten beziehungsweise zu verhindern. Aufbau eines Elasticsearch-Clusters Ein Elasticsearch-Cluster besteht aus einem oder mehreren Knoten und hat einen eindeutigen Namen. Alle seine Knoten kennen sich untereinander und bauen paarweise TCP-Verbindungen auf, über die sie in der Folge austauschen. Innerhalb eines Clusters können Knoten verschiedene Rollen übernehmen: Ein -Knoten beherbergt Shards und bearbeitet somit Indizierungs- und Suchanfragen. Ein -Knoten hat keine Shards, nimmt aber Anfragen entgegen und leitet sie an geeignete -Knoten weiter. Außerdem kann er Teilergebnisse verteilter Suchen aggregieren. Die Verwendung von -Knoten ist optional, aber es ist nicht unüblich, eine Cluster-Topologie mit -Knoten zu verwenden: Benutzer beziehungsweise vorgelagerte Anwendungen kommunizieren dann ausschließlich mit den -Knoten, welche die erhaltenen Anfragen wiederum an geeignete - Knoten weiterleiten. Das entlastet die -Knoten, sodass sie mehr Ressourcen für Index-Operationen und die eigentliche Suche in Dokumenten zur Verfügung haben. Abbildungˇ2 zeigt ein Beispiel-Cluster mit zwei - und drei -Knoten. Nützlich zu wissen ist, dass man -Knoten auch in eine vorgelagerte Webanwendung einbetten kann. Im Ergebnis wird ix Developer 2015 Big Data 111

3 Master A sie damit selbst Teil des Clusters, was einen Netzwerk-Hop gegenüber einer Anwendung mit separaten -Knoten einspart. Möglich ist diese Optimierung beim Zugriff auf den Cluster allerdings nur, wenn sie mit der gewünschten Firewall-Konfiguration des Systems in Einklang steht. In einem Elasticsearch-Cluster übernimmt ein Master-Knoten bestimmte zentrale Dienste. So verwaltet und verteilt er Informationen zu existierenden Indizes und Mappings und entscheidet, welche Shards auf welchen Knoten angelegt werden sollen. Standardmäßig ist jeder Knoten im Cluster Master-wählbar. Das heißt, er kann die Master-Rolle übernehmen. Es ist jedoch auch möglich, durch Konfiguration in der elasticsearch.yml-datei einzelne Knoten davon auszunehmen. Split Brain der größte Feind des Clusters Für die Funktionstüchtigkeit des Clusters ist es essenziell, dass es genau einen Master gibt. Eine Situation mit zwei oder mehr Master-Knoten heißt Split Brain und ist zu vermeiden, da sie üblicherweise mit verlust einhergeht: Gibt es mehrere Master-Knoten, könnten verschiedene Teile des Clusters zu unterschiedlicher Auffassung kommen, welche Shards die Primaries sind. Jeder Teil würde dann Index-Operationen gegebenenfalls für die gleichen Dokumente an seine Primaries weiterleiten. Wird das Split Brain später behoben und entscheidet sich das Cluster für jeweils nur einen der Primaries als primäre quelle, gehen die auf den anderen Shards durchgeführten Index-Operationen verloren. Manuelle Korrekturarbeiten stoßen in so einem Fall schnell an ihre Grenzen, sobald sich in den verschiedenen Versionen der nicht kompatible Änderungen finden. Um einem Split Brain entgegenzuwirken, bietet Elasticsearch den Konfigurationsparameter minimum_master_nodes an, der ebenfalls in der elasticsearch.yml-datei zu finden ist. Er beschreibt, wie viele Master-wählbare Knoten ein Knoten sehen B C 1. Index-Statistiken 2. Sortierung 3. Rückgabefelder Ein Cluster mit drei Knoten, bei denen Knoten A der Master sowie die Verbindung zwischen Knoten A und C gestört ist (Abb.ˇ3) Sind akkurate Ergebnisse gewünscht, erfordert eine verteilte Suche drei Round-Trips zwischen dem und den beteiligten -Knoten (Abb.ˇ4). muss, damit er selbst als Master gewählt werden darf. Setzt man minimum_master_nodes auf das in verteilten Systemen gängige Quorum (d.ˇh. mehr als die Hälfte aller Master-wählbaren Knoten), ist das Cluster bei einer vollständigen Netzwerkpartitionierung vor Split Brains geschützt. Denn wann immer das Cluster partitioniert ist, befinden sich höchstens in einer Partition mehr als die Hälfte der Master-wählbaren Knoten, sodass sich überhaupt nur in dieser Partition ein Master wählen lässt. Im Ergebnis ist dann nur diese Partition des Clusters funktional, während die anderen, Master-losen alle Index-Operationen und gegebenenfalls auch Suchanfragen ablehnenˇ[i]. Ein gut gehütetes Geheimnis ist, dass das Setzen von minimum_master_nodes nur im Fall einer vollständigen Netzwerkpartitionierung vor Split Brains schützt. Diese liegt vor, wenn kein Knoten einer Partition irgendeinen Knoten einer anderen Partition sehen kann. Ist jedoch zum Beispiel nur eine einzelne Verbindung zwischen zwei Knoten gestört, kann es nach wie vor zu Split Brains kommen. Abbildungˇ3 zeigt eine solche Situation. Angenommen sei, Knoten A ist Master und die Verbindung zwischen Knoten A und C ist gestört. Knoten C sieht dann keinen Master mehr und kann kurzerhand einspringen, weil er mit Knoten B und sich selbst ein Quorum an Master-wählbaren Knoten sieht. Da Knoten A ebenfalls Master bleibt, gibt es nun ein Split Brain. Ein Ausfall einzelner Verbindungen und das daraus resultierende Split Brain kann bei schweren Überlastsituationen auf einem oder mehreren Knoten durchaus vorkommen. Es empfiehlt sich, ein Monitoring für Split Brains aufzusetzen, etwa unter Verwendung der /_cat/master-apiˇ[j]. Außerdem mag es nützlich sein, zwei alternative Ansätze zum Umgang mit der Master-Rolle in Erwägung zu ziehen: 1. Um Split Brains garantiert zu vermeiden, kann man minimum_master_nodes auf die Gesamtzahl Master-wählbarer Knoten setzen. Die Konsequenz ist jedoch, dass das gesamte Cluster nicht mehr verfügbar ist, sobald einer der Masterwählbaren Knoten ausfällt. Wer sich für diesen Ansatz entscheidet, kann daher auch mit einem einzigen, festen Master- Knoten arbeiten. Das Risiko für Nichtverfügbarkeit steigt dann zwar, dafür vermeidet man aber verlust. 2. Ist eine hohe Verfügbarkeit wichtig, empfiehlt es sich, das Risiko für Split Brains trotzdem so weit wie möglich zu minimieren. Ein vielversprechender Ansatz ist die Verwendung dedizierter Master-wählbarer Knoten, die keinerlei sonstige Aufgaben wie haltung oder Beantwortung von Suchanfragen übernehmen. Auch sollten sie idealerweise auf eigener Hardware laufen, um sie vor Überlast durch andere Knoten zu schützen. Es ist zu empfehlen, mindestens drei dedizierte Master-wählbare Knoten aufzusetzen, sodass ein Quorum auch noch möglich ist, wenn einer ausfällt. Die versteckten Kosten verteilter Suche Auf den ersten Blick mag eine verteilte Suche in einem Index mit mehreren Shards attraktiv wirken, da die Teilsuchen auf den beteiligten Shards parallel zueinander ablaufen. Tatsächlich wird dieser Vorteil jedoch durch andere Effekte (negativ) überkompensiert, sodass eine verteilte Suche im Regelfall deutlich langsamer ist als eine äquivalente auf einem einzigen Shard. Abbildungˇ4 zeigt ein Beispiel für eine verteilte Suche in einem Index mit drei Shards, die sich auf drei verschiedenen Knoten befinden. Angenommen, eine vorgelagerte Anwendung sendet eine Suchanfrage und verlangt die N besten Treffer zurück. Ein -Knoten erhält die Suchanfrage und führt nun folgende Schritte durch: 112 ix Developer 2015 Big Data

4 1. Er fordert lokale Index-Statistiken von den drei Shards an. Aus den Antworten erstellt er globale Index-Statistiken, um mit diesen eine akkurate Relevanzberechnung zu ermöglichen. 2. Er leitet die Suchanfrage gemeinsam mit den globalen Index- Statistiken an die drei Shards weiter. Als Antwort erhält er von jedem Shard die N lokal besten Suchtreffer in Form ihrer Dokumenten-IDs und der jeweils dazugehörigen Relevanz. Daraus erstellt er eine globale Sortierung der N global besten Suchtreffer. 3. Er fordert nun von den drei Shards gezielt die eigentlich zurückzuliefernden (Dokumenten-Felder) für die N global besten Suchtreffer an. Aus den Antworten erstellt er schließlich die finale Antwort auf die ursprüngliche Suchanfrage. Um ein akkurates Ergebnis zu liefern, benötigt eine verteilte Suche also drei komplette Round-Trips zu allen beteiligten Shards. Zudem gibt es zwischen jeder dieser verteilten Phasen eine sequenzielle, in der ein Knoten die Antworten aller anderen auswertet, was den Gewinn durch die Parallelisierung noch weiter reduziert. Eine verteilte Suche ist offenbar aufwendig. Standardmäßig lässt Elasticsearch Schritt 1 übrigens aus, da der Verzicht auf globale Index-Statistiken die Relevanzberechnung bei großen, homogenen Dokumentenmengen kaum beeinträchtigen soll. Es kann aber sinnvoll sein, das für den konkreten Anwendungsfall zu evaluieren und den ersten Schritt gege - benenfalls wieder aufzunehmen. Ferner gibt es die Option, die Schritte 2 und 3 zu kombinieren und damit einen ganzen Round- Trip einzusparen. Der Erfolg dieser Maßnahme ist aber unklar, da die Shards dann für wesentlich mehr (nämlich jeweils die N lokal besten) Dokumente Feldinhalte auslesen und diese alle an den -Knoten verschicken müssen. Für weitere Details zur Auswahl der verschiedenen Optionen für verteilte Suchen siehe die Anleitung der Entwicklerˇ[j]. Bei einer verteilten Suche ist es unabhängig von ihrer konkreten Ausprägung generell erstrebenswert, die Anzahl beteiligter Shards zu minimieren, die Häufigkeit der verteilten Suche zu reduzieren oder sie sogar ganz zu vermeiden. Hierfür gibt es mehrere Möglichkeiten, sofern die und Suchanfragen bestimmte Voraussetzungen erfüllen. Grundsätzlich gilt bei Elasticsearch: Es ist äquivalent, ob man in einem Index mit 50ˇShards oder in 50ˇIndizes mit jeweils einem Shard sucht. Denn in beiden Fällen werden effektiv 50ˇLucene-Indizes durchsucht und deren Ergebnisse aggregiert. Hieraus ergibt sich eine gewisse Flexibilität beim Index-Design. Zeitorientierte Suche nach letzte drei Tage Ein gut optimierbares Szenario liegt vor, wenn einmal indizierte Dokumente nur selten oder gar nicht aktualisiert, viele Suchen anhand von Zeiträumen eingegrenzt und neuere Dokumente häufiger gesucht werden als alte. Beispiele für dieses Szenario sind die Indizierung von Logdaten, aber auch die von Tweets oder sonstigen Nachrichten beziehungsweise Ereignissen. Es empfiehlt sich das folgende Index-Design: Definiert wird ein Index pro Zeitraum, zum Beispiel pro Tag. Jeder Index erhält einen Namen, der dem Datum des jeweiligen Tages entspricht. Indiziert wird stets in den Index des aktuellen Tages, was sich für s transparent durch die Nutzung eines Index-Aliasˇ[k], etwa namens heute, realisieren lässt. Falls die Menge der täglich anfallenden zuverlässig in einen einzigen Shard passt, genügt bereits einer pro Index. Da Suchanfragen in der Regel eine zeitliche Komponente enthalten (z.ˇb. finde alle Logs aus den letzten drei Tagen, die folgenden Text enthalten ), reicht es aus, nur die relevanten Indizes (für die betroffenen Tage) in die Suchanfrage mit einzubeziehen. Elasticsearch erlaubt hierfür, bei einer Suchanfrage konkret die Indizes zu benennen, die beteiligt werden sollen. Im Ergebnis durchsucht man also nur wenige Indizes beziehungsweise Shards, obwohl die gesamte menge ( alle Logdaten ) wesentlich größer ist. Abbildungˇ5 veranschaulicht das beschriebene Szenario. Man kann sogar einen Schritt weitergehen und die Optimierung auf die Hardware ausweiten. Die Nutzung von SSDs ist für Elasticsearch generell zu empfehlen, aber vielleicht aus Kostengründen nicht flächendeckend möglich. Lassen sich indizierte Dokumente aber in heiß und kalt unterteilen (z.ˇb. könnten die Logdaten der letzten Tage heiß und alle älteren Logdaten kalt sein), steigert man die Suchperformance bereits erheblich, wenn man nur die Indizes mit heißen auf Knoten mit SSDs verwaltet. Neu hinzukommende heiße Indexe legt man ebenfalls auf Knoten mit SSDs an, während ältere Indizes abkühlen und auf andere Knoten migriert werden. Benutzerorientierte heute (für Indizierung) Optimiertes Index-Design für zeitorientierte : Indiziert wird stets in einen Index für den aktuellen Tag, und Suchen erstrecken sich über alle Indizes für die relevante Zeitspanne der Suchanfrage (Abb.ˇ5). Shard 1 Nutzer 2 Nutzer 3 Nutzer 4 Shard 2 Nutzer 1 Nutzer 6 Nutzer N-1 Filter nach Nutzer 1 Nutzer 5 Nutzer N Suche von Nutzer 1 Shard M Optimiertes Index-Design für benutzerorientierte : Dank Routing befinden sich alle Dokumente eines Benutzers im selben Shard, und die Abgrenzung verschiedener Nutzer wird durch einen Filter sichergestellt (Abb.ˇ6). Ein zweites, gut zu optimierendes Szenario setzt verschiedene Benutzer (oder Mandanten) voraus, deren Dokumente niemals für andere Benutzer sichtbar sind. Man könnte in diesem Fall zwar einen eigenen Index für jeden Benutzer anlegen, aufgrund diverser Fixkosten für die Verwaltung eines Index ist dieser Ansatz jedoch nicht für große Benutzerzahlen geeignet. Alternativ könnte man alle Benutzer in einem großen Index mit hinreichend vielen Shards verwalten, doch dann stellt sich die Herausforderung der verteilten Suche, da die Dokumente einzelner Benutzer über alle Shards verstreut sind. Einen Ausweg aus diesem Dilemma bietet Elasticsearch durch das sogenannte Routingˇ[l], was die Verwendung eines ix Developer 2015 Big Data 113

5 Onlinequellen [a] Elasticsearch [b] Apache Solr Reference Guide; Shards and Indexing Data in SolrCloud cwiki.apache.org/confluence/display/solr/shards+and+ Indexing+Data+in+SolrCloud [c] Shard Overallocation current/overallocation.html [d] Refresh API current/near-real-time.html#refresh-api [e] Apache Lucene lucene.apache.org [f] Search Request Preference current/search-request-preference.html [g] Allocation Awareness current/modules-cluster.html#allocation-awareness [h] No Master Block current/modules-discovery-zen.html#no-master-block [i] Cat Master current/cat-master.html [j] Search Type current/search-request-search-type.html [k] Index Aliases current/indices-aliases.html [l] Routing Value current/routing-value.html [m] Designing for Scale current/scale.html [n] Scaling an Elasticsearch Index blog.codecentric.de/en/2015/02/scaling-an-elasticsearchindex-introduction/ anderen Shard Key anstelle der Dokumenten-ID erlaubt. Wählt man die Benutzer-ID als Shard Key, landen alle Dokumente eines Benutzers sicher im selben Shard. Im Ergebnis hat man einen großen Index für alle Benutzer, mit einer festen Menge von Shards, aber trotzdem keine verteilten Suchen. Zu beachten ist, dass sich nach wie vor mehrere Benutzer einen Shard teilen, falls ihre Benutzer-IDs auf denselben Shard aufgelöst wurden. Deshalb benötigt man bei Suchanfragen nach wie vor einen Suchfilter nach Benutzer-ID, um die Regeln für (Nicht-)Sichtbarkeit zwischen Benutzern einzuhalten. Abbildungˇ6 veranschaulicht das beschriebene Index-Design. Natürlich besteht die Gefahr, dass ein Benutzer allein schon so viele Dokumente besitzt, dass diese die Kapazität eines Shards sprengen. Es ist daher wichtig, Flexibilität für dynamische Änderungen am Index-Design zu bewahren. Erreichen lässt sich das durch eine konsequente Verwendung von Index-Aliassen, indem für jede Benutzer-ID ein Alias angelegt wird. Der Alias eines Benutzers zeigt initial auf den großen gemeinsamen Index und enthält zudem die benötigte Routing- und Filter-Information in Form der Benutzer-ID. -Anwendungen re - ferenzieren ausschließlich diese Index-Aliasse. Das heißt, sie kennen einen separaten Index für jeden Benutzer, ohne aber Kenntnis der internen Verwaltung der zu haben. Durch diese Entkopplung von -Anwendungen und tatsächlicher Index-Struktur ist es jederzeit möglich, transparent Änderungen vorzunehmen. Zum Beispiel könnte ein Benutzer mit sehr vielen Dokumenten aus dem gemeinsamen Index in einen eigenen Index mit mehreren Shards migriert werden. Zum Abschluss wird einfach der Alias des Benutzers auf den neuen Index umgelenkt, und es ist keinerlei Änderung bei -Anwendungen nötig. Eine umfangreiche Darstellung des Themas Index-Design für Skalierbarkeit findet sich bei den Entwicklernˇ[m]. Dynamische Erweiterung von Indizes Trotz aller Planung kann es passieren, dass ein Index an seine Kapazitätsgrenze stößt. Da sich seine Anzahl an Shards nicht nachträglich ändern lässt, gibt es nur zwei Auswege: 1. Den Index um einen zweiten Index erweitern und Suchanfragen verteilt an beide senden. Eine Herausforderung hierbei ist, dass man bei Updates von Dokumenten identifizieren muss, an welchen der beiden Indizes man sie zu senden hat. 2. Einen neuen Index mit mehr Shards erstellen und die aus dem alten Index dorthin migrieren. Die größte Heraus - forderung hierbei ist, dass die Migration Stunden oder sogar Tage dauern kann und deshalb in der Regel ohne Downtime vonstatten gehen muss. Bei beiden Optionen besteht gehöriges Potenzial für Fehler, sodass deren Beschreibung den Rahmen dieses Artikels sprengen würde. Stattdessen sei auf die Blog-Serieˇ[n] verwiesen, die eine ausführliche Diskussion beider Ansätze liefert. Fazit Elasticsearch bietet einen hervorragenden Baukasten für die Realisierung skalierbarer Suchlösungen: Sharding, Replikation, Allocation Awareness, Routing und Index-Aliasse sind sehr flexible Werkzeuge, die vielfältig eingesetzt werden können. Besonders wichtig für eine hohe Such-Performance, insbesondere bei großen mengen und verteilten Indizes, ist ein auf den Anwendungsfall optimiertes Index-Design. Die Kenntnis verschiedener Fallstricke, wie die Gefahr von Split Brains, Inkonsistenzen bei Lesezugriffen oder die versteckten Kosten verteilter Suche, kann dabei helfen, unliebsame Überraschungen zu vermeiden. (ane) Dr. Patrick Peschlow arbeitet als Entwicklungsleiter bei der CenterDevice GmbH, einem deutschen Anbieter für Cloud-Dienste zum sicheren Austausch von Dateien. Alle Links: x 114 ix Developer 2015 Big Data