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

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

„640 kB sollten eigentlich genug für jeden sein.“ Viele von uns kennen vermutlich diesen Spruch, den Bill Gates angeblich im Jahr 1981 gemacht haben soll. Heute misst man den Arbeitsspeicher eines Rechners in Gigabytes und würde man sich zu der Aussage hinreißen lassen, dass z.B. 8 Gigabyte Hauptspeicher doch sicherlich für alle Zeiten ausreichend sein sollten, könnte man sich sicher sein, dass auch diese Behauptung in einigen Jahren skurril wirken würde.

Die weltweite Datenmenge wächst, unaufhaltsam und immer schneller. Der digitale Fußabdruck, den jeder von uns Jahr für Jahr hinterlässt, wird immer größer. Die gesamte Datenmenge, die die Menschheit vom Anbeginn der Geschichtsschreibung bis in das Jahr 1986 erzeugt hat, beträgt etwa 2.6 Exabytes (= 300.000x die größte Bibliothek dieser Welt). Im Jahr 2016 entsteht jeden Tag eine neue Datenmenge dieser Größe. Diese Entwicklung ist exponentiell, das digitale Datenvolumen verdoppelt sich etwa alle zwei Jahre - mit Konsequenzen für die Verarbeitung dieser Datenflut.

War es früher noch möglich, die in einem Unternehmen entstehenden Daten mit einem einzigen Rechner zu verarbeiten, ist dies heute in vielen Fällen nicht mehr denkbar. Zwar gilt (mit gewissen Einschränkungen) noch immer das Mooresche Gesetz, demzufolge sich die Komplexität integrierter Schaltkreise alle 24 Monate verdoppelt. Allerdings steigt die effektive Geschwindigkeit, mit der Daten verarbeitet werden können, nicht linear mit.

Eine Revolution stellt die Solid State Disc da, die durch ihre extrem niedrigen Zugriffszeiten Verfahren ermöglicht, die lange Zeit nicht praktikabel waren. Doch gibt es Grenzen für die Leistungsfähigkeit eines einzelnen Rechners – physikalisch oder finanziell (vertikale Skalierung war schon immer teuer und wenig kosteneffektiv). Damit bleibt irgendwann nur noch die horizontale Skalierung als Lösungsansatz übrig: statt eines sehr teuren monolithischen Hochleistungsrechners setzt man auf einen Verbund vieler günstiger Rechner. In Summe erhält man so erheblich mehr Rechenleistung für das gleiche Geld.

Wir folgern: Eine Big Data-fähige Technologie ist zwingend verteilt.

Unser verteiltes System ist Big Data-fähig, kostengünstig und schnell. Damit ist doch eigentlich alles geklärt… oder etwa doch nicht? Dazu muss man wissen, dass für verteilte Systeme folgendes Gesetz gilt:

CAP Theorem

Ein verteiltes System kann maximal zwei der folgenden drei Eigenschaften aufweisen:

  • (C) Consistent/Konsistent:
    Jeder Knoten sieht zu jedem Zeitpunkt die gleichen Daten.

  • (A) Available/Verfügbar:
    Jede Anfrage an das System wird zeitnah beantwortet.

  • (P) Partition tolerant/Partitionstolerant:
    Das System arbeitet auch bei Knoten- oder Kommunikationsausfällen weiter.

Anschaulich wird dies anhand eines Beispiels:

Über zwei Reisebüros A, B wird das letzte Ticket für einen Flug angeboten. Die beiden Standorte koordinieren den Verkauf über eine Telefonleitung, um sicherzustellen, dass der Platz nicht doppelt vergeben wird.

Büro A wird nun von einem Kunden 1 betreten, der die Reise buchen möchte. Der Verkäufer aus A ruft kurz in Büro B an und informiert darüber, dass die Reise nun verkauft wird. Der Kunde verlässt A mit seinem exklusiven Ticket. Nun betritt ein Kunde 2 Büro B, möchte ebenfalls die Reise buchen, wird aber vom Verkäufer dort darüber informiert, dass der Flug ausgebucht ist. In diesem Szenario hat alles geklappt: Die Kunden mussten nicht warten (Bild 2 und 4), und die Reise wurde exakt 1x verkauft (Bild 3).

Aber es gab ja auch keinen Netzwerkausfall!

Nun betrachten wir, was passiert, wenn die Telefonleitung ausgefallen ist: Kunde 1 möchte die Reise buchen, aber der Verkäufer von A kann Büro B nicht erreichen. Er hat nun drei Möglichkeiten:

  • 1. Warten, bis die Telefonleitung wieder steht. Damit ist das System nicht mehr verfügbar.
  • 2. Das Ticket nicht verkaufen. Das wäre eine Form der Konsistenzverletzung, denn tatsächlich existiert ja ein „verkaufsfähiges“ Ticket.
  • 3. Das Ticket verkaufen und hoffen, dass es nicht gleichzeitig in Büro B verkauft wird (was ein eindeutiger Bruch der Konsistenz wäre).

Dass das CAP-Theorem für eine verteilte Architektur immanent ist, bedeutet aber nicht, dass cleveres Vorgehen die Auswirkung in der Praxis nicht doch verbessern kann. So kann man in unserem Beispielcluster das Verhalten deutlich verbessern, wenn Reisebüro A das Ticket auch dann verkaufen darf, wenn B nicht erreichbar ist, wohingegen B in diesem Fall warten oder den Verkauf verweigern muss (A wird also eine Art privilegierter Knoten).Wir haben die konsistente Verfügbarkeit trotz komplettem Netzwerksausfall von 0% auf 50% gesteigert! Dennoch gilt folgende Aussage:

Eine Big Data-fähige (und damit verteilte) Technologie (z.B. unternehmensweite Suche oder Content Analytics) muss zwangsläufig eine der Eigenschaften konsistent, verfügbar, partitionstolerant aufgeben.

Was bedeutet das für eine Suchmaschine bzw. für Enterprise Search? Oder anders formuliert: Worauf können wir verzichten, und welche Auswirkungen hat dies in der Praxis?

Antworten darauf liefert Ihnen in Kürze unser nächster Blogartikel.

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