Le serveur unique Redis Cloud Cluster de 1,2 million d’opérations/seconde Unbenchmark

Le serveur unique Redis Cloud Cluster de 1,2 million d’opérations/seconde Unbenchmark

1.2M unbenchmark art

Tout en rattrapant le monde l’autre jour, j’ai lu le post invité High Scalability de Anshu et Rajkumar d’Aerospike (excellent travail d’ailleurs). J’ai vraiment apprécié l’ensemble de la pièce et j’ai été impressionné par les ajustements importants qu’ils ont apportés à leur instance EC2 pour atteindre la marque 1M, mais je n’arrêtais pas de me demander – comment Redis ferait-il?

J’aurais pu faire un benchmark complet. Mais faire un benchmark complet est une épreuve consommatrice de temps et de ressources. Et c’est sans compter les difficultés initiales de comparer des pommes, des oranges et d’autres sortes de fruits. Un vrai benchmark est un piège, car il n’est rien de plus qu’un effort jugé dès le départ comme en retard. Mais je voulais une réponse, et je la voulais rapidement, alors j’étais prêt à faire quelques sacrifices pour l’obtenir. Cela signifiait faire la meilleure chose suivante – une référence.

Un non-benchmark n’est, selon (ma propre) définition, rien à voir avec un benchmark (d’où son nom). Dans ce document, vous coupez tous les coins et relâchez chaque hypothèse pour obtenir un chiffre approximatif rapide et sale. En nous appuyant fortement sur l’expertise des gars de nos laboratoires, nous avons mesuré les performances de notre logiciel Redis Cloud sans aucune autre optimisation. Nous avons exécuté notre unbenchmark avec la configuration suivante :

  • Un fragmenté1 Serveur de base de données NoSQL en mémoire Redis Cloud exécuté sur une seule instance Amazon (voir mes notes sur le partitionnement et les clusters Redis Cloud ci-dessous).
  • 3 000 000 d’objets, chacun d’une taille de 100 octets.
  • La memtier_benchmark tool client exécuté sur une instance non serveur à l’aide des arguments de ligne de commande suivants : `–ratio=1:1 -n 1000000 -d 100 -t 1 -c 50 –pipeline=75 –key-pattern=S:S`.
  • Une charge de travail qui mélange les lectures et les écritures dans des proportions égales (nous n’avons pas de parti pris particulier pour un type d’opération par rapport à l’autre et pensons que ce mélange reflète mieux la vie réelle).
  • Une instance c3.8xlarge à la demande.

Nous n’avions pas le temps de configurer un VPC et d’ajuster les groupes de placement pour des performances optimales, nous avons donc exécuté le tout dans notre environnement de service standard, c’est-à-dire sur un réseau EC2 bruyant et encombré. Nous n’avons pas non plus réglé le comportement du processeur, le nombre de threads ou la configuration des fragments pour cette expérience – nous avons laissé Redis Cloud utiliser ses valeurs par défaut. Nous n’avons pas testé plusieurs configurations réseau ni ajouté d’interfaces réseau élastiques (ENI) supplémentaires. Nous avons simplement pris un serveur Redis Cloud fraîchement provisionné sur HVM et avons fait l’analyse comparative par rapport à celui-ci…

Vous pouvez trouver la sortie brute de notre course dans cet essentiel, mais l’essentiel est qu’il a marqué un peu plus de 1,2 million de TPS (1228432 pour être exact). Naturellement, ce résultat étonnant m’a vraiment ouvert l’appétit et j’ai immédiatement demandé un benchmark complet, toutes optimisations incluses, épuisante et exhaustive, comprenant des fruits et légumes pour vraiment voir à quel point nous pouvons repousser les limites avec Redis ! Et devine quoi? C’est dans l’arriéré 🙂

1 Quelques notes sur le sharding et les clusters Redis Cloud (comme promis) :

De par sa conception, le serveur Redis est (principalement) un processus à un seul thread. Cela étant, le sharding est généralement utilisé pour faire évoluer une base de données Redis au-delà des limites d’un seul cœur de processeur ou de la capacité de RAM d’un seul serveur. Il existe trois approches généralement acceptées pour implémenter le sharding : côté client, proxy ou clustering. Étant donné que les solutions côté client et basées sur proxy pour le partitionnement de Redis sont plus faciles à mettre en œuvre indépendamment du moteur de base de données sous-jacent réel, ces (par exemple, Redis-rb et casse Noisette) existent depuis un certain temps maintenant. Il n’existe cependant que quelques solutions de cluster Redis aujourd’hui.

Un cluster Redis partitionné désigne un groupe de serveurs Redis (processus) déployés sur un ou plusieurs nœuds de calcul sur un réseau. Le cluster exécute des bases de données Redis, chacune couvrant potentiellement un certain nombre de nœuds et plusieurs cœurs, sur une quantité agrégée de RAM. Un cluster de niveau production doit également relever des défis tels que garantir la disponibilité de la base de données, ainsi que ses performances et la gestion de l’infrastructure et des ressources de la base de données.

L’implémentation la plus connue d’un cluster Redis est, naturellement, celle de l’open source. Grappe Redis (v3) est déjà à un stade avancé de bêta et devrait être prêt pour la production dans quelques mois. Cette prochaine version fournira d’excellentes réponses à bon nombre des défis que j’ai mentionnés. Parmi ses nombreuses nouvelles fonctionnalités, la nouvelle version OSS inclut également la possibilité de créer fragmenté groupes. Au nom de toute la communauté Redis (mes excuses si j’ai offensé quelqu’un en présumant :)), nous nous attendons à ce que la version 3 de Redis soit une nouvelle version majeure à tous égards !

Outre la v3 open source, il existe déjà quelques autres clusters Redis. Certaines personnes sont allées de l’avant et ont construit leurs propres clusters, chacune pour ses propres raisons. Je ne veux nommer personne (commeTwitter, Flickr ou Pinterest) mais une entreprise qui a construit un cluster est Redis. Notre service Redis Cloud est alimenté par notre propre implémentation d’un cluster Redis et il a été utilisé en production pendant la majeure partie des deux dernières années. Au cours de cette période, nous avons construit et exploité nos clusters sur plusieurs clouds et régions de données. En tant qu’entreprise en démarrage, nous avons dû construire nos systèmes pour qu’ils évoluent à la fois bien et économiquement afin de répondre au succès spectaculaire de notre service public commercial.

Redis est un contributeur au projet open source Redis – la plupart de nos employés sont des développeurs incroyables qui vivent et respirent Redis – mais nos utilisateurs avaient besoin de solutions qui n’étaient pas prêtes dans le cadre de l’open source. Afin de relever ces défis commerciaux, nous avons développé des solutions qui nous permettent de faire évoluer les bases de données Redis à la volée de mégaoctets à téraoctets. Nous déployons, adaptons et gérons des clusters sur quatre fournisseurs IaaS différents et sur environ 20 centres de données. Nos utilisateurs ont créé des dizaines de milliers de bases de données, et pour chaque base de données, nous avons non seulement maintenu la disponibilité et les performances, mais également pris en charge les tâches opérationnelles et administratives (le tout avec un petite équipe devops).

Pour utiliser nos clusters Redis Cloud, il vous suffit de vous inscrire à notre service et de créer une base de données. Vous pouvez configurer une base de données partitionnée en quelques secondes (bien que la partition ne soit pas incluse dans notre offre gratuite). Les instances Redis Cloud peuvent être partitionnées à l’aide de la politique standard, c’est-à-dire Spécification de cluster Redis open sourceou avec une puissante stratégie de partitionnement personnalisée entièrement configurable via une liste de règles d’expression régulière (voir la page d’aide de la fonctionnalité et mises à jour futures pour plus d’informations).

Tant que je suis sur le sujet, voici l’un des faits les moins connus sur les clusters de Redis : vous n’avez rien à changer dans votre application pour commencer à les utiliser. Oui, vous pouvez utiliser votre code et votre bibliothèque client existants (qu’ils soient ou non compatibles avec le cluster et le sharding) et vous bénéficierez toujours de toute l’évolutivité, de la disponibilité et des avantages opérationnels qu’offre le cluster. Nos utilisateurs n’ont qu’à créer la base de données et configurer ses options (disponibilité, persistance des données, partitionnement, sécurité et autres) et bazinga ! Ils peuvent simplement utiliser l’URL Redis unique (nom d’hôte et port) qui est la passerelle vers leur base de données dans un cluster Redis. Bien sûr, il y a des ajustements, des meilleures pratiques, des optimisations, des conseils, des astuces et un million d’autres choses que vous pourriez faire en plus, mais (comme le montre l’unbenchmark), notre cluster est assez performant même sans eux.

J’avais voulu garder ces notes brèves, mais le clustering est un de mes sujets riches et préférés et je pourrais continuer encore et encore pendant des jours (en fait, je promets que je le ferai – plus d’annonces/techniques/benchmarks/spécifications/comparaisons à suivre) . Pour que ce post reste de taille moyenne, j’aimerais terminer ici et vous inviter à suivre nous et cri à moi – Je suis très disponible 🙂

Ce message a été initialement publié sur HighScalability.com le 27 août 2014.

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 *