Full Text Search: SQL Standard vs. proprietaere Features

1. Warum Full Text Search kaum standardisiert ist

Full Text Search gehoert zu den Bereichen von SQL, in denen der ANSI SQL Standard nur eine sehr duenne Grundlage bietet. Der Standard definiert mit CONTAINS und MATCH zwar theoretische Konstrukte fuer textbasierte Suche, doch die tatsaechliche Umsetzung, insbesondere Relevanz-Ranking, Sprachanalyse und Indexierungsstrategie, ist vollstaendig den einzelnen Datenbankherstellern ueberlassen. Das fuehrt dazu, dass Full Text Search in PostgreSQL, MySQL und SQL Server auf grundlegend verschiedenen internen Architekturen basiert, obwohl alle drei Systeme das gleiche Grundproblem loesen wollen: relevante Textstellen in grossen Datenmengen schnell zu finden.

Diese fehlende Standardisierung bei Full Text Search ist kein Zufall, sondern spiegelt die Komplexitaet des Problems wider. Textsuche erfordert linguistische Vorverarbeitung wie Stemming und Stopword-Entfernung, spezialisierte Indexstrukturen wie invertierte Indizes, und eine Bewertungsfunktion fuer Relevanz, die stark von Anwendungsfall und Sprache abhaengt. Anders als bei SELECT oder JOIN gibt es bei Full Text Search kein einfaches, universell akzeptiertes mathematisches Modell, das sich problemlos standardisieren liesse. Die folgenden Abschnitte zeigen, wie die drei grossen Datenbanksysteme das Problem jeweils loesen.

2. PostgreSQL: tsvector, tsquery und GIN-Indizes

PostgreSQL bietet mit den Typen tsvector und tsquery die technisch ausgereifteste native Full Text Search Implementierung unter den relationalen Datenbanken. Ein tsvector ist eine vorverarbeitete, normalisierte Repraesentation eines Textes, bei der Woerter auf ihre Wortstaemme reduziert und mit Positionsinformationen versehen werden. Die Funktion to_tsvector('german', text) erzeugt diese Repraesentation unter Beruecksichtigung sprachspezifischer Regeln, waehrend to_tsquery('german', suchbegriff) die Suchanfrage in dasselbe Format konvertiert.

Fuer performante Volltextsuche kombiniert man tsvector-Spalten mit einem GIN-Index (Generalized Inverted Index), der Suchanfragen auch bei Millionen Datensaetzen in Millisekunden beantwortet. Der Operator @@ prueft, ob ein tsvector zu einer tsquery passt, und ts_rank() liefert eine numerische Relevanzbewertung, die fuer die Sortierung der Suchergebnisse genutzt wird. Diese Kombination macht PostgreSQL zur technisch vollstaendigsten Full Text Search Loesung unter den in diesem Artikel verglichenen Systemen, allerdings mit dem Preis, dass die korrekte Nutzung ein tieferes Verstaendnis der zugrunde liegenden Konzepte erfordert.

-- PostgreSQL: tsvector column with GIN index for fast full text search
ALTER TABLE articles ADD COLUMN search_vector TSVECTOR
    GENERATED ALWAYS AS (to_tsvector('german', title || ' ' || body)) STORED;

CREATE INDEX idx_articles_search ON articles USING GIN (search_vector);

-- Query with relevance ranking
SELECT id, title, ts_rank(search_vector, query) AS relevance
FROM articles, to_tsquery('german', 'datenbank & performance') AS query
WHERE search_vector @@ query
ORDER BY relevance DESC
LIMIT 20;

3. MySQL: FULLTEXT-Index und MATCH AGAINST

