• IntraFind
  • Unternehmen
  • Suche + Big Data = Eventual Consistency Teil 2 - Warum Suche in extrem großen Datenmengen nicht mehr zwingend konsistent sein kann

Suche + Big Data = Eventual Consistency
Teil 2 - Warum Suche in extrem großen Datenmengen nicht mehr zwingend konsistent sein kann

Fortsetzung Blogbeitrag von Jörg Viechtbauer vom 19.05.2015

Der erste Teil des letzten Blogbeitrages endete mit der Feststellung:
Eine Big Data-fähige (und damit verteilte) Technologie muss zwangsläufig eine der Eigenschaften konsistent, verfügbar, partitionstolerant aufgeben.

Teil 2 soll nun Antworten auf folgende Fragen liefern:
Was bedeutet das für eine Suchmaschine? Oder anders formuliert: Worauf können wir verzichten, und welche Auswirkungen hat dies in der Praxis?

Die Partitionstoleranz ist kaum verhandelbar, denn sie wird umso wichtiger, je höher man skalieren möchte. In einem Verbund von 300 Rechnern ist zu erwarten, dass im Schnitt jede Woche mindestens eine Maschine ausfällt.

Wie wichtig ist die Verfügbarkeit? 2005 wurde bei Google die Trefferliste experimentell auf 30 Einträge vergrößert – mit dem Ergebnis, dass der Traffic um 20% einbrach. Als Ursache wurde der Anstieg der Suchzeit von 400 auf 900 Millisekunden identifiziert. Einmal mehr gilt: Zeit ist Geld! Selbst eine geringfügige Verschlechterung der Verfügbarkeit hätte Google Milliarden gekostet. Somit sind Abstriche bei der Verfügbarkeit nicht akzeptabel.

Bleibt also unabwendbar nur noch die Konsistenz als verzichtbare Eigenschaft. Verlust der Konsistenz – das klingt beunruhigender als es ist, betrifft die Inkonsistenz doch lediglich die während des Netzwerkausfalls aufgelaufenen Operationen und somit nur einen Bruchteil der Gesamtdatenmenge.

Was bedeutet der Verlust von Konsistenz für Suche / Enterprise Search?

Bei einer Suchmaschine kann sich dies z.B. so bemerkbar machen, dass neu indizierte Dokumente erst zeitverzögert gefunden werden können oder – wenn das System beispielsweise durch Replikation hochverfügbar (und damit noch verteilter) gemacht wird – temporär alternierende Ergebnislisten (mal wird das neue Dokument gefunden und dann wieder nicht).

Vielleicht sind auch die Facettenwerte nicht exakt oder das Dokument wird zunächst nicht präzise gerankt… die konkreten Auswirkungen hängen von der Implementierung ab, sind bei einer Suchmaschine aber in den allermeisten Fällen kaum wahrnehmbar und stellen daher keine Einschränkung der Funktionalität dar.
Oder haben Sie schon einmal bemerkt, dass die Google Suche inkonsistent ist? Und wenn ja, hat es Sie gestört?

Wenn die unmittelbare Konsistenz schon nicht vollständig garantiert werden kann, gibt es in den meisten Architekturen doch eine gewisse Annäherung daran, die mit dem englischen Begriff eventual consistency bezeichnet wird. Ein System heißt eventual consistent, wenn es garantiert, dass es zu einem konsistenten Zustand konvergiert, d.h. irgendwann einmal konsistent wird. Auch hier kann man keine pauschalen Aussagen darüber treffen, was dies konkret bedeutet und wie lange es dauern wird, bis dieser Zustand erreicht ist. In der Regel wird das System nach Wiederherstellung der Konnektivität die Konsistenz überprüfen und gegebenenfalls mit einer Art Reparatur beginnen.

Sollen in unserem Beispiel die Reisebüros verfügbar und partitionstolerant sein, verkaufen die Verkäufer das Ticket auch dann, wenn die Leitung zusammengebrochen ist, versuchen danach aber jede Minute, den Kollegen zu erreichen.

Sobald dies gelingt, wird der Konsistenzzustand überprüft:

  • Wurde das Ticket nicht oder nur einmal verkauft, ist alles in Ordnung.
  • Wurde das Ticket hingegen fälschlicherweise doppelt verkauft, erfolgt nun die Wiederherstellung eines gültigen Zustands.
  • Ein Kunde wird über den Fehler unterrichtet, erhält eine Rückerstattung und als Kompensation z.B. eine gute Flasche Wein.


FAZIT

Die digitale Datenflut wächst exponentiell und schneller als sich die Rechenleistung eines einzelnen Rechners entwickelt. Eine Big Data-fähige Architektur muss daher zwangsläufig horizontal skalieren, Somit unterliegt sie dem CAP-Theorem, demzufolge ein verteiltes System nicht gleichzeitig sowohl konsistent, verfügbar als auch partitionstolerant sein kann.

Bei einer Suchmaschine wird die Konsistenz – als der am wenigsten ins Gewicht fallende Faktor – durch eine schwächeren Konsistenzgarantie ersetzt: der eventual consistency. Diese gewährleistet, dass das System – so schon nicht unmittelbar – doch irgendwann einmal konsistent sein wird.

Zurück

Der Autor

Jörg Viechtbauer

Jörg Viechtbauer ist seit Oktober 2012 als Software Architekt bei der IntraFind Software AG beschäftigt.
Nach seinem Informatikstudium an der RWTH Aachen war Jörg Viechtbauer in der Softwareentwicklung namhafter deutscher Softwareunternehmen tätig und sammelte umfassende Praxiserfahrung in der Konzeption und Implementierung von Enterprise Search-Lösungen.
Aktuell gilt sein Interesse besonders der Entwicklung von Suchlösungen, Services & Plugins auf Basis von Elasticsearch.

Zurück