Lakebase Search dimensionieren: Cache statt Compute auf Vorrat

Wer Lakebase Search dimensionieren will, sollte nicht allein auf die Zahl der Dokumente schauen. Entscheidend ist, wie groß der Suchindex wird, welche Daten im Cache liegen und wo Suchanfragen tatsächlich Zeit verlieren. Neue Databricks-Benchmarks mit bis zu vier Millionen Textpassagen liefern dafür konkrete Anhaltspunkte. Für mittelständische Unternehmen mit Azure und Databricks ist das besonders relevant, wenn interne Wissenssuche oder KI-Assistenten zuverlässig antworten sollen, ohne unnötig hohe Betriebskosten zu verursachen.

Kurz gesagt: Databricks zeigt anhand neuer Benchmarks, dass das Verhältnis zwischen Local File Cache und Vektorindex eine zentrale Größe für die Dimensionierung von Lakebase Search ist. Ein Cache ungefähr in Indexgröße bediente nach dem Aufwärmen 95 bis 98 Prozent der angefragten Seiten ohne Speicherzugriff außerhalb des Caches. Für die Praxis bedeutet das: zuerst Suchabfrage und Cache prüfen, dann Datenbank und Anwendung gezielt skalieren.

Was ist neu an den Erkenntnissen zu Lakebase Search?

Neu sind konkrete Messergebnisse dazu, wie Cache-Größe, Kandidatenzahl und Anwendungsressourcen die Leistung von Lakebase Search beeinflussen. Der Beitrag liefert damit eine Grundlage für Kapazitätsentscheidungen, nicht nur eine Beschreibung der Suchfunktionen.

Lakebase Search verbindet Vektorsuche und BM25-basierte Schlüsselwortsuche über Postgres-Erweiterungen innerhalb von Lakebase Postgres. Vektorsuche findet inhaltlich ähnliche Texte; BM25 bewertet Treffer anhand der enthaltenen Suchbegriffe. Hybride Suche kombiniert beide Verfahren.

Das ist beispielsweise für technische Dokumentation interessant: Eine Suche muss sowohl eine sinngemäße Fehlerbeschreibung als auch eine exakt eingegebene Artikelnummer berücksichtigen können. Die Suchindizes liegen dabei neben den Anwendungstabellen. Ein separates Suchsystem mit zusätzlicher Datenübertragung ist für diese Architektur nicht erforderlich.

Das kann den Betrieb vereinfachen, ersetzt aber keine Architekturentscheidung. Suchlast und übrige Datenbankzugriffe teilen sich Ressourcen. Berechtigungen und Filter müssen auch dann sauber umgesetzt werden, wenn Anwendung und Suche dieselbe Datenbank nutzen.

Lakebase Search dimensionieren: Welche Größe entscheidet?

Das Verhältnis von Local File Cache zu Vektorindex ist in den veröffentlichten Tests der wichtigste Orientierungspunkt für die Cache-Dimensionierung. Die reine Anzahl gespeicherter Textpassagen reicht dafür nicht aus.

Der Local File Cache hält kürzlich gelesene Datenbankseiten auf dem Compute bereit. Fehlt eine benötigte Seite dort, muss Lakebase Postgres sie aus dem zugrunde liegenden Speicher nachladen. Mehr Compute Units, kurz CU, stellen unter anderem mehr Cache-Kapazität bereit.

Die Vektorindizes der untersuchten Datensätze waren unterschiedlich groß:

• Bei einer Million Textpassagen belegte der Index 5,8 GB.
• Bei zwei Millionen Textpassagen waren es 11,5 GB.
• Bei vier Millionen Textpassagen waren es 23,0 GB.

Diese Werte sind keine allgemeingültige Umrechnung von Dokumenten in Speicherbedarf. Sie gelten für die verwendeten Embeddings und die getestete Indexkonfiguration. Für Deine Planung zählt deshalb die tatsächlich gemessene Indexgröße.

Warum ein warmer Cache nicht alles erklärt

In den Tests sank die mediane Latenz der hybriden Suche auf 33 Millisekunden, als das Verhältnis von Cache zu Vektorindex ungefähr eins erreichte. Bei kleineren Verhältnissen lag sie über einen größeren Bereich nahe 800 Millisekunden. Besonders der Schlüsselwortanteil profitierte davon, weniger Seiten nachladen zu müssen.

Das sind Messwerte der getesteten Suchabfragen, keine Zusage für die Antwortzeit einer fertigen Anwendung. Dort kommen beispielsweise Query-Embedding, Netzwerkzugriffe und Verarbeitung im Webserver hinzu. Außerdem konkurrieren weitere Tabellen und Indizes um Ressourcen. Ein Cache in Vektorindexgröße ist daher ein sinnvoller Startpunkt für Tests, aber keine pauschale Produktionsfreigabe.

Wie beeinflusst die Kandidatenzahl Qualität und Antwortzeit?

Eine kleinere Kandidatenzahl reduziert die gelesenen Datenbankseiten, kann aber die Zusammensetzung der Suchergebnisse verändern. Deshalb gehört dieser Parameter in einen fachlichen Qualitätstest und nicht nur in die technische Optimierung.