MySQL loest Full Text Search mit einem eigenen Indextyp namens FULLTEXT, der direkt auf einer oder mehreren TEXT- beziehungsweise VARCHAR-Spalten angelegt wird. Die Abfrage erfolgt ueber die Funktion MATCH(spalten) AGAINST(suchbegriff), die in zwei Modi arbeitet: dem Standard-Modus mit natuerlichsprachlicher Suche und dem Boolean-Modus, der explizite Operatoren wie + fuer Pflichtwoerter und - fuer auszuschliessende Woerter unterstuetzt. Der natuerlichsprachliche Modus liefert automatisch eine Relevanzbewertung, die direkt im SELECT ausgegeben werden kann, ohne eine separate Ranking-Funktion aufzurufen.

Ein wichtiger Unterschied zu PostgreSQL: MySQL bietet standardmaessig keine echte linguistische Stammform-Reduktion (Stemming), sondern arbeitet primaer mit exakten Wort- und Praefix-Uebereinstimmungen, ergaenzt um eine konfigurierbare Stopword-Liste. Fuer InnoDB-Tabellen, dem Standard-Storage-Engine seit MySQL 5.6, funktioniert FULLTEXT zuverlaessig, war aber lange Zeit eine MyISAM-Exklusivitaet, was in aelteren Migrationen gelegentlich noch zu Verwirrung fuehrt, wenn Full Text Search Features von einer aelteren MySQL-Version erwartet werden.

-- MySQL: FULLTEXT index on title and body columns
ALTER TABLE articles ADD FULLTEXT INDEX idx_articles_fulltext (title, body);

-- Natural language mode, returns relevance score automatically
SELECT id, title,
       MATCH(title, body) AGAINST('datenbank performance' IN NATURAL LANGUAGE MODE) AS relevance
FROM articles
WHERE MATCH(title, body) AGAINST('datenbank performance' IN NATURAL LANGUAGE MODE)
ORDER BY relevance DESC
LIMIT 20;

-- Boolean mode: required and excluded words
SELECT id, title
FROM articles
WHERE MATCH(title, body) AGAINST('+datenbank -mongodb' IN BOOLEAN MODE);

4. SQL Server: Full-Text Index und CONTAINSTABLE

SQL Server implementiert Full Text Search ueber einen separaten Full-Text-Index, der ueber einen eigenen Full-Text-Katalog verwaltet wird, ein architektonisches Detail, das administrativ mehr Aufwand erfordert als die integrierten Loesungen von PostgreSQL und MySQL. Die Abfrage erfolgt ueber die Funktionen CONTAINS() fuer einfache Boolesche Bedingungen im WHERE, oder CONTAINSTABLE(), das als tabellenwertige Funktion eine RANK-Spalte liefert, die man per JOIN mit der Basistabelle verbindet, um eine relevanzsortierte Ergebnisliste zu erhalten.

SQL Server unterstuetzt komplexe Suchausdruecke ueber FORMSOF(INFLECTIONAL, wort) fuer flektierte Wortformen und NEAR(wort1, wort2, distanz) fuer Naeherungssuche, bei der zwei Begriffe innerhalb einer bestimmten Wortdistanz vorkommen muessen. Diese Funktionen bieten eine ausdrucksstaerkere Abfragesprache als die einfache MATCH AGAINST-Syntax von MySQL, erfordern aber auch mehr Einarbeitung. Die Notwendigkeit eines separaten Katalogs und die im Vergleich langsamere Indexaktualisierung machen SQL Server Full Text Search fuer Anwendungen mit sehr haeufigen Schreibvorgaengen weniger geeignet als die enger integrierten Loesungen der anderen Systeme.

-- SQL Server: Full-Text Catalog and Index required first
CREATE FULLTEXT CATALOG ArticlesCatalog AS DEFAULT;

CREATE FULLTEXT INDEX ON Articles (Title, Body)
KEY INDEX PK_Articles
ON ArticlesCatalog;

-- CONTAINSTABLE returns a RANK column, joined back to the base table
SELECT a.Id, a.Title, ft.RANK AS Relevance
FROM Articles a
INNER JOIN CONTAINSTABLE(Articles, (Title, Body), 'database AND performance') ft
    ON a.Id = ft.[KEY]
ORDER BY ft.RANK DESC;

