Das Engineering-Team hinter einem Video-Hosting-Dienst ersetzte seinen SQLite-FTS5-Index durch einen OpenSearch-Cluster. Dadurch sank die Rate der Suchanfragen ohne Ergebnisse von 12 % auf 1,4 %, während die Search-to-Click-Rate um 9 % stieg und die Latenz unter 28 ms blieb.

Warum der Wechsel unumgänglich wurde

Die Volltextsuche-Erweiterung von SQLite (FTS5) ist attraktiv: Sie befindet sich in derselben Datei wie der Rest der Daten, verursacht keine Lizenzkosten und liefert bei exakten Token-Übereinstimmungen sofort Ergebnisse. Die Protokolle der Plattform zeigten jedoch, dass etwa zwölf Prozent der Nutzersuchen überhaupt kein Ergebnis lieferten. Rechtschreibfehler wie „intersteller“ oder „avengrs endgame“ – die Art von Tippfehlern, die Menschen auf mobilen Tastaturen machen – waren die Hauptursache.

Ein schneller Workaround mittels Trigrammen (Dreier-Zeichen-Fragmenten) senkte die Rate der leeren Suchanfragen auf 7 %, verursachte jedoch zwei Probleme. Erstens blähte sich der Index auf mehr als das Dreifache seiner ursprünglichen Größe auf, was die Speicherkosten in die Höhe trieb und die Updates verlangsamte. Zweitens litt die Relevanz; das Fuzzy-Matching lieferte eine unübersichtliche Mischung aus nicht verwandten Videos, was die Nutzer eher verwirrte, als sie zu führen.

Das Team kam zu dem Schluss, dass eine spezialisierte Suchmaschine mit nativer Tippfehler-Toleranz und einer ausgefeilten Relevanzbewertung erforderlich war.

Aufbau der OpenSearch-Pipeline

SQLite als „Source of Truth“ beibehalten

OpenSearch diente als vergängliche, schreibgeschützte Replik. Alle Video-Metadaten verblieben in SQLite; der Suchindex konnte ohne das Risiko eines Datenverlusts neu aufgebaut werden. Wenn der OpenSearch-Cluster ausfiel, fiel die Anwendung automatisch auf die ursprüngliche FTS5-Engine zurück.

Schichtweise Relevanz mit einer „should“-Abfrage

Anstatt sich allein auf Fuzzy-Matching zu verlassen, kombinierte die Abfrage drei Klauseln:

  • Exakte Phrasenübereinstimmung – höchster Boost, um Nutzer zu belohnen, die den Titel korrekt eingegeben haben.
  • Alle Begriffe vorhanden – mittlerer Boost, um Abfragen abzufangen, bei denen jedes Wort vorkommt, aber nicht zwingend in der richtigen Reihenfolge.
  • Fuzzy-Match – niedriger Boost, der als Sicherheitsnetz für falsch geschriebene Token dient.

Diese Hierarchie bewahrte die Präzision bei sauberen Abfragen und bot gleichzeitig einen nachsichtigen Fallback für Tippfehler.

Tuning der Fuzzy-Einstellungen

Eine Prefix-Länge von 1 erzwang, dass der erste Buchstabe jedes Begriffs übereinstimmen musste, bevor die Fuzzy-Logik griff. Diese Regel hielt die Suche schnell und verhinderte eine Explosion der Kandidatenbegriffe, die den Arbeitsspeicher überlasten könnte. Das Team begrenzte zudem die maximale Anzahl der Begriffserweiterungen – eine weitere Schutzmaßnahme gegen unkontrollierten Ressourcenverbrauch.

Synchronisationsstrategie

Drei komplementäre Prozesse halten den OpenSearch-Index mit SQLite synchron:

  • Ein Cronjob zur Synchronisierung neuer Daten.
  • Nächtlicher Diff-Durchlauf – sucht nach Unstimmigkeiten, die bei den inkrementellen Updates durchgerutscht sind.
  • Wöchentlicher vollständiger Neuaufbau – läuft hinter einem Index-Alias und tauscht diesen dann in einem einzigen Schritt aus, was eine Downtime von Null garantiert.

Messbare Auswirkungen nach zwei Wochen

  • Suchanfragen ohne Ergebnisse sanken von 12 % auf 1,4 %.
  • Die Search-to-Click-Conversion stieg um 9 %.
  • Die mediane Latenz blieb unter 28 ms und lag damit deutlich innerhalb des UX-Ziels der Plattform.

Einschränkungen und Gegenargumente

Die Migration ist kein Plug-and-Play-Upgrade. Das Team betont, dass die Primärdatenbank niemals durch eine Suchmaschine ersetzt werden sollte; SQLite bleibt der maßgebliche Speicher für alle Video-Metadaten.

Fazit

Die Einführung einer Tippfehler-Toleranz durch eine spezialisierte Suchmaschine verwandelte eine spürbare Sackgasse in der User Journey in ein reibungsloses, schnelles Erlebnis. Die Fallstudie zeigt, dass eine disziplinierte Architektur – die Beibehaltung des relationalen Speichers als „Source of Truth“, die Schichtung der Relevanz und die Absicherung der Fuzzy-Logik – messbare Gewinne liefern kann, ohne die Stabilität zu opfern.

Quelle: https://dev.to/ahmet_gedik778845/migrating-video-title-search-from-sqlite-fts5-to-opensearch-fuzzy-queries-4bhj