Back to top

Dieser Artikel ist der dritte Teil in der Reihe  Suche für Big Data und Big Data für die Suche von Paul Nelson, leitender Architekt bei Search Technologies.


Erkenntnis 3: Suche ist besser als SQL

 

Ich bin inzwischen alt genug, dass ich noch die Bereiche Netzwerk und hierarchische Datenbanken im Grundstudium gelernt habe. Natürlich existierten damals schon relationale Datenbanken, aber die Debatte, welche Datenbankstruktur sich durchsetzen würde, war noch nicht abgeschlossen. Ich erinnere mich noch daran, wie 1986 ein Ingenieur, selbst Autor eines Buches zu hierarchischen Datenbanken, mir zuversichtlich erklärte, dass relationale Datenbanken nur eine vorübergehende Mode wären. „Die Welt ist nunmal hierarchisch aufgebaut“, erklärte er.

Als ich Quel lernte (die RDBMS-Sprache von Ingres), war es Liebe auf den ersten Blick. Endlich gab es eine Sprache, die definierte Mathematik verwendet, um ein zuvor nie denkbares Niveau des Ausdrucks zu erreichen. Es war wie eine Offenbarung, ich war direkt süchtig. Irgendwann war ich dann natürlich gezwungen, auf SQL zu wechseln, und meine Liebe verblasste. SQL war für mich eigentlich immer wie eine Zweckehe, die mir von IBM und Oracle aufgezwungen wurde. Quel hingegen wird immer einen Platz in meinem Herzen haben. 

Aber gegen Tatsachen kann man nicht argumentieren. SQL hat gerade den 40. Geburtstag gefeiert und ist stark wie eh und je.

Bisher. 

Mir ist inzwischen aufgegangen, dass die Suche besser ist als SQL. Es ist schwer zu beschreiben, wie radikal diese Aussage für mich ist. Es ist in etwa so, wie wenn man sagt, dass die Bildschirmfreigabe besser ist als eine Boeing 747. 

Anders ausgedrückt, ich bin zuvor nie auch nur auf den Gedanken gekommen, SQL überhaupt mit der Suche zu vergleichen. In meiner Denkweise waren beides immer grundverschiedene Hilfsmittel, die für komplett unterschiedliche Ziele eingesetzt werden. Eins für die Textsuche, unstrukturiert. Eins für die Mathematik, strukturiert. Beide haben immer friedlich nebeneinander existiert, jeder in seinem eigenen Umfeld. 

Aber SQL ist inzwischen bis an die Grenzen der Belastbarkeit gestreckt worden und wird auch für Nutzungszwecke eingesetzt, für die die Suche einfach geeigneter ist. Das ist vor allem der Fall bei Anwendungen für das Data Warehouse und OLAP. Hier ist, was die Suche für Big Data leisten kann. Sie kann der Welt Zugriff auf Big Data geben. 

Aber wie? Und warum Suche statt SQL? Ganz einfach, weil ...

  • Die Suche ist schnell

Die Suche liefert ihre Ergebnisse in Sekunden, oder gar Sekundenbruchteilen. SQL-Abfragen im Data Warehouse brauchen mehrere Minuten. Oder Stunden. Oder Tage. 

Geschwindigkeit bringt Flexibilität. Geschwindigkeit bedeutet weniger Probleme, wenn mal ein Fehler geschieht. Geschwindigkeit bedeutet Spaß und Spiel. Geschwindigkeit öffnet die Möglichkeiten der Datenanalyse für jedermann, nicht nur für Datenbank-Programmierer. Darüber hinaus ...

  • Die Suche ist vertraut

Jeder kennt die Suche, jeder nutzt sie, jeden Tag. Selbst meine 85 Jahre alte Mutter nutzt Suchfunktionen, selbst mein 96 Jahre alter Onkel (gut, zugegeben, zu seiner Zeit war er eine Art Prolog-Guru, aber trotzdem ...). 

Der Prozentsatz der Leute, die die Suche verwenden, ist enorm viel größer als der Prozentsatz jener, die SQL nutzen. 

