La première version du système de mise en cache en mémoire Dragonfly est disponible, prenant en charge les protocoles Memcached et Redis, mais permettant d'exécuter des requêtes avec des performances bien supérieures et une consommation de mémoire moindre. 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 travail des sites à forte charge, en mettant en cache les requêtes lentes dans le SGBD et les données intermédiaires dans la RAM. Le code Dragonfly est écrit en C/C++ et est distribué sous licence BSL (Business Source License).
La licence BSL a été proposée par les co-fondateurs de MySQL comme alternative au modèle Open Core. L'essence de BSL est que le code des fonctionnalités avancées est initialement disponible pour modification, mais pendant un certain temps, il ne peut être utilisé gratuitement que si des conditions supplémentaires sont remplies, qui nécessitent l'achat d'une licence commerciale pour être contournées. Les conditions de licence supplémentaires du projet Dragonfly nécessitent que le code soit transféré vers la licence Apache 2.0 uniquement le 1er juin 2027. Jusqu'à présent, la licence autorise l'utilisation du code uniquement pour assurer le fonctionnement de ses services et produits, mais interdit son utilisation pour la création de services cloud payants qui servent de module complémentaire à Dragonfly.
Selon les développeurs et les tests démontrés, Dragonfly prétend être le système de stockage de mémoire le plus rapide. Par rapport à Redis, Dragonfly a obtenu des performances multipliées par 25 et une consommation de mémoire réduite par trois pour les charges de travail typiques. Un serveur Dragonfly peut traiter des millions de requêtes par seconde. Par exemple, dans l'environnement Amazon EC2 c6gn.16xlarge, il a été possible d'atteindre des performances de 3.8 millions de requêtes par seconde.
Lors des tests de stockage de 5 Go de données, Dragonfly nécessitait 30 % de mémoire en moins que Redis. Lors de la création d'instantanés avec la commande « bgsave », la consommation de mémoire augmente, mais aux moments de pointe, elle reste presque trois fois inférieure à celle de Redis, et l'opération d'enregistrement d'instantané elle-même est beaucoup plus rapide (dans le test, un instantané dans Dragonfly a été écrit en 30 secondes, tandis que Redis - en 42 secondes).
Les hautes performances sont obtenues grâce à une architecture multithread sans partage de ressources (shared-nothing), ce qui signifie que chaque thread se voit attribuer un processeur distinct avec sa propre partie de données, fonctionnant sans mutex ni verrous de rotation. Pour garantir l'atomicité lorsque vous travaillez avec plusieurs clés, des verrous VLL légers sont utilisés. Pour stocker efficacement les informations en mémoire, la structure dashtable est utilisée, qui implémente un type de table de hachage partitionnée.
Parmi les fonctionnalités disponibles dans la première version, on note la prise en charge du protocole RESP2 et de 130 commandes Redis, ce qui correspond approximativement aux fonctionnalités de la version Redis 2.8. De plus, Dragonfly prend en charge toutes les commandes memcached à l'exception de CAS (check-and-set), prend en charge les opérations asynchrones de création d'instantanés, fournit une consommation de mémoire prévisible, fournit un interpréteur Lua 5.4 intégré et prend en charge les types de données complexes tels que les hachages, ensembles et listes (ZSET, HSET, LIST, SETS et STRING).
Un mode de mise en cache est disponible séparément, qui remplace automatiquement les anciennes données par de nouvelles données une fois la mémoire libre épuisée. Il est possible d'attacher une durée de vie aux données pendant laquelle les données sont considérées comme pertinentes. L'état de stockage peut être vidé sur le disque en arrière-plan pour une récupération ultérieure après le redémarrage. Pour gérer le système, une console HTTP est fournie (se lie au port TCP 6379) et une API de renvoi de métriques, compatible avec Prometheus. Dans les versions futures, nous prévoyons d'étendre la prise en charge des commandes Redis et de mettre en œuvre la possibilité de répliquer le stockage pour assurer la tolérance aux pannes et l'équilibrage de charge.
Source: opennet.ru