Diese Frage verlangt nach einer sehr breiten Antwort, die in allen Aspekten beantwortet werden muss. Es gibt sehr wohl bestimmte Besonderheiten, die ein System für einen speziellen Anwendungsfall einem anderen überlegen machen können, aber ich möchte hier die Grundlagen behandeln.
Ich werde ganz auf Solr als Beispiel für mehrere Suchmaschinen eingehen, die in etwa gleich funktionieren.
Ich möchte mit einigen harten Fakten beginnen:
-
Sie können sich nicht auf Solr/Lucene als sichere Datenbank verlassen. Es gibt eine Liste von Fakten, warum, aber sie bestehen hauptsächlich aus fehlenden Wiederherstellungsoptionen, fehlenden Acid-Transaktionen, möglichen Komplikationen usw. Wenn Sie sich entscheiden, solr zu verwenden, müssen Sie Ihren Index aus einer anderen Quelle wie einer SQL-Tabelle füllen. Tatsächlich eignet sich solr perfekt zum Speichern von Dokumenten, die Daten aus mehreren Tabellen und Beziehungen enthalten, für die sonst komplexe Joins erstellt werden müssten.
-
Solr/Lucene bietet überwältigende Funktionen für Textanalyse/Stemming/Volltextsuche/Scoring/Unschärfe. Dinge, die Sie mit MySQL einfach nicht tun können. Tatsächlich ist die Volltextsuche in MySql auf MyIsam beschränkt und das Scoring ist sehr trivial und begrenzt. Das Gewichten von Feldern, das Verbessern von Dokumenten auf bestimmte Metriken, das Bewerten von Ergebnissen basierend auf der Phrasennähe, das Abgleichen von Genauigkeit usw. ist sehr harte Arbeit bis fast unmöglich.
-
In Solr/Lucene haben Sie Dokumente. Sie können Relationen nicht wirklich speichern und verarbeiten. Nun, Sie können natürlich die Schlüssel anderer Dokumente in einem mehrwertigen Feld eines Dokuments indizieren, sodass Sie auf diese Weise tatsächlich 1:n-Beziehungen speichern und beides tun können, um n:n zu erhalten, aber den Datenaufwand. Verstehen Sie mich nicht falsch, es ist für viele Zwecke vollkommen in Ordnung und effizient (z. B. für einen Produktkatalog, in dem Sie die Händler für Produkte speichern und nur nach Teilen suchen möchten, die bei bestimmten Händlern oder so erhältlich sind). Aber mit HAS / HAS NOT ist das Ende der Möglichkeiten erreicht. So etwas wie „Alle Produkte erhalten, die bei mindestens 3 Händlern erhältlich sind“ kann man fast nicht machen.
-
Solr/Lucene hat sehr schöne Facettierungsfunktionen und Post-Search-Analysen. Beispiel:Nach einer sehr breiten Suche mit 40000 Treffern können Sie anzeigen, dass Sie nur 3 Treffer erhalten würden, wenn Sie Ihre Suche auf die Kombination verfeinern würden, dass dieses Feld diesen Wert und jenes Feld diesen Wert hat. Dinge, die zusätzliche Abfragen in MySQL erfordern, werden effizient und bequem erledigt.
Lassen Sie uns zusammenfassen
-
Die Stärke von Lucene liegt in der Textsuche/-analyse. Aufgrund der umgekehrten Indexstruktur ist es auch umwerfend schnell. Sie können wirklich viel nachbearbeiten und andere Anforderungen erfüllen. Obwohl es dokumentorientiert ist und keine "Graph-Abfrage" hat, wie es Triple Stores mit SPARQL tun, können grundlegende N:M-Beziehungen gespeichert und abgefragt werden. Wenn sich Ihre Anwendung auf die Textsuche konzentriert, sollten Sie sich auf jeden Fall für Solr/Lucene entscheiden, wenn Sie keine guten Gründe haben, wie z. B. sehr komplexe, mehrdimensionale Bereichsfilterabfragen, anders zu handeln.
-
Wenn Sie keine Textsuche haben, sondern etwas, wo Sie auf etwas zeigen und klicken können, aber keinen Text eingeben, sind gute alte relationale Datenbanken wahrscheinlich ein besserer Weg.