5. Relevanz-Ranking im Vergleich

Relevanz-Ranking ist der Bereich, in dem sich Full Text Search Implementierungen am staerksten inhaltlich unterscheiden, nicht nur syntaktisch. PostgreSQL bietet mit ts_rank() und ts_rank_cd() zwei verschiedene Ranking-Funktionen, die Worthaeufigkeit, Dokumentlaenge und optional die Naehe der Suchbegriffe zueinander beruecksichtigen, konfigurierbar ueber Gewichtungsparameter, die vier Prioritaetsstufen (A bis D) fuer unterschiedliche Textabschnitte wie Titel und Body erlauben.

MySQL berechnet die Relevanz beim natuerlichsprachlichen MATCH AGAINST automatisch nach einem internen, nicht direkt konfigurierbaren Algorithmus, der grob an klassischen TF-IDF-Prinzipien orientiert ist, aber deutlich weniger Einstellungsmoeglichkeiten bietet als PostgreSQL. SQL Server berechnet die RANK-Spalte in CONTAINSTABLE() ebenfalls automatisch, mit einem proprietaeren, nicht vollstaendig dokumentierten Algorithmus. Wer feingranulare Kontrolle ueber Relevanz-Ranking braucht, etwa fuer eine E-Commerce-Produktsuche mit Business-Prioritaeten, findet in PostgreSQL die flexibelste, aber auch komplexeste Loesung unter den drei verglichenen Systemen.

6. Sprachanalyse: Stemming, Stopwords und Woerterbuecher

Die Qualitaet von Full Text Search haengt entscheidend von der zugrunde liegenden Sprachanalyse ab. PostgreSQL bietet mit seinem Woerterbuch-System die flexibelste Loesung: to_tsvector('german', text) nutzt eingebaute Sprachregeln fuer Deutsch, die Stemming (Reduktion auf Wortstaemme), Stopword-Filterung und sogar Synonym-Woerterbuecher unterstuetzen, die sich individuell konfigurieren lassen. Diese Flexibilitaet erlaubt es, branchenspezifische Terminologie oder Abkuerzungen als Synonyme zu hinterlegen, was fuer spezialisierte Suchanwendungen wertvoll ist.

MySQL bietet ab Version 5.7 ebenfalls konfigurierbare Stopword-Listen und ueber die ngram- oder MeCab-Parser Unterstuetzung fuer Sprachen ohne Wortgrenzen wie Japanisch oder Chinesisch, verzichtet aber standardmaessig auf echtes Stemming. SQL Server nutzt sprachspezifische Wordbreaker und Stemmer, die als separate Komponenten installiert werden und je nach konfigurierter Sprache der Spalte automatisch angewendet werden, mit solider, aber weniger anpassbarer Qualitaet als PostgreSQLs Woerterbuch-System. Wer Full Text Search fuer mehrsprachige Anwendungen einsetzt, sollte die Sprachkonfiguration explizit pro Spalte oder Dokument festlegen, statt sich auf eine globale Standardeinstellung zu verlassen.

7. Grenzen von Full Text Search in der Datenbank

So leistungsfaehig Full Text Search in modernen Datenbanken auch geworden ist, gibt es klare Grenzen. Facettierte Suche mit mehreren gleichzeitigen Filtern, Fuzzy-Matching fuer Tippfehler-Toleranz, Autocomplete mit Prefix-Matching in Echtzeit und insbesondere horizontale Skalierung ueber mehrere Server hinweg sind Bereiche, in denen dedizierte Suchmaschinen wie Elasticsearch oder OpenSearch der datenbankintegrierten Full Text Search deutlich ueberlegen sind. PostgreSQL, MySQL und SQL Server wurden primaer als transaktionale Datenbanken konzipiert, Full Text Search ist dort ein wertvolles, aber sekundaeres Feature.