Man kann jetzt natürlich sagen, klar, aber das ist doch nur normale Textsuche, nicht mehr als die Navigation auf Websites. Das kann man doch nicht mit SQL vergleichen, mit all diesen exakten mathematischen Ausdrucksmöglichkeiten. Geht doch gar nicht. 

Und bis vor kurzem hätte ich da noch zugestimmt. Aber jetzt nicht mehr, weil ...

  • Die Suche ist leistungsfähig

In letzter Zeit gibt es immer mehr Ingenieure (wie die meisten meiner Freunde hier bei Search Technologies), vor allem im Open-Source-Bereich, die sich in die Suchmaschinen einarbeiten und sie Dinge leisten lassen, die zuvor undenkbar waren. Was denn so? Nun, eigentlich alles, wofür wir früher SQL verwendet haben, wie:

  • Histogramme: In SQL würden wir dafür Group-by Klauseln mit Ansammlungen verwenden. Bei der Suche wählt man ein Feld aus und lässt die Facetten dazu erstellen.
  • Mehrdimensionale Pivot-Tabellen: Histogramme (bzw. Facetten) über mehrere Felder, wodurch Tabellen mit Daten erstellt werden. Ich sage nur Heatmaps.
  • Group-by Klauseln: Bei Feldern mit hoher Kardinalität kann die Suche eine Liste der Gruppen ausgeben, anstelle von individuellen Datensätzen. Anders ausgedrückt werden Aufzeichnungen durchsucht und Menschen ausgegeben. Oder Unternehmen. Das ist unglaublich mächtig.

In Feldern mit geringer Kardinalität kann die Suche mehrere Ergebnissätze ausgeben, zum Beispiel die besten Ergebnisse für jede Dokumentart, oder für jede Contentquelle.

  • Berechnung geografischer Distanz und Reichweitenfilter: Diese Möglichkeiten werden jetzt schon seit einiger Zeit von der Suche genutzt.
  • Mathematik: Immer mehr Suchmaschinen ermöglichen auch die Berechnung mathematischer Funktionen über die Suchergebnisse.

Einige Suchmaschinen bietet sogar besondere Operatoren für die Berechnung standardmäßiger deskriptiver Statistiken, wie zum Beispiel Durchschnitt, Standardabweichung, Minimum oder Maximum für bestimmte Felder. 

Und das nicht nur bei kleinen Datensätzen, sondern auch bei richtig großen, weil ...

  • Die Suche ist skalierbar

Milliarden Datensätze können in Sekundenbruchteilen durchsucht werden. Google erledigt diese Aufgabe 35.000 Mal pro Sekunde. Natürlich hat Google Zehntausende Server zur Verfügung, aber diese Barriere schwindet, je mehr Cloud Hardware verfügbar wird. 

Die Suche ist skalierbar, weil es keine Verbunde gibt. Verbunde sind umständlich und zerstören die Skalierbarkeit, weil sie voraussetzen, dass die Datensätze verschiedener Tabellen abgeglichen werden, ein Prozess, der nicht leicht auf größere Server-Netzwerke umgelegt werden kann. 

In der Suche sind Dokumente bereits im Voraus verbunden, wenn sie für das Indexieren verarbeitet werden. Natürlich bedeutet das mehr Aufwand dabei, wie die Daten in der Suchmaschine repräsentiert werden (Zum Beispiel durch das Erstellen von 360-Grad-Ansichten der Einheiten), aber der Aufwand ist nicht so groß, wie man denken mag, weil ...

  • Die Suche ist schemafrei

In relationalen Datenbanken werden Spalten mit dem Ausdruck CREATE erstellt. Dann werden diese Spalten mit dem Ausdruck INSERT befüllt. Wenn es Daten gibt, die gemeinsam genutzt werden (zum Beispiel Namen für Regionen), wird für diese eine neue Tabelle erstellt. 

All diese Spalten! All diese Tabellen! 

Man braucht Monate, um all diese Tabellen mit all ihren Spalten zu erstellen. Hunderte Tabellen und Tausende Spalten sind normal. Mir begegnen ständig ER-Modelle mit Diagrammen, die nur auf mehreren Seiten Papier groß wie eine Zeitung ausgedruckt werden können. 

