Dimensionamento di Lakebase Search: lezioni da un caso reale con 4 milioni di query

Slide Hub è un’applicazione Databricks interna che consente agli ingegneri di campo di trovare e riutilizzare diapositive estratte da circa 700 presentazioni interne: interventi a eventi, presentazioni di prodotto e di architettura. Una barra di ricerca permette di individuare le diapositive sia per significato sia per parole‑chiave, e un server Model Context Protocol (MCP) fornisce la stessa ricerca agli agenti IA.

Architettura dei dati e estensioni Lakebase

Tutte le diapositive, i voti, la telemetria delle ricerche e la cronologia delle modifiche sono memorizzate in Lakebase Postgres. Per valutare le prestazioni di questa soluzione, Slide Hub è stato utilizzato come benchmark reale, poiché coinvolge utenti autentici e un carico di lavoro produttivo.

L’estensione Lakebase Search, resa disponibile a tutti a partire da settembre, è composta da un set di estensioni Postgres che operano direttamente accanto alle tabelle applicative, eliminando la necessità di un sistema di ricerca separato e di un doppio flusso di transazioni.

• lakebasevector – memorizza gli embedding, vettori numerici che rappresentano il significato di un testo, e supporta l’indice lakebaseann per la ricerca dei vicini più prossimi approssimativi (ANN).
• lakebasetext – gestisce l’indice lakebasebm25 per BM25, un metodo standard di ranking basato sulla frequenza delle parole.
• lakebase_tokenizer – opzionale, fornisce tokenizzazione avanzata.

L’indice ANN utilizza il partizionamento IVF, che raggruppa vettori simili così che una query legga solo pochi gruppi, e la quantizzazione RaBitQ, che comprime ogni dimensione a circa 1 bit. BM25 attribuisce un punteggio al testo mediante l’operatore <@.

Strategia di ricerca ibrida

Slide Hub combina due metodi di ricerca:

• Ricerca vettoriale: identifica le diapositive con significato simile alla query.
• Ricerca per parole‑chiave (BM25): individua le diapositive contenenti i termini della query.

Entrambi i metodi restituiscono una breve lista di “candidati”. Una singola istruzione SQL gestisce l’intera pipeline di ranking, unendo i risultati, applicando filtri di autorizzazione, e aggiungendo i voti degli utenti.

Per ciascuna metodologia vengono conservati 200 candidati. I due elenchi vengono fusi con la tecnica Reciprocal Rank Fusion (RRF) con k = 60: a ciascun candidato viene assegnato il punteggio 1/(60 + rank) in ogni lista, e i punteggi vengono sommati. Un filtro di similitudine di 0,70 scarta i risultati vettoriali troppo distanti, mentre le priorità sui titoli aumentano il peso delle corrispondenze sul titolo. I voti degli utenti ricevono un peso di 0,5 e i filtri di ambito limitano i risultati alle risorse visibili all’utente.

Dimensionamento delle risorse di calcolo

Lakebase Postgres è dimensionato in Compute Units (CU). Una CU fornisce circa 2 GB di RAM, CPU e SSD locale. Le risorse possono scalare automaticamente da 0,5 CU a 64 CU, con un margine di 16 CU tra minimo e massimo. Le risorse a dimensione fissa arrivano fino a 112 CU, mentre quelle con limite di 32 CU possono ridursi a zero.

PostgreSQL archivia tabelle e indici in pagine da 8 KB. Lakebase conserva le pagine recentemente lette in un cache locale (LFC) che può occupare fino al 75 % della memoria della CU. Una pagina non presente nel cache deve essere letta dallo storage, aumentando la latenza.

L’applicazione Databricks Apps, che ospita il server web di Slide Hub, ha dimensioni fisse: la configurazione MEDIUM fornisce fino a 2 vCPU e 6 GB di RAM, mentre la configurazione LARGE offre 4 vCPU e 12 GB di RAM. Slide Hub utilizza una singola istanza, con ogni worker Python che mantiene un pool di 8 connessioni al database. Due worker consentono al massimo 16 connessioni simultanee; quattro worker ne consentono 32.

Metodologia di test e risultati

Per identificare il collo di bottiglia, i test hanno variato un solo parametro alla volta: si fissava la dimensione della CU di Lakebase e si cambiava la configurazione dell’applicazione, oppure si manteneva costante l’applicazione e si variava la CU. Un generatore di carico simulava utenti che inviavano query di ricerca, incrementando gradualmente il numero di utenti in step.

Le metriche principali erano il numero di richieste al secondo (req/s) e la latenza mediana (p50) per 500 utenti, misurate per ogni combinazione di CU e dimensione dell’applicazione.

Fase 1: limitazione da Lakebase

Con CU inferiori o uguali a 4, il limite era rappresentato da Lakebase. Una configurazione LARGE con il doppio di worker non migliorava le prestazioni a 1 CU. A 1 CU, il tempo medio di esecuzione della query era di 146 ms, con 14,9 M di pagine lette dallo storage e un cache di 1,5 GB. A 8 CU, il tempo medio scese a 34 ms, il cache aumentò a 12 GB, e il throughput migliorò di circa 50 %.

Fase 2: limitazione dall’applicazione

Superata la soglia di 8 CU, la velocità dell’applicazione divenne il collo di bottiglia. Passare a 16 CU con la stessa configurazione MEDIUM offriva solo un 4 % di guadagno aggiuntivo, poiché le connessioni al database rimanevano per lo più inattive. Una configurazione LARGE con 4 worker a 16 CU raggiungeva almeno 662 req/s; a questo punto, il generatore di carico era il limite.

Le raccomandazioni operative sono quindi:

• Identificare il limite iniziale (database o applicazione).
• Aumentare le CU di Lakebase finché i worker non diventano il collo di bottiglia.
• Scalare l’applicazione aggiungendo worker e connessioni.

Importanza del pool di connessioni

Il pool di connessioni si è rivelato cruciale. Con 50 utenti, senza pool l’applicazione gestiva 45 req/s con p95 di 2,4 s; con pool, la capacità è salita a 85 req/s con p95 di 0,7 s. Il cache degli embedding, invece, non ha mostrato differenze misurabili sotto carico.

Impatto della soglia dei candidati

Il numero di candidati influisce direttamente sul numero di pagine lette per query, soprattutto con cache a freddo. Inizialmente Slide Hub esponeva 1 000 candidati per metodo; la documentazione suggerisce 40. Ridurre il numero di candidati diminuisce il carico di I/O, abbassando la latenza.

In sintesi, l’esperimento con Slide Hub evidenzia come Lakebase Search possa gestire efficacemente ricerche ibride su dataset di dimensioni moderate, purché le risorse vengano dimensionate in modo equilibrato tra database e livello applicativo.

Conclusioni e linee guida per i progettisti

Per gli sviluppatori che intendono integrare una barra di ricerca o un agente IA su Lakebase Postgres, è fondamentale:

• Comprendere il modello di dati e le estensioni necessarie (vector, text, ann, bm25).
• Stabilire una soglia di candidati adeguata per limitare le letture di pagina.
• Utilizzare un pool di connessioni per massimizzare il throughput.
• Scalare prima il database (CU) fino a 8 CU, poi aumentare il numero di worker dell’applicazione.
• Monitorare costantemente i metriche di latenza e di I/O per individuare rapidamente il nuovo collo di bottiglia.

Seguendo queste indicazioni, è possibile ottenere prestazioni ottimali con costi controllati, garantendo al contempo una ricerca veloce e rilevante per gli utenti finali.