lancedb study

Benchmark LancedB: Performances de recherche en texte complet et vecteur

Code de l'étude de référence décrite dans cet article de blog.

LancedB est une base de données vectorielle open source, intégrée et adaptée aux développeurs. Certaines fonctionnalités clés de LancedB qui le rendent extrêmement précieuse sont répertoriées ci-dessous, entre autres répertoriées sur leur dépôt GitHub.

• Incroyablement léger (pas de serveurs DB à gérer), car il fonctionne entièrement en cours avec l'application
• Extrêmement évolutif du développement à la production
• Capacité à effectuer une recherche en texte intégral (FTS), SQL Search (via DataFusion) et Ann Vector Search
• Prise en charge des données multimodales (images, texte, vidéo, audio, points ponctuels, etc.)
• Zéro-copy (via Arrow) avec version automatique des données sur son format de stockage Lance natif

Le but de ce dépôt est de démontrer les caractéristiques de recherche en texte intégral et vectorielles de LancedB via une référence de bout en bout, dans laquelle nous étudions soigneusement les résultats de la requête et le débit.

Ensemble de données

L'ensemble de données utilisé pour cette démo est l'ensemble de données de revues de vin de Kaggle, contenant ~ 130k avis sur les vins ainsi que d'autres métadonnées. L'ensemble de données est converti en archive zip, et le code pour cela ainsi que les données zip sont fournies ici pour référence.

Comparaison

L'étude des performances de n'importe quel outil isolément est un défi, donc par souci de comparaison, un flux de travail Elasticsearch est fourni dans ce repo. Elasticsearch est un moteur de recherche de texte complet et vectoriel populaire basé sur Lucene dont l'utilisation est régulièrement justifiée pour le texte intégral (et ces jours-ci, la recherche de vecteurs), ce qui en fait un outil significatif pour comparer LancedB contre.

Installation

Installez les dépendances dans un environnement virtuel via requirements.txt .

 # Setup the environment for the first time
python -m venv .venv  # python -> python 3.11+

# Activate the environment (for subsequent runs)
source .venv/bin/activate

python -m pip install -r requirements.txt

Résultats de référence

Note

• Les chiffres ci-dessous proviennent d'un MacBook Pro 2022 M2 avec 16 Go de RAM
• L'espace de recherche comprend 129 971 descriptions de revue du vin dans LancedB ou Elasticsearch
• Les requêtes sont échantillonnées au hasard à partir d'une liste de 10 exemples de requêtes pour la recherche de FTS et de vecteurs, et exécutent des requêtes aléatoires de 10, 100, 1000 et 10000
• La dimensionnalité vectorielle pour les intérêts est de 384 ( BAAI/bge-small-en-v1.5 )
• La recherche vectorielle dans Elasticsearch est basée sur Lucene-HNSW, et dans LancedB, est basé sur IVF-PQ
• La métrique de distance pour la recherche vectorielle est la similitude des cosinus dans l'une ou l'autre dB
• Les temps d'exécution signalés (et les QP calculés) sont en moyenne plus de 3 points

Résumé des résultats pour 10 000 requêtes aléatoires:

Cas	Elasticsearch (QPS)	LancedB (QPS)
FTS: série	399.8	468.9
FTS: simultanément	1539.0	528.9
Recherche de vecteur: série	11.9	54.0
Recherche vectorielle: simultanée	50.7	71.6

Discussion

• Via leurs clients Python, LancedB est clairement plus rapide que Elasticsearch en termes de QPS (requêtes par seconde) pour le cas d'utilisation de recherche de vecteur, et est également plus rapide pour le cas d'utilisation de recherche en texte complet lors de l'utilisation de plusieurs threads simultanément.
• Elasticsearch est plus rapide uniquement pour le cas d'utilisation FTS, en particulier dans le scénario simultané, probablement car il utilise un client asynchrone non bloquant (contrairement à LancedB, pour l'instant).
• À l'avenir, si un client Python asynchronisé (non bloquant) est disponible pour LancedB, le débit pour LancedB pour FTS devrait être encore plus élevé.

Référence en série

La référence série ci-dessous implique des requêtes séquentiellement exécutées dans une synchronisation pour la boucle dans Python. Ce n'est pas représentatif d'un cas d'utilisation réaliste dans la production, mais est utile pour comprendre les performances des moteurs de recherche sous-jacents dans chaque cas (Lucene pour Elasticsearch et Tantivy pour LancedB).

Plus de détails à ce sujet seront discutés dans un article de blog.

Recherche de texte intégral (FTS)

Requêtes	Elasticsearch (SEC)	Elasticsearch (QPS)	LancedB (sec)	LancedB (QPS)
10	0,0516	193.8	0,0518	193.0
100	0,2589	386.3	0,2383	419.7
1000	2.5748	388.6	2.1759	459.3
10000	25.0318	399.8	21.3196	468.9

Recherche vectorielle

Requêtes	Elasticsearch (SEC)	Elasticsearch (QPS)	LancedB (sec)	LancedB (QPS)
10	0,8087	12.4	0,2158	46.3
100	7.6020	13.1	1.6803	59.5
1000	84.0086	11.9	16.7948	59.5
10000	842.9494	11.9	185.0582	54.0

Référence simultanée

La référence simultanée est conçue pour reproduire un cas d'utilisation réaliste pour LancedB ou Elasticsearch - où plusieurs requêtes arrivent en même temps, et l'API REST en plus de la base de données doit gérer les demandes asynchrones.

Note

• La concurrence dans Elasticsearch est obtenue par le biais de son client asynchronisé
• La concurrence dans LancedB est obtenue via la bibliothèque multiprocessing de Python sur 4 threads de travail (un nombre plus élevé de threads a entraîné des performances plus lentes).

Recherche de texte intégral (FTS)

Requêtes	Elasticsearch (SEC)	Elasticsearch (QPS)	LancedB (sec)	LancedB (QPS)
10	0,0350	285.7	0,0284	351.4
100	0.1243	804.1	0.2049	487.8
1000	0,6972	1434.5	1.8980	526.8
10000	6.4948	1539.0	18.9136	528.9

Recherche vectorielle

Requêtes	Elasticsearch (SEC)	Elasticsearch (QPS)	LancedB, 4 threads (sec)	LancedB, 4 threads (QPS)
10	0,2896	34.5	0.1409	71.0
100	2.5275	39.6	1.3367	74.8
1000	20.4268	48.9	13.3158	75.1
10000	197.2314	50.7	139.6330	71.6