Suchmaschinen hingegen haben nie wirklich ein Schema benötigt. Jetzt mag man sagen, Moment, brauchten nicht frühe Suchmaschinen (wie meine, RetrievalWare, und FAST ESP) auch bestimmte festgelegte Felder? Bedeutet das nicht, dass auch Suchmaschinen ein Schema erfordern? 

Man muss dazu wissen, dass diese Felder nur bewusst hinzugefügt wurden, um den Festplattenspeicher zu optimieren (Siehe oben, Erkenntnis 1). Sie waren nie eine wirkliche Anforderung für die Suche selbst. Seit mehreren Jahren können alle neuen Suchmaschinen (Lucene, Solr, ElasticSearch, MarkLogic, Attivio usw.) jeden Satz Felder verwenden. 

(Wobei Solr eine Datei schema.xml verwendet – innerhalb dieser Datei sind jedoch dynamische Felder möglich. Außerdem hat Search Technologies Solr so erweitert, dass echte XML-Felder möglich sind, wodurch ein einzelnes Feld beliebigen XML-Content besitzen und suchen kann.)

Wie wichtig ist es, schemafrei zu sein? Nach meiner Erfahrung würde ich sagen, dass durchschnittliche Unternehmen mit Milliardenumsätzen mindestens 100 Datenquellen haben, die zu einem umfassenden System der Unternehmenssuche und Analyse kombiniert werden können. Das bedeutet, 100 Quellen x 25 Tabellen oder Unterquellen x (angenommen) je 5 Felder = 12.500 Felder zu verzeichnen. Search Technologies (als relativ kleines Unternehmen) nutzt bereits mindestens 14 verschiedene Quellen, soweit ich weiß. 

Wie kann man all diese Daten in einem massiven Schema verzeichnen? 

Antwort: Gar nicht. Man gibt die Datensätze einfach in XML und JSON aus (die meisten Systeme bieten diese Funktion schon von Haus aus) und lädt die Daten in eine Suchmaschine. Dann werden die Felder wie benötigt verbunden (siehe oben, Erkenntnis 1, Flexibilität). 

Und schließlich, nicht zu vergessen ...

  • Die Suche ist sicher

Um Unternehmensanwendungen zu bedienen müssen Suchmaschinen (und die diese umgebenden Ökosysteme wie Aspire von Search Technologies) komplexe Sicherheitseinschränkungen handhaben, dabei Sicherheit durch verschiedene Modelle, auf eine Art, die relationale Datenbanken nie auch nur zu bedenken hatten. Weitere Informationenen dazu findet man in meinem Blog-Artikel zur Sicherheit.

Das bedeutet, dass Daten von externen Quellen geladen werden können und das Ökosystem automatisch die ACLs für diese Daten mit einschließt. Weiterhin gehen Suchmaschinen auf intelligente Art mit Benutzern und Gruppenmitgliedschaften um, sie erkennen (beispielsweise), dass ein Benutzer Mitglied von LDAP-Gruppen, SharePoint-Gruppen, Jive-Gruppen usw. sein kann und wird den Benutzern daher nur die Suche und Analyse von Dokumenten gestatten, zu denen sie Zugriff haben.

Man sieht also, dass die Suche zahlreiche Vorteile gegenüber SQL hat. Aber was fehlt? Nun, so einiges:

  • Wir brauchen mehr und bessere Benutzeroberflächen

Zurzeit gibt es mehr Tools, die auf SQL basieren. So zum Beispiel Tableau. Die Suche muss da noch aufholen (obwohl Kibana ein interessanter Anfang ist).

  • Die Benutzeroberflächen brauchen mehr Funktionen

Zum Beispiel Arbeitsgruppen, gespeicherte und freigegebene Abfragen, gespeicherte und freigegebene Analysen, Verbindungen, Drucken, gespeicherte und freigegebene Dokumentenordner, Kennzeichnung gelesen/ungelesen usw. 

