Wie viel Zeit haben Sie?

Wie viel Zeit haben wir, Spock?
Zwölf Sekunden, Sir!

(Aus „Star Trek Into Darkness“, 2013)

Stellen Sie sich vor, Sie arbeiten als Datenanalyst für einen Nachrichtendienst. Sie managen eine Taskforce, deren Aufgabe es ist, einen mutmaßlichen Terroristen ausfindig zu machen. Die Nachverfolgung der Bewegungsmuster der gesuchten Person erzeugt eine wahre Datenflut: Zeugenberichte, Funksignale (menschliche und maschinelle Kommunikation), Bilder, Videos und Social-Media-Posts sind zu verarbeiten. Die rechtzeitige Zusammenführung dieser Daten und das Ziehen der richtigen Schlüsse entscheidet darüber, ob der Gesuchte gefasst und ein terroristischer Anschlag möglicherweise verhindert werden kann. Können Sie es sich leisten, Zeit zu vergeuden?

Die Kenntnis der relevanten Daten zum richtigen Zeitpunkt ist entscheidend. Ermöglichen Ihre Systeme den Abgleich neuer Informationen, sobald diese eingehen? Falls nicht, kommt es zu einer kritischen Zeitverzögerung zwischen dem Moment des Eintreffens der Daten und dem Moment, zu dem Sie davon Kenntnis erlangen und die Daten verwerten können. In dieser Zeit kann viel geschehen. Manchmal ist dafür ein sehr hoher Preis zu zahlen.

Wenn Sie Ihre Daten in einer relationalen Datenbank speichern, können Sie SQL in vollem Umfang nutzen. Die meisten relationalen Datenbanken aktualisieren ihre Indizes sofort, um neue Daten unmittelbar für die Abfrage verfügbar zu machen.

SQL hilft Ihnen jedoch nicht weiter, wenn Ihre Inhalte extrem heterogen sind und aus den unterschiedlichsten Quellen stammen. Bei Ihren Abfragen werden Sie sich nicht mit dem Verknüpfen relationaler Tabellen befassen wollen. Vielmehr werden Sie Fragen stellen wollen wie: „Finde alle E-Mails oder Anrufe zwischen dem Sender Joe und dem Empfänger Mo, in denen die Begriffe Abendessen, Zirkus oder Schlaf fallen, während Joe nicht weiter als 3 Kilometer vom Flughafen entfernt war.“

Die Suche in E-Mails, Observationsprotokollen und Anrufdaten in Kombination mit zeitlichen und Geodaten erfordert den Einsatz fortgeschrittener Suchmechanismen. Die Suchmaschine wird üblicherweise parallel zur Datenbank angelegt. Die dort gespeicherten Daten gehen in hoher Geschwindigkeit ein, sind extrem umfangreich und stammen aus den unterschiedlichsten Quellen. Die Suchmaschine benötigt für die Verarbeitung und Indexierung jedes neuen Datensatzes eine gewisse Zeit.

Warum?

Sie bezahlen mit Ihrer Wartezeit

Ihre Daten befinden sich in einer Datenbank. Das Problem: Die meisten Datenbanken lassen sich nicht direkt durchsuchen. Stattdessen müssen die Daten zunächst von der Datenbank in die Suchmaschine übertragen werden.

Datenbank und Suchmaschine haben verschiedene API-Sätze und unterstützen unterschiedliche Datentypen und Strukturen. Um Ihre Daten für die Suche verfügbar zu machen, muss der Datenbankinhalt umgewandelt und in die Suchmaschine übertragen werden. Jede neue Information oder Änderung, die in der Datenbank eingeht, muss auch auf die Suchmaschinen-Indexe propagiert werden. Häufig müssen dabei Teile des Index neu erstellt werden.

Die Erstellung des Codes, der zur Orchestrierung dieser Aufgabe erforderlich ist, ist eine Mammutaufgabe. Er muss von Experten programmiert werden, ist ebenso komplex wie fragil und erfordert unablässige Modifikationen und Anpassungen an die eingehenden Daten.

