La performance éprouvée de Redis |  Redis

La performance éprouvée de Redis | Redis

redis proven performance 1

Récemment, un fournisseur NoSQL connu a annoncé l’ajout de fonctionnalités en mémoire à son offre de base de données. La décision d’adopter une approche hybride avec leur offre de base de données soulève quelques préoccupations sérieuses. Redis, le magasin clé-valeur open source en mémoire, a fourni de nombreuses informations sur le monde des applications modernes. Une observation particulièrement accrocheuse est le besoin inhérent de bases de données avec des capacités en mémoire. En conséquence, les fournisseurs NoSQL à tous les niveaux ont travaillé avec diligence pour exploiter les avantages des bases de données sur disque et en mémoire.

Chez Redis, nous pensons que cette approche hybride est erronée. Notre préoccupation vient du fait que les fournisseurs utilisant cette approche ne peuvent pas réussir à fournir les avantages que les bases de données telles que Redis, avec uniquement des capacités en mémoire, ont apportées aux applications modernes. Dans son post récent, Salvatore Sanfilippo a énuméré trois facteurs importants des performances de la base de données, notamment la latence, la vitesse de fonctionnement et la qualité de fonctionnement. Les scénarios réels suivants illustrent ces trois facteurs sur la base de l’expérience que nous avons acquise en prenant en charge des dizaines de milliers d’applications modernes.

Avant de plonger dans chacun de ces composants de performance, j’aimerais partager les résultats d’une étude de recherche interne que nous avons menée pour comparer les performances d’un certain nombre de bases de données SQL et NoSQL populaires. Comme on le voit ci-dessous, il ne fait aucun doute que les bases de données en mémoire fonctionnent nettement mieux.

redis proven performance 2

Comparaison des performances des réponses NoSQL et SQL

Trois critères principaux

Tous les systèmes en mémoire peuvent être mesurés selon trois critères principaux : la latence, le débit et l’efficacité. Semblable aux trois facteurs importants de performance des bases de données de Sanfilippo, l’excellence de ces critères permet aux bases de données en mémoire, telles que Redis, de fonctionner nettement mieux que leurs rivales sur disque. Pour cette raison, les bases de données en mémoire sont devenues essentielles pour les applications modernes et évolutives et le traitement en temps réel.

1 – Latence : les applications modernes nécessitent une latence d’environ 100 ms entre le moment où une requête parvient à une application et celui où elle est traitée. L’application génère une réponse et la renvoie à l’utilisateur. Pour ce faire, le niveau de la base de données doit fonctionner avec une latence constante inférieure à la milliseconde, qui est uniquement accomplie par une base de données en mémoire qui récupère toutes les données directement à partir de la RAM.

2 – Débit : De nos jours, les performances des applications doivent évoluer instantanément. Prenez un compte Twitter avec 1 million de followers par exemple. Un seul tweet destiné à atteindre 1 million de personnes génère instantanément 1 million d’écritures simultanées et nécessite une mise à l’échelle immédiate. Ces types d’événements se produisent constamment sans aucun avertissement préalable, créant des défis importants pour le système.

Des scénarios comme celui-ci nécessitent une infrastructure qui peut évoluer instantanément. La mise à l’échelle automatique ne fera pas l’affaire, car le provisionnement de nœuds supplémentaires sur un cluster existant peut prendre plusieurs minutes. Et la construction d’une infrastructure NoSQL complète uniquement pour répondre aux demandes pendant les heures de pointe coûte très cher. En conséquence, un nombre croissant de développeurs conçoivent des applications en temps réel entièrement à partir de zéro avec Redis.

3 – Efficacité : Bien qu’une base de données en mémoire puisse être extrêmement rapide, ses performances continueront d’être médiocres si elle transfère constamment de grandes quantités de données brutes entre la base de données et une application. Le traitement redondant des données brutes non seulement gaspille des ressources, mais augmente également la latence. De plus, ce transfert de données brutes peut potentiellement bloquer l’ensemble de l’infrastructure réseau, nécessitant l’ajout de nœuds afin de maintenir la vitesse du réseau.

À l’aide des types de données et des commandes uniques de Redis, il est possible de créer un schéma de manière à ce que la base de données soit réglée pour répondre aux demandes des applications sans aucun traitement supplémentaire au niveau de l’application. Cette conception intelligente réduit considérablement la quantité de données transférées.

redis proven performance 3La figure de droite illustre un scénario réel d’un de nos clients. Sans Redis, ils auraient dû créer un cluster de plus de 150 nœuds pour prendre en charge une vitesse de réseau de 120 Gbit/s. De plus, ils auraient nécessité un travail accru au niveau de l’application. Redis fonctionne avec un cluster de six nœuds en mémoire, 1,5 Gbit/s, et aucun travail supplémentaire au niveau de l’application.

Choisir la base de données appropriée

Tenter de résoudre des problèmes que Redis a déjà résolus en ajoutant des fonctionnalités en mémoire à une base de données incompatible est voué à l’échec.

Chez Redis, nous croyons en une approche best-of-breed. Il n’y a aucune raison de se contenter d’un seul type de base de données, qu’elle soit en mémoire ou sur disque. Les applications modernes et évolutives doivent être conçues de manière à garantir que chaque composant exploite la base de données appropriée.

(Note de l’auteur : Un grand merci à Salvatore Sanfilippo pour la conversation fructueuse qui a conduit aux idées de cet article.)

Development Source

Related Posts

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Clés Redis dans la RAM |  Redis

Clés Redis dans la RAM | Redis

No Comment

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *