La première version du système de mise en cache des données en mémoire vive Dragonfly est désormais disponible, offrant la prise en charge des protocoles Memcached et Redis, tout en permettant d'effectuer des requêtes avec une performance bien supérieure et une consommation de mémoire réduite. Le système manipule les données au format clé/valeur et peut être utilisé comme une solution légère pour accélérer le fonctionnement de sites à fort trafic, en mettant en cache les requêtes lentes vers les bases de données et les données intermédiaires en mémoire. Le code de Dragonfly est écrit en C/C++ et est distribué sous la licence BSL (Business Source License).
La licence BSL a été proposée par les cofondateurs de MySQL comme alternative au modèle Open Core. Le principe de la BSL est que le code des fonctionnalités avancées est initialement disponible pour modifications, mais pendant un certain temps, il peut être utilisé gratuitement uniquement sous certaines conditions, ce qui nécessite l'achat d'une licence commerciale pour contourner ces conditions. Les conditions de licence supplémentaires du projet Dragonfly prévoient que le code soit transféré à la licence Apache 2.0 uniquement le 1er juin 2027. Jusqu'à cette date, la licence autorise l'utilisation du code uniquement pour faire fonctionner ses propres services et produits, mais interdit l'utilisation pour créer des services cloud payants reposant sur Dragonfly.
Selon les développeurs et les tests réalisés, Dragonfly prétend être le système de stockage en mémoire le plus rapide. Comparé à Redis, Dragonfly a réussi à obtenir une augmentation de performance de 25 fois et une réduction de la consommation de mémoire de trois fois sous des charges typiques. serveur Dragonfly peut traiter des millions de requêtes par seconde, par exemple, dans un environnement Amazon EC2 c6gn.16xlarge, une performance de 3,8 millions de requêtes par seconde a été atteinte.
Dans des tests de stockage de 5 Go de données, Dragonfly a nécessité 30 % de mémoire en moins que Redis. Lors de la création de snapshots par l'équipe « bgsave », la consommation de mémoire augmente, mais durant les pics, elle reste presque trois fois inférieure à celle de Redis, et l'opération d'enregistrement du snapshot se déroule beaucoup plus rapidement (dans le test, le snapshot dans Dragonfly a été enregistré en 30 secondes, tandis que Redis a mis 42 secondes).
Une performance élevée est atteinte grâce à une architecture multithread sans partage de ressources (shared-nothing), impliquant qu'un gestionnaire séparé, avec sa propre portion de données, est associé à chaque thread, fonctionnant sans mutex ni spin-locks. Pour garantir l'atomicité lors de la manipulation de plusieurs clés, des verrous légers VLL sont utilisés. Une structure dashtable, qui met en œuvre une variété de tables de hachage partitionnées, est appliquée pour un stockage efficace des informations en mémoire.
Parmi les fonctionnalités disponibles dans la première version, on note le support du protocole RESP2 et 130 commandes Redis, ce qui correspond à peu près à la fonctionnalité de la version Redis 2.8. De plus, Dragonfly prend en charge toutes les commandes memcached, sauf CAS (check-and-set), offre un support pour les opérations asynchrones afin de créer des instantanés, garantit une consommation de mémoire prévisible, inclut un interpréteur Lua 5.4 intégré et prend en charge des types de données complexes tels que des hachages, des ensembles et des listes (ZSET, HSET, LIST, SETS et STRING).
Un mode de mise en cache est disponible, où le remplacement des anciennes données par de nouvelles se fait automatiquement après l'épuisement de la mémoire disponible. Il est possible d'attacher un temps de vie aux données, durant lequel celles-ci sont considérées comme valides. L'état du stockage peut être sauvegardé sur disque en arrière-plan pour une restauration ultérieure après un redémarrage. Un console HTTP est fournie pour gérer le système (attachée au port TCP 6379) et une API compatible avec Prometheus pour fournir des métriques. Les prochaines versions prévoient d'élargir le support des commandes Redis et de mettre en œuvre la possibilité de réplication du stockage pour garantir la tolérance aux pannes et l'équilibrage de charge.
Source : opennet.ru