Ich denke, hier können wir einige Ideen von den Informationsdiensten der Regierung übernehmen, die uns in Sachen Analyse und Informationssammlung ein Stück voraus sind.

  • Wir brauchen Standard-Abfragesprachen

SQL ist (nominell) ein Standard. Es gibt keine (oder kaum) Unterschiede zwischen den Anbietern.

Abfragesprachen für die Suche hingegen sind komplett ungeordnet. Die oben aufgeführten Funktionen werden von unterschiedlichen Suchmaschinen komplett unterschiedlich gehandhabt. Die Branche braucht dringend eine standardisierte Struktur für eine Sprache für Suche / No-SQL mit Analysefähigkeiten.

Vielleicht sollte man das mal angehen.

Aber das kommt schon noch. SQL hat schließlich schon 40 Jahre Vorsprung.

 

Was bedeutet das für uns?

Ich sage immer gerne, dass es drei Computer-Revolutionen in meinem Leben gegeben hat:

  1. Der Personal Computer. Ich habe damals auf dem brandneuen Altair 8800 eines Freundes ein einfaches Programm geschrieben. Es hat zwei Zahlen zusammengerechnet. Im Keller habe ich auch noch einen tragbaren Kaypro, liebevoll Schlepptop genannt, einen IBM-PC und einen der ersten Macintosh-Computer.
  2. Das Internet: 1989, noch vor dem eigentlichen Internet, startete ich mit einem Geschäftspartner zusammen mein erstes Unternehmen für Suchmaschinen (meiner Definition nach hat das Internet erst 1995 wirklich an Bedeutung gewonnen, als Netscape an die Börse ging). Das Jahr war für mich eine seltsame Erfahrung. Ein bisschen so, wie wenn man morgens aus dem Haus geht und der Himmel auf einmal grün ist, nicht mehr blau wie sonst. Alles war anders. Meine Suchmaschine, RetrievalWare (die bis 2007 auf dem Markt war, bis sie von FAST aufgekauft wurde), hat diese Änderungen nie wirklich verkraftet. Und ...
  3. Big Data: Wie bei all diesen revolutionären Änderungen scheint es fast so, als ob uns auch hier wieder alle Hilfsmittel in die Hand gelegt wurden, alles, was wir brauchen, genau in dem Augenblick, als wir es brauchen. Big Data erfordert riesige verteilte Speichermöglichkeiten, elastische Berechnungsressourcen, verteilte Berechnungsframeworks, flexible Datenrepräsentation, statistische Analyse in großem Rahmen, Algorithmen zum Data-Mining ...

... und die Suche.

 

Ich glaube, das wichtigste, was ich mit diesem Blog aussagen will, ist, dass wir in den nächsten fünf Jahren große Änderungen auf dem Bereich der Suche erwarten können. 

Durch das Internet sind Suchmaschinen etwas Alltägliches geworden (wie schön bei Ziggy und Dilbert zu sehen). Dabei haben sich die Suchmaschinen aber eigentlich schon seit den frühen 90er Jahren kaum noch verändert. Die letzte große Änderung fand statt, als jeder auf Relevanzbewertung und verteilte parallele Verarbeitung umstellte. 

Natürlich sind die Algorithmen effizienter geworden, es gibt jetzt Facetten und einige elegante Analysemöglichkeiten, aber eigentlich verwenden wir immer noch das gleiche alte TF-IDF, und auch die allgemeine Architektur (Content-Verarbeitung -> Tokenerstellung -> Indexieren -> verteilte Suche) hat sich in den letzten mehr als 20 Jahren nicht geändert. 

Es wird also höchste Zeit, dass da mal Bewegung reinkommt. Ich bin davon überzeugt, dass Frameworks durch Big Data ein Katalysator sein können. Durch sie werden Fähigkeiten zum Vorschein kommen, die nicht nur die Technologie selbst stark beeinflussen werden, sondern auch die Art, wie wir Geschäfte machen. Und sogar die Gesellschaft als Ganzes.

Also sollten wir es anpacken und die Vision Realität werden lassen.

 

--- Paul

0