Wenn Sie sich entscheiden, eine neue Datenquelle zu verfolgen, wie z. B. die Feeds einer Sicherheitskamera, müssen Sie diese nicht nur in der Datenbank abspeichern. Vielmehr müssen Ihre Entwickler diese Daten wieder so umwandeln, dass die Suchmaschine sie auch verarbeiten kann.

Erreicht die Aktualisierung eines Datensatzes die Datenbank, weil sich zum Beispiel die aktuelle Position einer beobachteten Person geändert hat, dauert es somit eine Weile, bis Ihre Suchmaschine die neue Position auslesen kann. Inzwischen kann sich die gesuchte Person bereits wieder an einem völlig anderen Ort befinden.

Je mehr Intelligence-Daten Sie also im Laufe Ihrer Operation zur Verfügung haben, desto größer die Verzögerung, bis Ihnen diese Daten durch Suchabfragen greifbare Ergebnisse liefern können. Ihr Erfolg bei der Erfassung von immer mehr Daten bremst Sie also am Ende aus.
Wertvolle Zeit geht verloren, um den technologischen Anforderungen nachzukommen. Hier läuft doch etwas falsch.

Angenommen, Sie verfolgten unter Nutzung einer Software zur Erkennung des Nummerschildes die Route eines Fahrzeugs mithilfe der verfolgten Sicherheitskamerafeeds in Echtzeit mit, dann würde die Latenz bei der Suchmaschinenindexierung veraltete Antworten auf Ihre Abfragen liefern. Das hieße, dass Sie zu spät darüber Kenntnis erlangen, dass sich der Wagen z. B. in Richtung Flughafen bewegt. Möglicherweise hat diese Latenzzeit schwerwiegende Folgen.

Geringe Latenz – mit etwas Datenverlust?

Um dem Problem veralteter Daten zu begegnen, kamen in den letzten Jahren sogenannte Datenbanken mit geringer Latenz auf den Markt. Für diese Datenbanken wird mit dem Versprechen geworben, dass die Zugriffszeit auf Daten auf Null bzw. realistischer auf einen Wert, der geradezu Null beträgt und im Millisekundenbereich liegt, verringert werden kann. Häufig handelt es sich dabei um skalierbare In-Memory-Datenbanken, die riesige Datenmengen verarbeiten können. Kein Zugriff kann schneller erfolgen als der auf Daten, die im Arbeitsspeicher gespeichert sind. Insofern lösen diese Datenbank ihr Versprechen durchaus ein.

Und doch müssen Abstriche gemacht werden. Oft können diese Datenbanken nur eine „gute“ Datenkonsistenz gewährleisten. Dies ist erheblich weniger als die auf ACID-Transaktionen basierende Datenkonsistenz der meisten relationalen Datenbanken. Was heißt das für Sie? Es gibt keine Garantie, dass diese Systeme Ihre Daten nicht verlieren.

Ein weiteres Zugeständnis, das an die hohe Geschwindigkeit zu machen ist, ist die eingeschränkte Fähigkeit zur Datenabfrage. Im Vergleich bieten selbst klassische relationale Datenbanken umfassende Abfragefunktionalität. Doch wie wir bereits gesehen haben, stößt auch SQL an seine Grenzen.

Latenzfreie Indizierung ist gefragt

Die Latenz zwischen Datenbank und Suchmaschine kann verringert werden: entweder durch Verwendung einer Teilmenge Ihrer Quellen oder durch eine vereinfachte Darstellung der Inhalte. Beide Optionen verringern die Komplexität der Datenübermittlung zwischen den zwei Systemen und sorgen so für eine schnellere Verfügbarkeit der Daten für die Suche.

Doch je stärker Sie vereinfachen oder die Datenmenge beschneiden, desto größer ist das Risiko, am Ende die entscheidenden Informationen ausgespart zu haben. Folgendes Szenario: Sie haben sich entschieden, nur die Telefonprotokolle zu durchsuchen, die bestimmte Codewörter enthalten. Was, wenn sich die Codes in der Zwischenzeit geändert haben – die alten Codewörter aber weiterhin verwendet werden? Ihre Suchmaschine arbeitet mit wertlosen, ja sogar irreführenden Informationen. Denn die relevanten Informationen befinden sich zwar in der Datenbank, doch Sie können über Ihre Suchfunktionen nicht darauf zugreifen.

