Comparaison entre Redis Enterprise 5.2.0 et Hazelcast 3.9

Comparaison entre Redis Enterprise 5.2.0 et Hazelcast 3.9

Arrière plan

Hazelcast a publié deux benchmarks comparant son système à la base de données open source Redis :

    • La première (publié le 20 mai 2016) a injustement comparé quatre instances autonomes de Redis 3.0.7 open source s’exécutant sur le réseau avec un cluster Hazelcast IMDG 3.6 à 4 nœuds fonctionnant en mode quasi-cache.
    • La deuxième (publié le 4 avril 2017) a comparé la version 3.2.8 du cluster open source Redis (avec 48 instances maîtres et 48 instances esclaves exécutées sur un cluster à 3 nœuds) avec un cluster Hazelcast IMDG 3.8 à 3 nœuds, tous deux exécutés sur le réseau.

Récemment, plusieurs prospects et clients nous ont demandé d’exécuter un benchmark similaire (sur le réseau) entre Redis Enterprise et Hazelcast. Étant donné que les clusters Redis Enterprise sont basés sur une architecture différente des clusters open source (comme expliqué plus en détail ici), nous voulions voir s’il y aurait des différences dans ces résultats.

Configuration de référence

Au début, nous avions pour objectif de reproduire exactement la même configuration de référence utilisée par Hazelcast, mais ils utilisaient apparemment du matériel propriétaire. En tant qu’entreprise née dans le cloud, chez Redis, nous n’hébergeons pas un seul serveur en interne et avons donc décidé de rechercher une configuration de serveur similaire sur AWS. Voici la configuration que nous avons utilisée :

Configuration matérielle

Paramètre Évaluer
Machines serveur et client
  • Instance EC2 de type m4.10xlarge : Intel E5 160 Go de RAM 10 Go Xeon E5-2676
  • RAM : 160 Go de mémoire
  • Réseau : Ethernet 10 Gbit/s
Nombre de machines serveurs 3
Nombre de machines clientes 3

Configuration du logiciel et du cluster

Entreprise Redis Noisette
Version du système d’exploitation Ubuntu 16.04
Version de cluster 5.2.0 3.9
Configuration du cluster
  • 48 maîtres + 48 esclaves (16 + 16 sur chaque nœud)
  • 16 threads proxy sur chaque nœud de cluster
3 membres

Outil de génération de charge

Dans ses benchmarks, Hazelcast a utilisé RadarGun pour orchestrer la charge générée à la fois contre Hazelcast et Redis. Dans l’affaire Redis, RadarGun lancé un Amas Jedis et utilisé un fichier de configuration similaire à cette (bien que nous n’ayons pas pu trouver la configuration exacte dans cette fourche répertoriée par Hazelcast).

L’utilisation du bon outil pour tester un produit est cruciale pour exécuter un benchmark réussi. Par exemple, la plupart des experts préféreraient tester Redis avec un technique de canalisation, car cela accélère Redis et est utilisé par une grande partie des utilisateurs de Redis. Cependant, nous n’avons pas trouvé de configuration de pipeline dans les benchmarks Hazelcast.

Nous avons donc opté pour l’approche suivante :

  • Utilisez le RadarGun orchestrateur pour tester Hazelcast (nous avons fait l’hypothèse que depuis qu’il a été sélectionné par Hazelcast, l’entreprise était probablement satisfaite des résultats de référence qu’elle a produits pour son système).
  • Utilisation memtier_benchmark (un outil de génération de charge open source pour Redis et Memcached) pour tester Redis, avec l’API Redis Cluster.

Configuration de la génération de charge

Entreprise Redis Noisette
Version memtier_benchmark
version 1.2.8
RadarGun version 3.0.0
Nombre de threads par client 64
Rapport lecture/écriture 80:20
Nombre d’objets 4 millions
Taille de l’objet Chaînes avec une distribution aléatoire des longueurs entre 100 octets et 10 000 octets
Taille totale de l’ensemble de données 42 Go
Ligne de commande utilisée memtier_benchmark – mode cluster
-s -p –key-maximum=4000000 –test-time=900 –data-size-range=100-10000
-c 1 -t 64 –conduite=5
–motif-clé=P:P –ratio=1:4
–distinct-client-seed
dist.sh -c benchmark-hazelcast-server.xml -t -u ubuntu -o `pwd` -m ip-radargun:2103 ip-server-1 ip-server-2 ip-server-3 ip-client-1 ip -client-2 client IP

Résultats de référence

Les résultats de notre benchmark sont présentés ci-dessous :

res1

res2

Sommaire

Nous avons relancé le benchmark comparant Hazelcast à Redis sur le réseau avec deux changements majeurs :

  1. Cette fois, nous avons testé un cluster Redis Enterprise par opposition à la version open source de Redis.
  2. Nous avons utilisé le memtier_benchmark outil de génération de charge plutôt que RadarGun pour tester Redis Enterprise avec l’API Redis Cluster open source.

Nous avons trouvé que les résultats des performances de Hazelcast étaient très similaires (ou meilleurs) à ce que la société avait publié ici. Par conséquent, nous avons tendance à croire que le cluster Hazelcast et le RadarGun orchestrator ont été configurés correctement.

D’autre part, nos résultats ont atteint un débit (plus de 3,5X) et une latence (~3X) bien meilleurs pour le cluster Redis Enterprise que ceux de Hazelcast. Nous pensons que ces différences étaient liées à :

  1. Hazelcast utilisant un outil inapproprié pour comparer Redis (nous pensons également que si leur équipe avait utilisé le bon outil de génération de charge, le benchmark open source de Hazelcast aurait montré de bien meilleurs résultats pour Redis) ; et
  2. Redis Enterprise est conçu pour bien fonctionner avec une combinaison de pipelining et de l’API de cluster open source.

annexe

Résultats Redis Entreprise

Screenshot from 2018 08 07 18 03 05

Résultats Hazelcast

Screenshot from 2018 08 08 09 07 36

Screenshot from 2018 08 08 09 07 47

Screenshot from 2018 08 08 08 53 53

Orchestrateur de référence RadarGun
Screenshot from 2018 07 11 19 10 03

Si vous avez des questions concernant ce benchmark, n’hésitez pas à m’envoyer un e-mail : keren sur redis.com. Si vous souhaitez en savoir plus sur Redis Enterprise, visitez ici ou email produit sur redis.com.

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 *