Vom Prototyp zur Produktion: Hohe QPS für Databricks AI Search

Suche ist überall: Produktsuche auf E-Commerce-Seiten, Sprachanfragen auf Smart-TVs, Empfehlungen in jedem Feed und Identitätsabgleich bei der Kontosuche. Jede Aktion löst eine Anfrage pro Seitenaufruf, pro Tastendruck und pro Benutzeraktion aus. Bei einer großen Anzahl von Nutzern bedeutet dies, dass Tausende von Abfragen pro Sekunde auf den Suchindex treffen, wobei der Spitzenverkehr oft um ein Vielfaches höher ist.

Die Suche ist außerdem entscheidend für den Umsatz. Im Einzelhandel konvertieren Käufer, die die Suche nutzen, zwei- bis dreimal so häufig wie diejenigen, die nur stöbern. Auf Streaming-Plattformen bestimmen Empfehlungen den Großteil dessen, was Nutzer sich ansehen.

Um QPS auf Produktionsniveau zu erreichen, musste man früher für jede App einen maßgeschneiderten Retrieval-Stack aufbauen. Lasttests über Indexgrößen, Abfragetypen und Filter hinweg durchführen. Kapazitäten manuell dimensionieren. Load Balancer vor dem Index einrichten. Jeder neue Such-Anwendungsfall bedeutete, wieder von vorne anzufangen. Dieses Problem betrifft Vektordatenbanken, Suchmaschinen und selbstgebaute Stacks gleichermaßen.

Ankündigung der Skalierung für hohe QPS für Databricks AI Search

Heute kündigen wir die Skalierung für hohe QPS für Databricks AI Search an, die ab sofort allgemein verfügbar ist. Standard-Endpunkte können jetzt mit einem einzigen, leicht verständlichen Parameter auf Tausende von QPS skaliert werden. Sie nennen uns Ihr Ziel, und wir stellen die entsprechende Infrastruktur bereit.

Legen Sie target_qps beim Erstellen auf dem Endpunkt fest oder aktualisieren Sie ihn jederzeit auf einem bestehenden Endpunkt über das SDK, die REST-API oder die Endpunkt-Benutzeroberfläche. Databricks stellt die Infrastruktur bereit, um das Ziel zu erreichen. Sie müssen keine Replikatanzahlen verwalten, keine Knotengrößen dimensionieren und keine Load Balancer einrichten.

Die Governance von Unity Catalog und Delta Sync bleiben bestehen. Derselbe Endpunkt, der Ihren Prototyp angetrieben hat, skaliert jetzt für den Produktionsverkehr, ohne dass Sie die Plattform verlassen müssen.

Wann Sie eine Skalierung für hohe QPS benötigen

Drei Echtzeit-Produktionsmuster erfordern dies.

Suchleisten, wie die Produktsuche im E-Commerce, die Inhaltssuche auf Streaming- und Medienplattformen oder die Sprachsuche auf vernetzten Geräten. Ein Typeahead-Suchfeld kann bei jedem Tastendruck eine Suchanfrage auslösen, sodass die QPS mit dem aktiven Tippvolumen skaliert. Die Latenz wirkt sich direkt auf die Conversion aus. Eine End-to-End-Architektur finden Sie unter Building Real-Time Product Search on Databricks.

Empfehlungs- und Personalisierungssysteme, wie „Das könnte Ihnen auch gefallen“-Bereiche im E-Commerce oder personalisierte Feeds auf Medien- und Streaming-Plattformen. Jeder Seitenaufruf löst eine Empfehlungsabfrage aus, sodass Traffic-Spitzen zuerst das Retrieval treffen. Die Latenz von Empfehlungen ist entscheidend für die Antwortzeit der Anfrage.

Echtzeit-Entitätsauflösung, wie Identitätsabgleich, Deduplizierung oder Abfragen in großen Katalogen zum Zeitpunkt der Anfrage. Die Abfragerate ist hier ein betriebliches SLA und keine Spitze, die Sie zwischenpuffern können.

Wenn Sie eines der folgenden Probleme feststellen, benötigen Sie diese Funktion wahrscheinlich:

• Fehler des Typs 429 (Too Many Requests) in den Produktionsprotokollen
• Spitzen bei der P95-Latenz bei steigendem Datenverkehr, selbst bei mäßiger durchschnittlicher Auslastung
• Workarounds wie duplizierte Endpunkte oder clientseitiges Load Balancing

So funktioniert es im Detail

Deklarieren. Sie legen ein QPS-Ziel für den Endpunkt fest. Databricks berechnet und stellt die Rechenkapazität bereit, um dieses Ziel zu erreichen. Keine Replikatanzahlen, keine Knotendimensionierung, keine Kapazitätsplanung.

Funktioniert mit bestehenden Endpunkten. Aktualisieren Sie jeden Standard-Endpunkt über das Python SDK, die REST-API oder die Benutzeroberfläche. Die neue Kapazität wird wirksam, wenn das nächste Mal ein Index auf dem Endpunkt erstellt oder synchronisiert wird.

Skalierungsstatus überwachen. Das Feld scaling_info auf dem Endpunkt verfolgt den Fortschritt beim Übergang von SCALING_CHANGE_IN_PROGRESS to SCALING_CHANGE_APPLIED.

Observability in der Produktion. Der Betrieb eines Retrieval-Systems in der Produktion erfordert Transparenz bei den Anfragen pro Sekunde, der Abfragelatenz und dem Zustand des Endpunkts. Die Endpunkt-Benutzeroberfläche zeigt nun alle drei Werte für jeden Endpunkt an.

Nutzen Sie die Authentifizierung über Service Principals, um die Leistung zu maximieren. Der Datenverkehr von Service Principals wird über leistungsoptimierte Netzwerke geleitet, die für Produktions-Workloads mit hohen QPS ausgelegt sind. Der Datenverkehr über Personal Access Tokens (PAT) ist auf einige Dutzend QPS begrenzt, was sich zwar für das Prototyping, nicht aber für die Produktion eignet. Eine vollständige Anleitung finden Sie im Leitfaden zur Performance-Optimierung.

Dimensionierung. Nutzen Sie die Benutzeroberfläche für die Endpunkt-Observability und die native Genie-Integration, um Ihre Datenverkehrsmuster zu verstehen und target_qps mit ausreichend Puffer für Spitzenwerte festzulegen.

Legen Sie noch heute los

Der Unterschied zwischen Prototyp und Produktion ist jetzt nur noch ein Konfigurationsparameter. Die Skalierung für hohe QPS ist ab heute allgemein verfügbar, eine Anmeldung ist nicht erforderlich. Zwei Wege für den Einstieg:

• Erstellen Sie einen neuen Endpunkt, bei dem target_qps auf Ihr anfängliches Ziel eingestellt ist
• Aktualisieren Sie einen bestehenden Endpunkt mit target_qps, um den Index zu skalieren, der bereits für Ihre Anwendung bereitgestellt wird

Was kommt als Nächstes?

Wir arbeiten weiter daran, den Betrieb der Suche in großem Maßstab zu vereinfachen. Eine automatische Skalierung bei Traffic-Spitzen – ohne manuelle Kapazitätsplanung oder Dimensionierung – sowie die Unterstützung für speicheroptimierte Endpunkte sind für das laufende Jahr geplant.

Weitere Informationen:

• Dokumentation zu hohen QPS
• Übersicht über Databricks AI Search
• Best Practices für die Performance
• Building Real-Time Product Search on Databricks

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag