Annuncio di VDBBench 1.0: benchmarking open-source di VectorDB con i tuoi carichi di lavoro di produzione reali
La maggior parte dei benchmark per database vettoriali testa con dati statici e indici pre-costruiti. Ma i sistemi di produzione non funzionano così: i dati fluiscono continuamente mentre gli utenti eseguono query, i filtri frammentano gli indici e le caratteristiche delle prestazioni cambiano drasticamente sotto carichi di lettura/scrittura concorrenti.
Oggi rilasciamo VDBBench 1.0, un benchmark open-source progettato da zero per testare i database vettoriali in condizioni di produzione realistiche: ingestione di dati in streaming, filtraggio dei metadati con selettività variabile e carichi di lavoro concorrenti che rivelano i reali colli di bottiglia del sistema.
Scarica VDBBench 1.0 → | Visualizza la classifica →
Perché i benchmark attuali sono fuorvianti
Siamo onesti: c'è uno strano fenomeno nel nostro settore. Tutti parlano di "non manipolare i benchmark", eppure molti partecipano esattamente a questo comportamento. Da quando il mercato dei database vettoriali è esploso nel 2023, abbiamo visto numerosi esempi di sistemi che "ottengono risultati splendidi nei benchmark" ma "falliscono miseramente" in produzione, sprecando tempo di ingegneria e danneggiando la credibilità dei progetti.
Abbiamo osservato questo scollamento in prima persona. Ad esempio, Elasticsearch vanta velocità di query a livello di millisecondi, ma dietro le quinte può impiegare oltre 20 ore solo per ottimizzare il proprio indice. Quale sistema di produzione può tollerare un tale tempo di inattività?
Il problema deriva da tre difetti fondamentali:
Dataset obsoleti: molti benchmark si basano ancora su dataset legacy come SIFT (128 dimensioni), mentre gli embedding moderni vanno da 768 a 3.072 dimensioni. Le caratteristiche prestazionali dei sistemi che operano su vettori 128D rispetto a vettori 1024D+ sono fondamentalmente diverse: pattern di accesso alla memoria, efficienza degli indici e complessità computazionale cambiano tutti drasticamente.
Metriche di vanità: i benchmark si concentrano sulla latenza media o sul QPS di picco, creando un quadro distorto. Un sistema con latenza media di 10 ms ma latenza P99 di 2 secondi crea un'esperienza utente terribile. Il throughput di picco misurato su 30 secondi non dice nulla sulle prestazioni sostenute.
Scenari eccessivamente semplificati: la maggior parte dei benchmark testa flussi di lavoro di base "scrivi dati, costruisci indice, interroga": essenzialmente test di livello "Hello World". La produzione reale implica ingestione continua di dati mentre si servono query, filtraggio complesso dei metadati che frammenta gli indici e operazioni di lettura/scrittura concorrenti che competono per le risorse.
Cosa c’è di nuovo in VDBBench 1.0?
VDBBench non si limita a iterare su filosofie di benchmarking obsolete: ricostruisce il concetto dai principi fondamentali con una convinzione guida: un benchmark è utile solo se predice il comportamento effettivo in produzione.
Abbiamo progettato VDBBench per replicare fedelmente le condizioni del mondo reale lungo tre dimensioni critiche: autenticità dei dati, pattern dei carichi di lavoro e metodologie di misurazione delle prestazioni.
Diamo un'occhiata più da vicino alle nuove funzionalità introdotte.
🚀 Dashboard riprogettata con visualizzazioni rilevanti per la produzione
La maggior parte dei benchmark si concentra solo sull'output dei dati grezzi, ma ciò che conta è come gli ingegneri interpretano e agiscono su quei risultati. Abbiamo riprogettato l'interfaccia utente per dare priorità alla chiarezza e all'interattività, consentendoti di individuare i divari prestazionali tra i sistemi e prendere decisioni infrastrutturali rapide.
La nuova dashboard visualizza non solo i numeri delle prestazioni, ma anche le relazioni tra di essi: come il QPS degrada sotto diversi livelli di selettività dei filtri, come il recall fluttua durante l'ingestione in streaming e come le distribuzioni della latenza rivelano le caratteristiche di stabilità del sistema.
VDBbench dashboard
Abbiamo ritestato le principali piattaforme di database vettoriali, tra cui Milvus, Zilliz Cloud, Elastic Cloud, Qdrant Cloud, Pinecone e OpenSearch, con le loro configurazioni più recenti e le impostazioni consigliate, assicurandoci che tutti i dati di benchmark riflettano le capacità attuali. Tutti i risultati dei test sono disponibili nella VDBBench Leaderboard.
🏷️ Filtraggio per tag: il killer nascosto delle prestazioni
Le query reali raramente avvengono in isolamento. Le applicazioni combinano la similarità vettoriale con il filtraggio dei metadati ("trova scarpe che assomigliano a questa foto ma costano meno di 100 $"). Questa ricerca vettoriale filtrata crea sfide uniche che la maggior parte dei benchmark ignora completamente.
Le ricerche filtrate introducono complessità in due aree critiche:
Complessità del filtro: un numero maggiore di campi scalari e condizioni logiche complesse aumenta le richieste computazionali e può causare un richiamo insufficiente e la frammentazione degli indici a grafo.
Selettività del filtro: questo è il "killer nascosto delle prestazioni" che abbiamo verificato ripetutamente in produzione. Quando le condizioni di filtraggio diventano altamente selettive (escludendo il 99%+ dei dati), le velocità delle query possono variare di ordini di grandezza e il richiamo può diventare instabile mentre le strutture degli indici faticano con insiemi di risultati sparsi.
VDBBench testa sistematicamente vari livelli di selettività del filtraggio (dal 50% al 99,9%), fornendo un profilo completo delle prestazioni in questo modello di produzione critico. I risultati rivelano spesso drastici cali di prestazioni che non emergerebbero mai nei benchmark tradizionali.
Esempio: nei test Cohere 1M, Milvus ha mantenuto un richiamo costantemente elevato a tutti i livelli di selettività del filtro, mentre OpenSearch ha mostrato prestazioni instabili, con il richiamo che fluttuava significativamente in diverse condizioni di filtraggio, scendendo sotto 0,8 in molti casi, il che è inaccettabile per la maggior parte degli ambienti di produzione.
Figura: QPS e richiamo di Milvus e OpenSearch a diversi livelli di selettività del filtro (test Cohere 1M).
🌊 Lettura/scrittura in streaming: oltre i test su indici statici
I sistemi di produzione raramente godono del lusso di dati statici. Nuove informazioni affluiscono continuamente mentre le ricerche vengono eseguite: uno scenario in cui molti database altrimenti impressionanti crollano sotto la doppia pressione di mantenere le prestazioni di ricerca gestendo al contempo scritture continue.
Gli scenari di streaming di VDBBench simulano operazioni parallele reali, aiutando gli sviluppatori a comprendere la stabilità del sistema in ambienti ad alta concorrenza, in particolare il modo in cui la scrittura dei dati incide sulle prestazioni delle query e come le prestazioni evolvono con l'aumento del volume dei dati.
Per garantire confronti equi tra sistemi diversi, VDBBench utilizza un approccio strutturato:
Configurare tassi di scrittura controllati che rispecchiano i carichi di lavoro di produzione target (ad es., 500 righe/sec distribuite su 5 processi paralleli)
Attivare operazioni di ricerca dopo ogni 10% di ingestione dei dati, alternando modalità seriale e concorrente
Registrare metriche complete: distribuzioni della latenza (incluso P99), QPS sostenuti e accuratezza del richiamo
Tracciare l'evoluzione delle prestazioni nel tempo man mano che il volume dei dati e lo stress del sistema aumentano
Questo test di carico controllato e incrementale rivela quanto bene i sistemi mantengano stabilità e accuratezza durante l'ingestione continua, qualcosa che i benchmark tradizionali raramente catturano.
Esempio: nei test di streaming Cohere 10M, Pinecone ha mantenuto QPS e richiamo più elevati durante l'intero ciclo di scrittura rispetto a Elasticsearch. In particolare, le prestazioni di Pinecone sono migliorate significativamente dopo il completamento dell'ingestione, dimostrando una forte stabilità sotto carico sostenuto, mentre Elasticsearch ha mostrato un comportamento più irregolare durante le fasi di ingestione attiva.
Figura: QPS e richiamo di Pinecone vs. Elasticsearch nel test di streaming Cohere 10M (tasso di ingestione di 500 righe/s).
VDBBench va ancora oltre supportando un passaggio di ottimizzazione opzionale, consentendo agli utenti di confrontare le prestazioni della ricerca in streaming prima e dopo l'ottimizzazione dell'indice. Inoltre, traccia e riporta il tempo effettivamente speso in ciascuna fase, offrendo approfondimenti più dettagliati sull'efficienza del sistema e sul comportamento in condizioni simili alla produzione.
Figura: QPS e Recall di Pinecone vs. Elasticsearch nel Cohere 10M Streaming Test dopo l'ottimizzazione (tasso di ingestione di 500 righe/s)
Come mostrato nei nostri test, Elasticsearch ha superato Pinecone in QPS—dopo l'ottimizzazione dell'indice. Ma quando l'asse x riflette il tempo effettivo trascorso, è chiaro che Elasticsearch ha impiegato significativamente più tempo per raggiungere quelle prestazioni. In produzione, quel ritardo conta. Questo confronto rivela un compromesso chiave: throughput di picco vs. time-to-serve.
🔬 Dataset moderni che riflettono i carichi di lavoro AI attuali
Abbiamo completamente rinnovato i dataset usati per il benchmarking dei database vettoriali. Invece di set di test legacy come SIFT e GloVe, VDBBench utilizza vettori generati da modelli di embedding all'avanguardia come OpenAI e Cohere, che alimentano le applicazioni AI di oggi.
Per garantire la rilevanza, specialmente per casi d'uso come Retrieval-Augmented Generation (RAG), abbiamo selezionato corpora che riflettono scenari aziendali reali e specifici di dominio:
| Corpus | Modello di embedding | Dimensioni | Dimensione | Caso d'uso |
|---|---|---|---|---|
| Wikipedia | Cohere V2 | 768 | 1M / 10M | Base di conoscenza generale |
| BioASQ | Cohere V3 | 1024 | 1M / 10M | Specifico di dominio (biomedico) |
| C4 | OpenAI | 1536 | 500K / 5M | Elaborazione di testo su scala web |
| MSMarco V2 | udever-bloom-1b1 | 1536 | 1M / 10M / 138M | Ricerca su larga scala |
Questi dataset simulano meglio i dati vettoriali ad alto volume e alta dimensionalità di oggi, consentendo test realistici dell'efficienza di archiviazione, delle prestazioni delle query e dell'accuratezza del recupero in condizioni che corrispondono ai carichi di lavoro AI moderni.
⚙️ Supporto per dataset personalizzati per test specifici del settore
Ogni azienda è unica. Il settore finanziario potrebbe aver bisogno di test focalizzati sugli embedding delle transazioni, mentre le piattaforme social sono più interessate ai vettori del comportamento degli utenti. VDBBench ti consente di eseguire benchmark con i tuoi dati generati dai tuoi specifici modelli di embedding per i tuoi specifici carichi di lavoro.
Puoi personalizzare:
Dimensioni dei vettori e tipi di dati
Schema dei metadati e pattern di filtraggio
Volume dei dati e pattern di ingestione
Distribuzioni delle query che corrispondono al tuo traffico di produzione
Dopotutto, nessun dataset racconta una storia migliore dei tuoi dati di produzione.
Come VDBBench misura ciò che conta davvero in produzione
Progettazione delle metriche focalizzata sulla produzione
VDBBench dà priorità alle metriche che riflettono le prestazioni nel mondo reale, non solo i risultati di laboratorio. Abbiamo riprogettato il benchmarking attorno a ciò che conta davvero negli ambienti di produzione: affidabilità sotto carico, caratteristiche della latenza di coda, throughput sostenuto e conservazione dell'accuratezza.
Latenza P95/P99 per l'esperienza utente reale: La latenza media/mediana maschera gli outlier che frustrano gli utenti reali e possono indicare un'instabilità di sistema sottostante. VDBBench si concentra sulla latenza di coda come P95/P99, rivelando quali prestazioni il 95% o il 99% delle tue query otterrà effettivamente. Questo è cruciale per la pianificazione degli SLA e per comprendere l'esperienza utente nel caso peggiore.
Throughput sostenibile sotto carico: Un sistema che funziona bene per 5 secondi non basta in produzione. VDBBench aumenta gradualmente la concorrenza per trovare il numero massimo sostenibile di query al secondo (
max_qps) del tuo database—non il numero di picco in condizioni brevi e ideali. Questa metodologia rivela quanto bene il tuo sistema regge nel tempo e aiuta con una pianificazione della capacità realistica.Richiamo bilanciato con le prestazioni: La velocità senza accuratezza è priva di significato. Ogni numero relativo alle prestazioni in VDBBench è abbinato a misurazioni del richiamo, così sai esattamente quanta rilevanza stai scambiando per il throughput. Questo consente confronti equi, alla pari, tra sistemi con compromessi interni molto diversi.
Metodologia di test che riflette la realtà
Un'innovazione chiave nel design di VDBBench è la separazione tra test seriali e concorrenti, che aiuta a catturare come i sistemi si comportano sotto diversi tipi di carico e rivela caratteristiche prestazionali importanti per diversi casi d'uso.
Separazione della misurazione della latenza:
serial_latency_p99misura le prestazioni del sistema sotto carico minimo, dove viene elaborata una sola richiesta alla volta. Questo rappresenta lo scenario migliore per la latenza e aiuta a identificare le capacità di base del sistema.conc_latency_p99cattura il comportamento del sistema in condizioni realistiche ad alta concorrenza, dove più richieste arrivano simultaneamente e competono per le risorse del sistema.
Struttura del benchmark in due fasi:
Test seriale: Esecuzione a processo singolo di 1.000 query che stabilisce prestazioni e accuratezza di base, riportando sia
serial_latency_p99sia il richiamo. Questa fase aiuta a identificare il limite teorico delle prestazioni.Test di concorrenza: Simula l'ambiente di produzione sotto carico sostenuto con diverse innovazioni chiave:
Simulazione realistica dei client: Ogni processo di test opera indipendentemente con la propria connessione e il proprio set di query, evitando interferenze da stato condiviso che potrebbero distorcere i risultati
Avvio sincronizzato: Tutti i processi iniziano simultaneamente, garantendo che il QPS misurato rifletta accuratamente i livelli di concorrenza dichiarati
Set di query indipendenti: Previene tassi di cache hit irrealistici che non riflettono la diversità delle query in produzione
Questi metodi attentamente strutturati garantiscono che i valori max_qps e conc_latency_p99 riportati da VDBBench siano sia accurati sia rilevanti per la produzione, fornendo informazioni significative per la pianificazione della capacità in produzione e la progettazione del sistema.
Iniziare con VDBBench 1.0
VDBBench 1.0 rappresenta un cambiamento fondamentale verso benchmarking rilevanti per la produzione. Coprendo la scrittura continua dei dati, il filtraggio dei metadati con selettività variabile e carichi in streaming sotto pattern di accesso concorrenti, fornisce l'approssimazione più vicina agli ambienti di produzione reali oggi disponibile.
Il divario tra i risultati dei benchmark e le prestazioni reali non dovrebbe essere un gioco di supposizioni. Se stai pianificando di distribuire un database vettoriale in produzione, vale la pena capire come si comporta oltre i test di laboratorio idealizzati. VDBBench è open-source, trasparente e progettato per supportare confronti significativi, alla pari.
Non lasciarti influenzare da numeri impressionanti che non si traducono in valore in produzione. Usa VDBBench 1.0 per testare scenari importanti per la tua azienda, con i tuoi dati, in condizioni che riflettono il tuo carico di lavoro effettivo. L'era dei benchmark fuorvianti nella valutazione dei database vettoriali sta finendo: è ora di prendere decisioni basate su dati rilevanti per la produzione.
Prova VDBBench con i tuoi workload: https://github.com/zilliztech/VectorDBBench
Visualizza i risultati dei test dei principali database vettoriali: VDBBench Leaderboard
Hai domande o vuoi condividere i tuoi risultati? Unisciti alla conversazione su GitHub o connettiti con la nostra community su Discord.
Continua a leggere
A Few Notes from Databricks Data + AI Summit 2026: Why the Data Layer Matters Again
James Luan shares notes from Databricks Data + AI Summit 2026 on why production AI is pushing the data layer back to the center of infrastructure.
How Zilliz Ended Up at the Center of NVIDIA’s Unstructured Data Story at GTC 2026
If unstructured data is the context of AI, then the ceiling of AI applications will be set not just by models, but by how mature the infrastructure for unstructured data becomes.
Zilliz Cloud Now Available in Azure North Europe: Bringing AI-Powered Vector Search Closer to European Customers
The addition of the Azure North Europe (Ireland) region further expands our global footprint to better serve our European customers.