Dal prototipo alla produzione: QPS elevati per Databricks AI Search

La ricerca è ovunque: la scoperta di prodotti sui siti di vendita al dettaglio, le query vocali sulle smart TV, i consigli in ogni feed e la corrispondenza dell'identità durante la ricerca degli account. Ognuno di questi elementi attiva una richiesta per visualizzazione di pagina, per tasto premuto, per azione dell'utente. Su scala consumer, ciò si traduce in migliaia di query al secondo che colpiscono l'indice di ricerca, con un traffico di picco spesso diverse volte superiore.

La ricerca si trova anche sul percorso critico dei ricavi. Nel settore retail, gli acquirenti che utilizzano la ricerca convertono a un tasso da due a tre volte superiore rispetto a chi si limita a navigare. Sulle piattaforme di streaming, i consigli guidano la maggior parte di ciò che gli utenti guardano.

Raggiungere QPS a livello di produzione un tempo significava creare uno stack di recupero personalizzato per ogni app. Test di carico su dimensioni dell'indice, tipi di query e filtri. Dimensionamento manuale della capacità. Collegamento di load balancer davanti all'indice. Ogni nuovo caso d'uso di ricerca riavvia il lavoro. Il problema è comune a database vettoriali, motori di ricerca e stack fai-da-te.

Presentazione dello scaling ad alti QPS per Databricks AI Search

Oggi annunciamo lo scaling ad alti QPS per Databricks AI Search, che è ora generalmente disponibile. Gli endpoint Standard possono ora scalare a migliaia di QPS con un singolo parametro leggibile dall'utente. Tu ci indichi il tuo target. Noi forniamo l'infrastruttura per soddisfarlo.

Imposta target_qps sull'endpoint al momento della creazione o aggiornalo su qualsiasi endpoint esistente in qualsiasi momento tramite SDK, REST API o l'interfaccia utente dell'endpoint. Databricks fornisce l'infrastruttura per soddisfare il target. Nessun numero di repliche da gestire, nessun nodo da dimensionare, nessun load balancer da collegare.

La governance di Unity Catalog e Delta Sync rimangono attive. Lo stesso endpoint che alimentava il tuo prototipo ora scala al traffico di produzione senza lasciare la piattaforma.

Quando è necessario lo scaling ad alti QPS

Tre pattern di produzione in tempo reale lo richiedono.

Barre di ricerca, come la ricerca di prodotti sull'e-commerce, la scoperta di contenuti su piattaforme multimediali e di streaming, la ricerca vocale su dispositivi connessi. Una casella di completamento automatico può attivare una chiamata di ricerca per ogni tasto premuto, quindi i QPS scalano con il volume di digitazione attivo. La latenza influisce direttamente sulla conversione. Per un'architettura end-to-end, consulta Creazione di una ricerca di prodotti in tempo reale su Databricks.

Sistemi di raccomandazione/personalizzazione, come i pannelli "Potrebbe piacerti anche" sull'e-commerce, i feed personalizzati su piattaforme multimediali e di streaming. Ogni visualizzazione di pagina attiva una query di raccomandazione, quindi i picchi di traffico colpiscono prima il recupero. La latenza dei consigli si trova sul percorso critico della richiesta.

Risoluzione delle entità in tempo reale, come la corrispondenza dell'identità, la deduplicazione, la ricerca in cataloghi di grandi dimensioni al momento della richiesta. Qui la frequenza delle query è un SLA operativo, non un picco che si può bufferizzare.

Se riscontri uno dei seguenti problemi, probabilmente ne hai bisogno:

• Errori 429 (Too Many Requests) nei log di produzione
• Picchi di latenza P95 all'aumentare del traffico, anche con un utilizzo medio moderato
• Soluzioni temporanee come endpoint duplicati o load balancing lato client

Approfondimento sul funzionamento

Dichiarazione. Imposti un target di QPS sull'endpoint. Databricks calcola e fornisce la capacità di calcolo per raggiungere tale target. Nessun numero di repliche, nessun dimensionamento dei nodi, nessuna pianificazione della capacità.

Funziona con gli endpoint esistenti. Aggiorna qualsiasi endpoint Standard tramite Python SDK, REST API o l'interfaccia utente. La nuova capacità ha effetto alla successiva creazione o sincronizzazione di un indice sull'endpoint.

Monitoraggio dello stato di scaling. Il campo scaling_info sull'endpoint tiene traccia dei progressi durante il passaggio da SCALING_CHANGE_IN_PROGRESS to SCALING_CHANGE_APPLIED.

Osservabilità in produzione. La gestione di un sistema di recupero in produzione richiede visibilità su richieste al secondo, latenza delle richieste e integrità dell'endpoint. L'interfaccia utente dell'endpoint ora mostra tutti e tre questi elementi per ogni endpoint.

Usa l'autenticazione tramite entità servizio per massimizzare le prestazioni. Il traffico delle entità servizio viene instradato attraverso reti ottimizzate per le prestazioni, create per carichi di lavoro di produzione con QPS elevati. Il traffico dei token di accesso personale (PAT) è limitato a poche decine di QPS, il che lo rende adatto alla prototipazione ma non alla produzione. Consulta la guida alle prestazioni per la procedura completa.

Dimensionamento. Utilizza l'interfaccia utente di osservabilità dell'endpoint e l'integrazione nativa di Genie per comprendere i pattern di traffico e impostare target_qps con un margine sufficiente per i picchi.

Inizia a creare oggi stesso

La differenza tra prototipo e produzione è ora un parametro di configurazione. Lo scaling ad alti QPS è generalmente disponibile oggi, senza necessità di attivazione. Due modi per iniziare:

• Avvia un nuovo endpoint con target_qps impostato sul tuo target iniziale
• Aggiorna un endpoint esistente con target_qps per scalare l'indice che già serve la tua applicazione

Novità in arrivo

Continuiamo a semplificare la gestione della ricerca su scala. Lo scaling automatico per i picchi di traffico (senza pianificazione manuale della capacità o dimensionamento) e il supporto per gli endpoint ottimizzati per l'archiviazione sono previsti per la fine di quest'anno.

Per approfondire:

• Documentazione su QPS elevati
• Panoramica di Databricks AI Search
• Best practice per le prestazioni
• Creazione di una ricerca di prodotti in tempo reale su Databricks

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale