Solr und RDBMS: Entwerfen Sie Ihre Anwendung für das Beste aus beiden

von Amit Nithianandan

Einführung

Relationale Datenbanken (RDBMS) sind der Eckpfeiler der Datenpersistenz in der Softwareentwicklung. Auch wenn RDBMS in letzter Zeit wegen ihrer Skalierbarkeit und Geschwindigkeit unter Beschuss geraten sind, sind sie aufgrund ihrer Langlebigkeit, Portabilität, der Fülle an gut geschriebenen GUI-Verwaltungstools und der einfachen Abfrage immer noch der beliebteste Mechanismus zur Speicherung von Anwendungsdaten. Und die tabellarische Datendarstellung – Zeilen mit Datensätzen und Spalten mit Feldern – ist ein intuitiver Weg, um viele transaktionale Datentypen zu organisieren.

Daher ist es nur natürlich, bei der Organisation der Daten für Ihre Suchanwendung an das relationale Modell zu denken. Gleichzeitig bietet die Verwendung eines auf einem inversen Index basierenden Systems wie Solr/Lucene zur Gestaltung des Suchdienstes für Ihre Anwendung einige echte Vorteile, so dass die Benutzer sich schnell durch die Datenberge wühlen können. Was kann ein RDBMS also am besten, und wofür sollten Sie Solr einsetzen?

Zwei Modelle für den Umgang mit Daten

Das Wichtigste, was Sie bei der Entwicklung Ihres Suchdienstes beachten sollten, ist, dass Solr Ihr RDBMS nicht vollständig ersetzen soll, sondern es vielmehr ergänzen muss. Eines der Dinge, die Solr am besten kann, ist die Beantwortung einer Frage wie: „Was ist eine Liste der relevantesten Dokumente oder Felder, die möglicherweise der Abfrage ‚XYZ‘ entsprechen? „In diesem Fall könnten Ihre „XYZs“ mit einer Reihe von Dokumenten oder Datensätzen mit Feldern übereinstimmen, die Solr möglicherweise tokenisiert, gespeichert, abgefragt und/oder bewertet hat, um eine Liste von Ergebnisdokumenten zu erstellen.

Solr bietet auch die Möglichkeit, die Ergebnisse schnell nach Facettenfeldern zu filtern und so die Sucherfahrung zu bereichern, so dass Ihre Benutzer die Liste einschränken können, um das richtige Element oder die richtige Gruppe von Elementen auf der Grundlage von Facettenfeldern zu finden. Die zugrundeliegende inverse Indexstruktur eignet sich gut für diesen Ansatz, insbesondere wenn Sie die genaue Struktur der Abfragen oder der Daten nicht von vornherein kennen.

