semanticblog

Es gibt heute fast keinen Webauftritt mehr, der nicht über Suchfunktionalität verfügt. Dabei wird meistens bei kleineren bis mittelgroßen Webauftritten auf die MySQL-Volltextsuche zurückgegriffen.

Die Realisierung einer Volltextsuche über MySQL bietet einige Vorteile:

• Da diese Funktionalität bereits in die Datenbank integriert ist, fällt die Komplexität mehrere unterschiedliche Systeme verwalten zu müssen weg.
• MySQL unterstützt Boolesche Volltextsuche
• Volltextsuche mit Abfragenerweiterung
• Es lassen sich beliebige Stoppwörter für die Volltextsuche einstellen

Dennoch hat die MySQL-Suche auch Nachteile, die sich vor allem bei größeren Dokumentensammlungen bemerkbar machen.

• MySQL ist in erster Linie eine Datenbank und kein für Volltextsuche optimiertes System. Bei jeder Suchanfrage wird eine Anfrage an die Datenbank geschickt, was zu einer Abzweigung von Ressourcen entgegen Ihrer eigentlichen Kernaufgaben führt. Ein Index auf eine Spalte ist bei einer Suche nach Substrings ungeeignet.
• Wenn Sie aus geschäftsspezifischen Gründen auf InnoDB angewiesen sind kann die MySQL-Volltextsuche nicht ohne Einschränkungen benutzt werden, da diese auf MyISAM beschränkt ist.
• Bei größeren Datenmengen (ab ca. einem Gigabyte) lässt die Performance der Suche nach.
• Die Abfragemöglichkeiten und Matching-Modes sind im Gegensatz zu anderen Systemen limitiert.
• Die Möglichkeit Binary Large Objects (BLOBs) zu indizieren ist nicht gegeben.

Im Gegensatz zu MySQL ist Sphinx kein relationales Datenbanksystem sondern ein Open Source Search-Server, der im Wesentllichen auf die Erstellung und Abfrage von Indices über Textmengen spezialisiert ist.

Aus diesem Grunde bringt der Einsatz von Sphinx für den Zweck der Volltextsuche viele Vorteile mit sich:

• Die Indexierungsgeschwindigkeit großer Dokumentenmengen ist im Vergleich zu MySQL sehr schnell. Dabei ist der Standardweg direkt MySQL-Views zur Indexgenerierung zu verarbeiten. Der Vorteil bei dieser Vorgehensweise ist, dass Datenbank-Views nur einmal zur Indexierung abgefragt werden müssen. Danach gehören datenbankspezifische Geschwindigkeitseinbußen wegen komplexer Joins und falsch indexierter Fremdschlüssel der Vergangenheit an, weil der Sphinx-Index benutzt wird. Dieser ist in Form eines invertierten Index aufgebaut und sehr schnell. Bei NoSQL-Systemen, die nicht nativ von Sphinx unterstützt werden (z.B. MongoDB ) ist es möglich XML-Streams zu erzeugen und diese zu verarbeiten.
  Der Speicherverbrauch des Indexers ist hierbei individuell einstellbar.
• Die Abfragegeschindigkeit liegt auch bei mehreren Millionen Dokumenten im unteren Millisekundenbereich und der search service daemon (searchd) von Sphinx verbraucht nur wenig RAM.
• Resourcenschonung: Suchabfragen müssen nicht mehr von der Datenbank verarbeitet werden. Hierdurch lassen sich permanente Abfragen über komplexe Joins vermeiden, was den Load des Datenbankservers vor allem bei stark frequentierten Webportalen erheblich reduziert.
• Skalierbarkeit/Verteilte Suche: Nur bei sehr großen Seiten wirklich notwendig. Die einfachste Vorgehensweise ist, den Index nach seiner Erzeugung mittels eines Crob-Jobs und fsync auf andere Server zu kopieren. Es lassen sich somit mehrere Suchserver einsetzen, wobei auch mehrere CPUs/Kerne und 64-bit-Systeme unterstützt werden.
• Sphinx bietet die Möglich auch numerische Felder (zum Beispiel Preisabfragen im eCommerce-Bereich) zu indexieren.
• Unterstützung einer Vielzahl an Matching-Modes. Es ist kein Problem bestimmten Feldern eine höhere Gewichtung zu geben (Wenn Sie zum Beispiel bei Suchanfragen Überschriften in Artikeln höher bewerten möchten, als den Content-Text).
• Teilweise Ersetzung von SQL, durch die Unterstützung von Sortierung und Gruppierung der Ergebnismengen.
• Für alle wichtigen Programmiersprachen (PHP, Perl, Python, Ruby, Java C#, C/C++) existieren APIs.

Nachteile von Sphinx im Vergleich zur MySQL-Volltextsuche:

• Keine Unterstützung für Unterstützung a la “Meinten Sie vielleicht”. Dies muss über programmatischen Weg erfolgen. Jedoch können auch fremdsprachige Stemmer integriert werden. So würden die Wörter “gelaufen” und “lief” auf “laufen” reduziert und beide gefunden werden.
• Wenn sich nur wenige Dokumente ändern ist eine Neuindexierung des gesamten Dokumentenbestands oft zu zeitaufwändig. Eine Unterstützung des Updates von Teilbereichen des Index in Echtzeit wird erst in der neuesten beta-Version unterstützt. Der derzeitige Ansatz ist einen delta-Index zu erstellen, welcher nur die Änderungen beinhaltet und diesen mit dem Hauptindex zu mergen. Dennoch ist es ratsam, den gesamten Datenbestand in regelmäßigen Abständen neu zu indexieren. Dies ist durch cron-jobs sehr einfach umzusetzen.

Fazit:

Bei kleinen bis mittleren Datenbeständen ist die MySQL-Volltextsuche sicherlich ausreichend, da sie einen guten Kompromiss aus Performance und Benutzbarkeit darstellt. Wenn die Datenmenge jedoch anwächst und Sie diese durchsuchbar halten möchten, ist Sphinx eine wirklich empfehlenswerte Alternative.