Présentation
KiviDB apparaît sur GitHub comme une base de données en mémoire compatible avec le protocole Redis. Le projet se décrit comme plus rapide que Redis tout en ajoutant la prise en charge native de vecteurs, ce qui le rend intéressant pour les charges de travail d’embeddings et de recherche sémantique. Les dépôts publics contiennent le code source, la documentation d’installation et quelques exemples d’utilisation, mais aucune métrique détaillée n’est fournie dans le README.
Architecture et compatibilité Redis
Le moteur repose sur une implémentation du protocole RESP (Redis Serialization Protocol), ce qui permet aux clients Redis existants de se connecter sans modification. Cette compatibilité implique la prise en charge des commandes de base telles que GET, SET ou DEL. Le code source indique l’utilisation de structures de données en mémoire optimisées pour la latence, mais les spécifications exactes (par exemple, utilisation de tables de hachage lock‑free ou de slabs) ne sont pas détaillées publiquement.
Le projet mentionne également une architecture « single‑threaded » ou « multi‑threaded », sans préciser le modèle de concurrence. En l’absence d’informations précises, on peut supposer que la compatibilité Redis repose sur une couche d’abstraction qui traduit les requêtes RESP en appels internes, ce qui est une pratique courante dans les implémentations alternatives à Redis.
Gestion des vecteurs et performances
KiviDB ajoute un type de donnée dédié aux vecteurs, destiné à stocker des embeddings de dimensions élevées. Le README indique que les vecteurs sont indexés pour permettre des recherches de similarité, mais il ne décrit pas l’algorithme utilisé (par exemple, HNSW, IVF ou brute‑force). L’absence de benchmarks empêche de quantifier le gain de vitesse annoncé par rapport à Redis + module RedisVector.
Le code source montre l’utilisation de bibliothèques de calcul numérique (par exemple, SIMD ou BLAS) pour accélérer les opérations de produit scalaire. Cette approche est cohérente avec les exigences de calcul intensif des vecteurs, mais les performances réelles dépendent de la taille des vecteurs, du nombre d’éléments en mémoire et de la configuration du matériel.
Limites et perspectives
Sans données de charge ou de test, il est difficile d’évaluer la robustesse de KiviDB en production. Le projet ne fournit pas de mécanisme de persistance durable, ce qui limite son usage aux scénarios purement volatils ou aux caches temporaires. De plus, l’absence d’information sur la gestion de la réplication ou du clustering rend incertaine la capacité du système à supporter des déploiements à grande échelle.
Les contributeurs indiquent que le projet est en phase précoce et qu’ils accueillent les retours de la communauté. Une évolution possible serait l’intégration de stratégies de persistance et de réplication, ainsi que la publication de benchmarks comparatifs avec Redis et d’autres bases vectorielles. En attendant, les développeurs intéressés peuvent tester KiviDB dans des environnements de prototypage où la vitesse d’accès en mémoire et la compatibilité Redis sont les critères principaux.