Im Gegensatz dazu ist das RDBMS in seiner klassischen Implementierung dafür gedacht, Fragen zu beantworten wie: exakte Abfragen, z.B. „Gib mir alle Datensätze in meiner Benutzertabelle mit einem Erstellungsdatum nach dem 1. Oktober 2009“ oder Abfragen zu Berichten wie „Wie groß ist die durchschnittliche Dateigröße der auf meine Fotoseite hochgeladenen Bilder, gruppiert nach Benutzer und Datum“. Solche präzisen Abfragen, die auf das Layout der Daten in der klassischen tabellarischen RDBMS-Struktur abgestimmt sind, funktionieren auf diese Weise recht gut. Und natürlich gibt es noch eine weitere Sache, die das RDBMS sehr gut kann: die effiziente Ausführung einer Reihe von Einfügungen und Aktualisierungen für eine Transaktion, wobei ein Rollback erfolgt, wenn eine dieser Operationen fehlschlägt (auch bekannt als ACID-Eigenschaften: (Atomicity, Consistency, Isolation, Durability).

Am besten stellen Sie sich den Lucene-Index als eine schnell durchsuchbare Ansicht Ihrer Daten vor. Eine gut konzipierte Anwendung kann das Beste aus beiden Ansätzen nutzen, indem sie Solr verwendet, um den Benutzern bei der Suche nach den relevantesten Dokumenten zu helfen, und dann Ihr RDBMS zur Abfrage präziserer Zusatzinformationen nutzt, um dem Endbenutzer die Ergebnisse besser präsentieren zu können. Zu diesem Zweck können Sie Ihre Solr-Abfrage so gestalten, dass sie zusätzliche Felder mit den erforderlichen Schlüsseln/IDs zurückgibt, die wiederum für eine schnelle und präzise Abfrage Ihrer Datenbank nach diesen zusätzlichen Informationen verwendet werden können. Lassen Sie uns untersuchen, wie das funktionieren könnte.

Der klassische RDBMS-Ansatz

Wenn Sie Ihre datengesteuerte Anwendung entwerfen, müssen Sie als erstes die Frage beantworten: Wie sollen meine Benutzer die Daten finden? Die Einfachheit und das relative Fehlen von Einschränkungen bei der Datenstruktur können Solr zu einer verlockenden Wahl machen, aber es gibt definitiv Fälle, in denen die Anwendung besser mit einem RDBMS bedient wäre. Wenn Sie beispielsweise eine E-Commerce-Website erstellen, auf der Benutzer mit einem einfachen Drill-Down-Assistenten ein kompatibles Scheibenwischerblatt für ihr Auto finden können, dann könnte eine RDBMS-basierte Lösung das Problem leicht lösen, da die gewünschten Ergebnisse dem Benutzer durch die Ausführung einer Reihe fester, strukturierter Abfragen in der Datenbank präsentiert werden. Die Abfrage auf der obersten Ebene könnte zunächst die Auswahl des Modelljahrs sein; dann „Zeige mir alle Automarken“, gefolgt von „Zeige Modelle für die zuvor ausgewählte Automarke <> “ und schließlich „Zeige alle Scheibenwischer, bei denen das Jahr A, die Automarke B und das Automodell C ist.“ Der Benutzer kann schließlich das Wischerblatt auswählen, das für sein Auto verfügbar ist, und es online kaufen oder prüfen, ob ein Geschäft in der Nähe die Teilenummer des gewünschten Wischerblatts auf Lager hat. In diesem Fall könnten die Abfragen sogar in einer etwas willkürlichen Reihenfolge erfolgen. Der Benutzer könnte zuerst die Marke, dann das Jahr und dann das Modell auswählen – und erst dann mit der Auswahl der Wischerblätter fortfahren. Es geht auch ohne Volltextsuche (z.B. „billige Scheibenwischer Hyundai sonata“) oder Facettierung (nach Attributen wie Wischermarke, Baujahr oder Preis), um die Ad-hoc-Suchergebnisnavigation zu erleichtern, damit der Benutzer genau das richtige Wischerblatt findet. Gleichzeitig gibt es einige sequentielle Einschränkungen. Sie können nicht fragen, ob ein Wischerblatt kompatibel und vorrätig ist, bevor Sie die vorhergehenden Bedingungen (Marke, Modell, Jahr) ermittelt haben.

Vergleich des Solr-Ansatzes mit dem RDBMS

An dieser Stelle müssen wir einen wichtigen Unterschied zwischen dem reinen RDBMS-Ansatz und dem Solr-Suchansatz machen. Die relationale Modellierung lehrt uns, unsere Daten in zusammenhängende Entitäten zu normalisieren, um Redundanz zu vermeiden, und mehrere Tabellen und Fremdschlüssel zu verwenden, um Beziehungen zwischen diesen Entitäten herzustellen. Daher neigen viele Entwickler dazu, beim Umgang mit Solr genauso zu denken, indem sie vielleicht eine Tabelle in einem Index und eine andere Tabelle in einem anderen Index indizieren und dann fragen: „Wie kann ich die beiden in Solr miteinander verknüpfen?“ oder „Macht es Sinn, die Ergebnisse aus einem Index zu nehmen und den anderen abzufragen?“ Es ist jedoch wichtig, sich daran zu erinnern, dass Solr nicht an solche Einschränkungen gebunden ist und dass es sich um einen Dokumentenspeicher handelt, bei dem jedes Dokument eine Sammlung von Feldern ist. Bestimmte Kardinalsünden bei der relationalen Modellierung sind erlaubt, ja sogar erwünscht. Solr kann ohne weiteres ein einziges Feld mit mehreren Werten verwenden. Im Gegensatz dazu würde dies in einem RDBMS mit zwei oder mehr Tabellen und Fremdschlüsseln modelliert werden.

Wie bereits erwähnt, unterstützt Solr das Konzept der mehrwertigen Felder, die sehr nützlich sind, wenn mehrere unterschiedliche Werte in einem einzigen Feld gespeichert werden müssen (im Gegensatz zu einer durch Komma getrennten Zeichenfolge von Werten, die als ein einziger Wert gespeichert wird). Die Speicherung der vom Benutzer eingegebenen Tags würde beispielsweise als mehrwertiges Feld definiert werden, mit einem Wert für jedes Tag, so dass jedes dieser Tags bei einer Textsuche abgeglichen werden kann. In einem Dokumentenspeicher repräsentiert ein einzelnes Dokument ein einzelnes Konzept mit allen für die Darstellung dieses Konzepts erforderlichen Daten (im Gegensatz zu demselben Konzept, das in einem RDBMS über mehrere Tabellen verteilt ist und mehrere Joins erfordert, um es neu zu erstellen). Je uneinheitlicher die Daten sind, desto mehr kann die Freiheit von Solr von tabellarischen/Fremdschlüssel-Beschränkungen die Entwicklung vereinfachen: Die Dokumente müssen nicht alle die gleichen Felder oder sogar die gleichen Werte in den Feldern haben, damit Solr die richtigen Dokumente finden kann. Eine Datenbank würde eine vorherige Modellierung aller Felder und deren Abstraktion in Tabellen erfordern. Fehler in der Modellierung können die Effizienz von RDBMS beeinträchtigen. Wenn sich die Daten ändern, kann das relationale Modell, das Sie zu Beginn entworfen haben, für neue Felder, Entitäten usw. nicht mehr funktionieren, was für Solr kein Problem darstellt.

Betrachten wir noch einmal das E-Commerce-Beispiel. Wenn ich meinen Benutzern ermöglichen möchte, nach Wischerblättern zu suchen, die in einem Geschäft in der Nähe erhältlich sind, könnte ich einen Index mit mehreren Dokumenten oder Datensätzen für genau dasselbe Wischerblatt erstellen, wobei jedes Dokument unterschiedliche Standortdaten (Länge/Breite, Adresse usw.) enthält, um ein einzelnes Geschäft zu repräsentieren. Solr verfügt über eine Deduplizierungskomponente, mit deren Hilfe eindeutige Dokumente angezeigt werden können, falls ein bestimmtes Wischerblatt in mehreren Geschäften in meiner Nähe erhältlich ist. Im RDBMS-Datenmodell können Sie Produkte, Beschreibungen, Produktstandorte und Produktbilder jeweils in einer eigenen Tabelle speichern – was gut für die Datenpflege ist, da die einzelnen Daten logisch getrennt sind. Die Komplexität entsteht jedoch, wenn Sie eine SQL-Abfrage schreiben, um ein bestimmtes Modell eines Wischerblatts und dessen Standort darzustellen.

Aber – und hier liegt der Haken – aus Sicht der Suche kann die Ausführung von SQL-Abfragen wie „Welche RainX-Wischerblätter finde ich in der Nähe“ auf Ad-hoc-Basis ressourcenintensiv sein. Sie würden das RDBMS mit vielen derartigen Abfragen bombardieren, die sich auf verschiedene Tabellen, Produkte und Standorte erstrecken, und zwar zum Zeitpunkt der Abfrage und ohne Zwischenspeicherung, was sich nachteilig auf andere Teile des Systems auswirken kann, z. B. auf den Einkauf (der sehr transaktionsintensiv sein kann) oder auf andere Back-End-Bestandsmanagementprozesse. Was Sie bei der effizienten Datenverwaltung gewinnen können, verlieren Sie bei der Suchzeit. Solr hingegen kann problemlos mehrere verschiedene Abfragen bearbeiten, ohne dass es zu einem Ressourcenkonflikt kommt, wie dies bei einem RDBMS der Fall wäre.

Es gibt jedoch einen wichtigen Vorteil, den ein RDBMS immer noch mit sich bringt. Wenn Sie neue Waren hinzufügen oder Informationen zu bestimmten Feldern in allen Datensätzen ändern möchten (wenn Sie z.B. möchten, dass alle Scheibenwischer eine neue Teilenummer auflisten), kann es praktisch sein, diese Informationen an einem Ort in einem gut spezifizierten, normalisierten Feld zu haben. Wenn Sie dann noch die Eigenschaften der Rollback- und Persistenzverwaltung hinzufügen, sehen Sie, warum das RDBMS nicht so bald verschwinden wird.

Das Beste aus beidem machen

Glücklicherweise können Sie das Beste aus beiden Ansätzen herausholen, indem Sie die Solr-Komponente DataImportHandler (DIH) nutzen, um Ihre relationalen Daten zu indizieren. Alternativ dazu können Sie auch Komponenten^{von Drittanbietern} wie LuSQL verwenden, um diesen Prozess zu vereinfachen. Der DIH kann die Indizierung Ihrer relationalen Daten vereinfachen, da die SQL-Anweisungen, die für die Erstellung von Dokumenten erforderlich sind, in einer Konfigurationsdatei gespeichert werden, zusammen mit Mappings von Feldern der Ergebnismenge auf Solr-Dokumentfelder. Die DIH unterstützt einen vollständigen Import und eine Delta-Import-Konfiguration, so dass sich die inkrementelle Indizierung von der vollständigen Indizierung unterscheidet, da die inkrementelle Indizierung höchstwahrscheinlich eine Zeitkomponente und eine Verknüpfung mit einem Änderungsprotokoll enthält.

Im Wesentlichen wird jede Zeile in der Ergebnismenge, die durch die vom DIH ausgeführte SQL-Anweisung erzeugt wird, nun einem einzelnen Solr-Dokument zugeordnet. Sobald dieser Satz von Dokumenten – oder Datensätzen, früher als Datenzeilen bekannt – indiziert ist, ist Solr nominell bereit, Abfragen gegen diese Datensätze durchzuführen. Um die Abfrageergebnisse im Hinblick auf die Relevanz zu optimieren, müssen die Konfigurationsdateien von Solr natürlich so eingestellt werden, dass die verschiedenen Aspekte einer Abfrage am besten gewichtet werden, z. B. die Gewichtung bestimmter Dokumente, die Gewichtung von Texten, die Gewichtung von Feldern usw. (das Anwendungsprogrammiermodell zur Abstimmung der Relevanz ist eine der leistungsfähigsten Funktionen von Solr, aber das würde den Rahmen dieses Einführungsartikels sprengen). Während der Abfrage kann das an die aufrufende Komponente zurückgegebene Ergebnisdokument die Dokumentenkennungen enthalten, die erforderlich sind, um eine sekundäre, sehr gezielte Abfrage nach zusätzlichen Daten aus dem RDBMS durchzuführen, wie z.B. vorrätige Mengen, Bilder, Links zu Sonderangeboten, usw.

Aus der Perspektive des Systemdesigns sind zwei Hauptbereiche klar voneinander getrennt. Die Bestandsverwaltung erfolgt über das RDBMS und die Bestandssuche wird von Solr durchgeführt. Da das RDBMS über ACID-Eigenschaften verfügt, werden Funktionen wie der Kauf von Kunden oder die Eingabe neuer Bestände über die Datenbank abgewickelt, während die flexible, facettierte Volltextsuche von Solr übernommen wird. Die Kommunikationsverbindung zwischen Solr und dem RDBMS aus Sicht der Indizierung kann über die DIH-Delta-Import-Funktion von Solr und einen UNIX-Cron-Job erfolgen, der regelmäßig eine Solr + DIH-URL aufruft, um Änderungen zu indizieren, oder indem Änderungen direkt in Solr gepusht werden, indem Aktualisierungen gepostet werden.

Fazit

Zusammenfassend lässt sich sagen, dass Solr nicht als Ersatz für Ihr RDBMS gedacht ist. Vielmehr sollte Solr zur Entwicklung des Suchdienstaspekts Ihrer Anwendung verwendet werden, indem nur so viele Informationen gespeichert werden, wie für eine effiziente Abfrage Ihrer Datenquelle erforderlich sind, und der aufrufenden Komponente genügend Informationen zur Verfügung gestellt werden, um Ihr RDBMS nach zusätzlichen Informationen abzufragen. Die im zugrunde liegenden Lucene-Index gespeicherten Daten sind im Wesentlichen eine vollständig durchsuchbare Ansicht Ihrer Daten, die sich als entkoppelte Komponente in Ihrem System befindet. Wenn Sie sich gerade die Frage stellen, ob Sie mit Solr eine ähnliche Abfrage wie SELECT ___ in SQL durchführen können, sollten Sie innehalten und über Ihre Daten und das Design Ihrer Anwendung nachdenken.

Solr ist eine Suchmaschine, die auf effiziente Weise relevante Dokumente zu einer Benutzerabfrage zurückgeben soll. Sie ist am besten geeignet, wenn es darum geht, unterschiedliche Daten zu verarbeiten und die Logik zu vereinfachen, mit der die Abfrageergebnisse relevant gemacht werden. Es ist weder eine voll ausgestattete Berichtsplattform noch ein (transaktionaler) Datenspeicher mit Einschränkungen der referentiellen Integrität. Einen einfachen, aber großartigen Vergleich der Funktionen von Solr im Vergleich zu RDBMS finden Sie unter http://wiki.apache.org/solr/WhyUseSolr und eine vollständige Übersicht über die DIH-Komponente von Solr finden Sie unter http://wiki.apache.org/solr/DataImportHandler.

Amit Nithianandan ist ein Senior Search Engineer bei Zvents.