Wie viel Zeitverzögerung oder Latenz können Sie sich leisten? Ist es akzeptabel, von einem entscheidenden Telefongespräch 12 Stunden später zu erfahren? Besser wäre es sicher, man wüsste sofort Bescheid.

Das ist möglich. Mit der geeigneten Technologie.

Sie benötigen dazu eine Suchmaschinenindexierung, die nahezu in Echtzeit abläuft, oder, noch besser, vollständig latenzfrei.

Latenzfreie Indizierung ist die Fähigkeit, strukturierte und unstrukturierte Daten zu indizieren und sie für die Suche verfügbar zu machen, sobald sie die Datenbank erreichen. Sie brauche dazu eine Datenbank, die all die unterschiedlichen Arten von Daten speichern kann – bedenken Sie nur die Menge, Geschwindigkeit und Heterogenität der einfließenden Daten. Diese Aufgabenstellung ist gemacht für eine nicht relationale NoSQL Datenbank.

Doch zunächst gilt es, die entscheidenden Datensätze zu finden. Die Lösung dafür liegt in einem leistungsstarkem universellen Index ohne Latenzzeit. In der Welt nicht-relationaler Datenbanken gibt es nicht viele Produkte, die latenzfreie Indexierung mit leistungsstarker Suchfunktionalität vereinen. Wie bereits erwähnt ist latenzfreie Indizierung die Fähigkeit, Daten in der Datenbank zu speichern und gleichzeitig die Suchindexe mit dieser Information zu aktualisieren. MarkLogic ist eines dieser Lösungen.

Die Besonderheiten an MarkLogic sind die ACID-Transaktionen der Datenbank sowie umfangreiche Suchfunktionen, die eine Kombination von strukturierten und unstrukturierten Daten mit Geodaten und zeitlichen Informationen ermöglichen. Als Tripel-Datenbank lässt MarkLogic Daten mit semantischen Informationen, in grafischer Form aufbereiteten, kombinieren und über SPARQL abfragen. In MarkLogic eingespeiste Informationen sind für Suchabfragen und Benachrichtigung mit dem nächsten CPU-Zyklus verfügbar. Mit MarkLogic können Sie sicher sein, dass Ihre wertvollen Daten schnell und effizient in der Datenbank gespeichert werden, nicht verloren gehen und sofort auch für komplexe Suchabfragen verfügbar sind.

Geschwindigkeit – die neue Währung?

Wir alle wissen, dass Informationen die neue globale Währung sind. Doch nur, wenn Sie sich im Klaren darüber sind, wie wertvoll Ihre Informationen sind, können Sie sie zu Ihrem Vorteil nutzen. Mit MarkLogic werden Suchindexe im selben Moment aktualisiert, in dem Daten in die Datenbank eingelesen werden.

MarkLogic versendet Benachrichtigungen, sobald relevante Informationen in die Datenbank eingegangen sind. Sie können Fragen wie „Ist Joe in’s Auto gestiegen und fährt in Richtung Flughafen?“ vorab formulieren. Sobald eine entsprechende Beobachtung in der Datenbank eingeht, wird eine Benachrichtigung verschickt. Durch die latenzfreie Indexierung von MarkLogic ist eine Echtzeitüberwachung von Joe und seinem Fahrzeug möglich.

Und selbst wenn in Ihrem Job das Überwachen von Terroristen nicht auf der Tagesordnung steht, sollten Sie sich die Frage stellen: Wie relevant eine Latenzfreie Suche für Sie ist.

Mr. Spock hatte nur 12 Sekunden Zeit, die Enterprise zu retten. Wie viel Zeit haben Sie?
Laden Sie unsere latenzfreie Datenbank jetzt herunter und lernen Sie MarkLogic kennen– kostenlos!