Précédemment publié sur Nuclia.com. Nuclia est maintenant Progress Agentic RAG.
NucliaDB est le moteur de base de données distribué open source conçu pour la plateforme AI Search de Nuclia afin de s’adapter efficacement à diverses charges de travail et ensembles de données.
C’est plus qu’une base de données vectorielle typique. Il s’agit d’une base de données de recherche robuste et hybride conçue pour répondre à divers besoins en matière de stockage, d’indexation, de récupération et de recherche de données non structurées.
Il s’agit d’un élément important de l’offre cloud complète de Nuclia pour AI Search.
Dans cet article, je vais vous donner un aperçu de notre architecture et de la façon dont nous faisons évoluer NucliaDB chez Nuclia.
Architecture de stockage de données
NucliaDB est plus qu’une simple base de données vectorielle typique. Nous devons prendre en charge le stockage d’une gamme de différents types de données tout en prenant en charge plusieurs types d’index.
Pour y parvenir, notre architecture de stockage de données est construite autour d’une approche de couche de données à 3 niveaux.
Niveau 3 : données Blob
C’est ici que nous stockons les fichiers et les données extraites. NucliaDB est compatible avec les services Amazon S3 et Google Cloud Storage (GCS).
Niveau 2 : stockage clé-valeur
Notre couche de stockage clé-valeur est notre principale couche de stockage de ressources, de champs et de métadonnées.
Toutes les métadonnées des ressources et des champs sont stockées ici.
Pour cela, nous utilisons TiKVune base de données clé-valeur ACID hautement évolutive et tolérante aux pannes.
Niveau 1 : données d’indexation
Notre couche de stockage d’index fragmenté est notre couche de stockage la plus complexe.
Chaque fragment est un package de nos index qui alimentent notre recherche hybride.
Boîtes de connaissances, données d’indexation et partage
Avec Nuclia, le conteneur d’organisation des données de niveau supérieur est appelé « Knowledge Box ».
Une boîte de connaissances est une collection de fichiers, de vidéos, d’audio et de tout autre type de données non structurées sur lesquelles vous souhaitez pouvoir effectuer des recherches sémantiques ou obtenir des réponses génératives.
Chaque Knowledge Box peut alors avoir de nombreux « fragments » où ses données d’index sont gérées.
Partage dynamique
Du point de vue de l’architecture des données, nous avons construit notre architecture autour de la mise à l’échelle des recherches vectorielles dans une boîte de connaissances. Les index vectoriels peuvent utiliser beaucoup de disque et de mémoire, il est donc important d’avoir une stratégie de partitionnement efficace.
De plus, afin de mieux faire évoluer notre base de données de manière dynamique, nous souhaitions une stratégie de partitionnement qui ne nécessite pas que vous connaissiez à l’avance la taille correcte de vos données.
Par exemple, dans les stratégies de partitionnement utilisées par des bases de données comme ElasticSearch, vous devez connaître à l’avance le nombre de partitions que votre ensemble de données doit utiliser. Des stratégies comme celle-ci peuvent fonctionner correctement pour les données de séries chronologiques, mais ne fonctionnent pas pour d’autres cas d’utilisation.
Le partitionnement dynamique nous permet d’ajouter des fragments de données d’index à une boîte de connaissances au fur et à mesure de sa croissance. Nous gérons la taille de nos fragments principalement en contrôlant le nombre de vecteurs stockés dans l’index. Lorsque nous atteignons notre seuil, nous créons un nouveau fragment.
Architecture de stockage de fragments et de nœud d’indexation
La partie centrale de notre base de données est notre composant Index Node. Un nœud d’index gère le disque et lit et écrit sur ce disque pour un ensemble de répliques de fragments. Une réplique de fragment est une instance de fragment.
Puisque nous voulons être tolérants aux pannes et mettre à l’échelle dynamiquement les lectures, nos fragments peuvent avoir de nombreuses répliques. Chaque Shard Replica intègre 4 index distincts dans un objet de stockage de réplique unifié et transportable. Nos répliques sont ensuite réparties sur de nombreux nœuds d’index.
Cloud natif + autonome
Nous avons conçu NucliaDB pour qu’il soit Cloud-Native et dynamiquement évolutif.
NucliaDB est déployée en tant qu’architecture de service. La recherche, les lectures, les écritures, l’indexation, le traitement et l’ingestion sont tous évolutifs de manière dynamique.
Nous utilisons NATS comme notre bus de messages et GRPC pour la communication de service à service.
NucliaDB autonome
NucliaDB Standalone est un package de NucliaDB avec toutes les batteries incluses et un seul processus à exécuter. Il permet aux clients d’utiliser la puissance de Nuclia sur site tout en conservant l’entière propriété de leurs propres données.
Ce qui est unique à propos de NucliaDB, c’est que même s’il est cloud natif, utilisant NATS et GRPC pour communiquer entre les systèmes afin de fournir un système cloud évolutif robuste, NucliaDB peut également être exécuté dans ce mode autonome simple.
Python + Rouille
Nous sommes en mesure de fournir une expérience utilisateur autonome en partie grâce à la façon dont nous pouvons tirer parti de l’intégration des liaisons Python PyO3 de Rust. En utilisant Python et Rust ensemble, nous sommes en mesure de développer plus rapidement tout en gardant la partie importante de notre base de données extrêmement rapide.
La rouille PyO3 La prise en charge des liaisons est un excellent moyen de coller Python et Rust ensemble et a permis à Nuclia d’intégrer des couches de service directement dans Python. Ainsi, les composants qui communiquent normalement via GRPC peuvent être intégrés via les liaisons PyO3.
Mettre tout cela ensemble
En utilisant une architecture de données à plusieurs niveaux et une conception de service Cloud-Native, nous sommes en mesure de faire évoluer le service Cloud de Nuclia.
Nuclia est bien plus qu’une simple base de données. Il s’agit d’une solution complète avec traitement texte/docs/vidéo/audio, inférence, recherche sémantique, réponses génératives, API REST, application de bureau et une interface utilisateur dans une solution unique.
Source link