Der Übergang von Datenbanken zu Suchmaschinen
Lucid hat kürzlich eine Kundenumfrage über die Nutzung von Solr und Lucene durchgeführt. Einer der Kommentare, der mir ins Auge fiel, war die Frage nach den Unterschieden zwischen traditionellen SQL-Datenbankmaschinen und Suchmaschinen. Wenn Sie 20 Jahre lang mit Datenbanken gearbeitet haben und plötzlich mit einem Suchprojekt betraut werden, werden Ihnen einige der Konzepte sehr vertraut vorkommen, während andere Implementierungsmuster ganz anders erscheinen.
Die technischen Ähnlichkeiten und Unterschiede zwischen Datenbank und Suche sind so entscheidend, dass ich vor einigen Jahren einen ganzen Artikel darüber geschrieben habe: Relationale Datenbanken und Volltextsuchmaschinen im Vergleich, und es gibt auch eine Zusammenfassung hier.
Eines meiner Motive war es damals, der Welt zu sagen: „Der LIKE-Operator ist NICHT ein Ersatz für eine echte Volltextsuchmaschine!“ (obwohl Sie dieses Verhalten in Solr nachahmen können, wenn Sie es wirklich brauchen, um mit Altsystemen kompatibel zu sein)
Einer der Hauptpunkte des Artikels, den ich hier nicht wiederholen werde, ist der Vergleich und die Gegenüberstellung des Vokabulars zwischen den beiden Räumen, wie z.B. „record“ vs. „document“; scrollen Sie nach unten zum Abschnitt„Vocabulary Comparison Summary„.
Eine Aktualisierung, die ich vornehmen würde, wenn ich diesen Artikel heute schreiben würde, ist die Aktualisierung der Informationen über JOINS. Viele Jahre lang haben Sie bei Suchmaschinen einfach keine „Joins“ zur Suchzeit durchgeführt. Natürlich konnten Sie Inhalte aus Datenbanken indizieren und Daten aus mehreren Tabellen einbeziehen, aber diese Tabellen-Joins wurden in der Regel zur Indexzeit und nicht zur Suchzeit durchgeführt, daher heißt es in dem Artikel „n/a“. Man könnte dies auch als Denormalisierung oder ähnlich einer materialisierten Ansicht bezeichnen. Aber die Zeiten haben sich geändert und Solr 4.x unterstützt jetzt begrenzte Joins, wie auch einige andere Open Source Suchmaschinen. Erwarten Sie, dass sich die Leistung im Laufe der Zeit verbessern wird.
Eine weitere Änderung, die sich seit dem Schreiben dieses Artikels ergeben hat, betrifft Transaktionen. Es gibt zwar immer noch keine echten Transaktionen auf Datenbankebene, aber Solr 4 unterstützt optimistisches Sperren und den Abruf aktualisierter Werte in Echtzeit.
Ein weiterer Trend, der zwar kein direkter Ersatz für SQL ist, aber dennoch funktioniert, ist die Verwendung von Suchmaschinen-Facetten und Statistiken, die die Arbeit der SQL-Funktionen„GROUP BY“ und SUM/MIN/MAX übernehmen. Wenn Sie in der Vergangenheit Suchmaschinen aufgrund dieser Anforderung abgelehnt haben, ist es an der Zeit, einen neuen Blick darauf zu werfen!
Ein weiterer Trend in der Branche geht in Richtung nicht-traditioneller, nicht-SQL-basierter Datenspeicherung, wie NoSQL, Mongo, HBase usw. Wenn Sie ein klassischer SQL-Entwickler sind, müssen Sie vielleicht sowieso etwas anderes lernen. Die gute Nachricht ist, dass diese Datenbanken der neuen Generation auch gute Verbindungen zu Suchmaschinen haben.