Ein weiterer praktischer Nachteil: Full Text Search Indizes muessen bei jeder Aenderung an den zugrunde liegenden Daten aktualisiert werden, was bei sehr schreibintensiven Tabellen zu spuerbarer Latenz fuehren kann, besonders bei SQL Server mit seiner separaten Katalog-Architektur. Wer Volltextsuche fuer eine kleine bis mittlere Datenmenge und moderate Suchanforderungen braucht, etwa fuer eine interne Wissensdatenbank oder einen Blog, ist mit der eingebauten Full Text Search meist gut bedient. Bei komplexen Suchanforderungen mit Facetten, hoher Suchlast und dem Bedarf nach horizontaler Skalierung lohnt sich der zusaetzliche Betriebsaufwand einer dedizierten Suchmaschine.

8. Wann eine dedizierte Suchmaschine die bessere Wahl ist

Die Entscheidung zwischen datenbankintegrierter Full Text Search und einer dedizierten Suchmaschine haengt von mehreren Faktoren ab. Erstens: Suchvolumen. Wenige hundert Suchanfragen pro Minute bewaeltigt jede der drei besprochenen Datenbanken problemlos, bei mehreren tausend Anfragen pro Sekunde wird eine horizontal skalierbare Loesung wie Elasticsearch relevant. Zweitens: Komplexitaet der Suchlogik. Einfache Keyword-Suche mit Relevanz-Sortierung deckt Full Text Search in der Datenbank gut ab, facettierte Navigation mit Aggregationen ueber mehrere Dimensionen gleichzeitig ist die Domaene dedizierter Suchmaschinen.

Drittens: Operative Komplexitaet. Eine zusaetzliche Suchmaschine bedeutet ein weiteres System, das betrieben, ueberwacht und mit der primaeren Datenbank synchron gehalten werden muss, ueblicherweise ueber Change Data Capture oder periodische Batch-Synchronisation. Fuer viele mittelgrosse Anwendungen ist die eingebaute Full Text Search der Datenbank der pragmatischere Start, mit der Option, spaeter bei nachgewiesenem Bedarf auf eine dedizierte Loesung umzusteigen. Diese Migration ist deutlich einfacher, wenn die Suchlogik von Anfang an klar von der uebrigen Anwendungslogik getrennt implementiert wurde.

9. Full Text Search Implementierungen im direkten Vergleich

Die folgende Tabelle stellt die wichtigsten Merkmale der drei Full Text Search Implementierungen gegenueber.

Diese Gegenueberstellung zeigt, dass PostgreSQL die technisch flexibelste, aber komplexeste Loesung bietet, MySQL die einfachste mit den wenigsten Konfigurationsmoeglichkeiten, und SQL Server einen Mittelweg mit maechtiger Abfragesprache, aber hoeherem administrativem Aufwand durch den separaten Katalog.

10. Zusammenfassung

Full Text Search ist einer der Bereiche von SQL, die der ANSI SQL Standard bewusst offen laesst, weshalb PostgreSQL, MySQL und SQL Server drei grundlegend verschiedene Loesungen entwickelt haben. PostgreSQL bietet mit tsvector, tsquery und GIN-Indizes die technisch flexibelste, aber auch komplexeste Implementierung. MySQL punktet mit einfacher Handhabung ueber MATCH AGAINST, bietet aber weniger Kontrolle ueber Relevanz und Sprachanalyse. SQL Server liegt mit seiner maechtigen Abfragesprache und dem separaten Full-Text-Katalog dazwischen, erfordert aber mehr administrativen Aufwand.

Die wichtigste strategische Entscheidung liegt jedoch nicht zwischen den drei Datenbanksystemen, sondern zwischen datenbankintegrierter Full Text Search und einer dedizierten Suchmaschine wie Elasticsearch. Fuer moderate Suchanforderungen ist die eingebaute Loesung meist der pragmatischere Start, waehrend komplexe Facetten, hohe Suchlast oder der Bedarf nach horizontaler Skalierung fruehzeitig fuer eine dedizierte Suchinfrastruktur sprechen.

11. FAQ: Full Text Search Standard vs. proprietaer