Bei hybrider Suche liefert jedes Suchverfahren zunächst eine begrenzte Trefferliste. Diese Kandidaten werden anschließend zu einer gemeinsamen Rangfolge zusammengeführt.

Im veröffentlichten Vergleich blieben bei 200 statt 1.000 Kandidaten je Verfahren 90,5 Prozent der Top-10-Ergebnisse gleich. Gleichzeitig sank die Zahl berührter Datenbankseiten von 28.972 auf 10.401. Wichtig: Die Übereinstimmung mit einer größeren Kandidatenliste ist kein Nachweis fachlicher Richtigkeit.

Für eine deutschsprachige Unternehmenssuche solltest Du deshalb prüfen:

• Werden genaue Produktbezeichnungen und Artikelnummern gefunden?
• Funktionieren Abkürzungen, zusammengesetzte Wörter und interne Fachbegriffe?
• Bleiben relevante Treffer nach Berechtigungsfiltern sichtbar?
• Liefert die Suche brauchbare Ergebnisse bei ungenauen Fehlerbeschreibungen?

Die Skalierungstests nutzten einen englischsprachigen Textbestand. Ihre Ergebnisse ersetzen daher keine Qualitätsprüfung mit Deinen deutschen Dokumenten und Suchanfragen.

Kaltstart und Normalbetrieb getrennt bewerten

Ein nach Scale-to-zero neu gestartetes Compute hat zunächst einen leeren Cache. Zur Aufwachzeit kommen deshalb Zugriffe auf noch nicht zwischengespeicherte Seiten hinzu.

Definiere getrennte Zielwerte für den ersten Aufruf nach einer Pause und für den laufenden Betrieb. Für eine sporadisch genutzte interne Recherche kann eine längere erste Antwort akzeptabel sein. Bei einer regelmäßig benötigten Serviceanwendung kann ein dauerhaft aktives Minimum sinnvoller sein.

Was sagen die Benchmarks über die Compute-Kosten aus?

Die veröffentlichten Kostenwerte zeigen niedrige Datenbank-Compute-Kosten für einzelne Tests, aber keine vollständigen Betriebskosten einer Suchlösung. Databricks nennt für einen 14-minütigen Lasttest mit rund 109.000 Anfragen 0,02 US-Dollar Lakebase-Postgres-Compute-Kosten. Als dauerhaft aktive Basis gegen Kaltstarts empfiehlt der Beitrag 0,5 CU und nennt dafür etwa 31 bis 40 US-Dollar monatlich.

Diese Angaben sind weder ein Azure-Angebot noch eine belastbare Kalkulation für Deinen Betrieb. Prüfe aktuelle Verfügbarkeit, regionale Preise und Vertragskonditionen. Berücksichtige außerdem Anwendungshosting, Embedding-Erzeugung, Speicher und gegebenenfalls weitere Dienste.

Ebenso wichtig: Mehr Datenbank-Compute verbessert nicht automatisch die gesamte Anwendung. In den Lasttests verlagerte sich der Engpass bei wachsender Datenbankkapazität auf die Anwendung. Zusätzliche Datenbankressourcen brachten dann kaum noch Durchsatzgewinn, solange Worker und Verbindungspools unverändert blieben.

So gehst Du mit Azure und Databricks praktisch vor

Beginne mit einer klar begrenzten Suchaufgabe, etwa freigegebenen Wartungsunterlagen. Prüfe zunächst die Verfügbarkeit der benötigten Funktionen in Deiner vorgesehenen Azure- und Databricks-Umgebung sowie die Anforderungen an Datenresidenz und Zugriffsrechte.

Ein sinnvoller Ablauf umfasst vier Schritte:

1. Ziele festlegen: Definiere akzeptable Antwortzeiten, erwartete gleichzeitige Nutzung und fachlich relevante Treffer.
2. Repräsentativ testen: Nutze reale Dokumenttypen, deutsche Fachsprache und produktionsnahe Berechtigungsfilter.
3. Engpässe messen: Erfasse Indexgröße, Cache-Trefferrate, Datenbanklatenz und End-to-End-Latenz getrennt. Betrachte neben dem Median auch langsame Anfragen, etwa über p95.
4. Gezielt dimensionieren: Optimiere Kandidatenzahl und Verbindungspools. Erhöhe anschließend dort Ressourcen, wo der nachgewiesene Engpass liegt.

Die Einbettung in Deine Datenplattform entscheidet dabei mit: Dokumentaufbereitung, Aktualisierung und Zugriffssteuerung beeinflussen die Nutzbarkeit ebenso wie schnelle SQL-Abfragen. Eine Databricks Beratung kann helfen, diese Architekturfragen mit einem belastbaren Last- und Qualitätstest zu verbinden.

Was das für dich bedeutet

Plane Lakebase Search nicht nach Dokumentanzahl oder maximal verfügbarer Compute-Leistung. Miss den Index, teste die Trefferqualität und unterscheide zwischen Datenbank-, Anwendungs- und Kaltstartlatenz. So kannst Du Kosten und Nutzererlebnis anhand belastbarer Ergebnisse abwägen.

Du möchtest hybride Suche auf Azure und Databricks sinnvoll dimensionieren? Sprich mit Ailio über Deine Databricks-Architektur und einen passenden Testaufbau.

Redaktionelle Einordnung auf Basis eines Beitrags im Databricks-Blog.