Zaris vs Redis, mesuré honnêtement
Débit entièrement mesuré sur Azure via le protocole Redis — clusters 4 cœurs et 8 cœurs jusqu'à trois nœuds, chaque chiffre vérifié par CPU serveur. Sur des nœuds 8 cœurs de taille production, Zaris dépasse Redis à chaque taille de cluster et creuse l'écart à mesure que vous ajoutez des cœurs. Nous montrons aussi le compromis honnête : Zaris utilise plus de mémoire. Chaque chiffre ici est reproductible depuis le dépôt de benchmark open source.
Méthodologie — et transparence totale
- Générateur de chargememtier_benchmark (Docker, réseau hôte) pour Redis et Zaris-RESP ; un générateur à client natif open source sur mesure (NativeBench) pour les chiffres natifs. Les deux pilotent des valeurs de 100 octets, lecture/écriture 1:1.
- ServeursAzure F4als_v6 (4 cœurs) et F8als_v6 (8 cœurs) — AMD Zen4 de génération actuelle — dans un même VNet. Charge client depuis des VM F16als_v6 (16 cœurs).
- Équitable envers RedisRedis est présenté sous son meilleur jour :
--io-threads= nombre de cœurs avec--io-threads-do-reads, persistance désactivée, et un vrai Redis Cluster. La charge est épinglée au nœud propriétaire de chaque clé, de sorte que chaque moteur est mesuré de façon identique. - Règle d'arrêtNous augmentons la charge client jusqu'à ce que le débit serveur s'aplatisse et que le CPU du nœud sature — vérifié avec
mpstat/docker stats, pas un nombre de clients fixe. Un chiffre ne compte que lorsque le serveur, et non le client, est la limite.
Nos règles d'honnêteté
- Chaque chiffre de débit a été vérifié par CPU serveur à saturation — aucun pic trié sur le volet.
- Nous montrons où Zaris est à la traîne, pas seulement où il gagne — y compris son usage mémoire plus élevé.
- Redis bénéficie de sa meilleure configuration multi-cœurs, pas d'une version bridée.
- Une seule charge de travail (100 o, 1:1) sur des SKU Azure spécifiques. La vôtre différera — exécutez-le vous-même.
Cluster 8 cœurs : Zaris dépasse Redis à chaque taille
Cluster en protocole Redis sur des nœuds 8 cœurs, le CPU de chaque nœud vérifié saturé simultanément. Zaris mène à un nœud (+87%), deux nœuds (+70%) et trois (+81%) — un remplacement direct, sans modification applicative.
Les deux montent en charge de façon quasi linéaire entre les nœuds ; Zaris est simplement plus élevé par nœud parce qu'il utilise tous les cœurs, là où une instance Redis unique exécute les commandes sur un seul thread. La mémoire résidente de Zaris tournait autour de 0.7–1.4 GiB par nœud à ces charges — essentiellement de la mémoire de travail du GC que le runtime retient sous le barattage d'écritures, et non des données vivantes (le surcoût par enregistrement est ~2,5× Redis ; voir Mémoire ci-dessous).
Zaris monte en charge avec les cœurs. Une instance Redis unique, non.
Redis exécute les commandes sur un seul thread par nœud, de sorte qu'ajouter des cœurs ne bouge presque pas son plafond. Le front-end RESP de Zaris est entièrement multi-thread. Doublez les cœurs (4→8) sur un seul nœud et Zaris double presque (2.89M → 5.56M, 1.9×) alors que Redis gagne peu (2.45M → 2.97M, 1.2×). C'est pourquoi l'avance passe de quelques pour cent sur des machines 4 cœurs à +87% sur 8 cœurs.
Sur de petits nœuds 4 cœurs, les deux sont proches (Zaris 2,89 M vs Redis 2,45 M). Plus la machine est grande, plus l'avance de Zaris est large — donc sur le matériel de production que vous déploieriez réellement, Zaris gagne de façon décisive.
Vous pouvez égaler les cœurs — mais pas sans perdre en disponibilité
La réfutation habituelle : lancez plusieurs instances Redis par machine pour utiliser tous les cœurs. Vous le pouvez — mais chaque instance possède une tranche de l'espace de clés, de sorte qu'une seule machine héberge désormais plusieurs shards. Quand cette machine tombe, vous ne perdez pas un shard, vous perdez tous d'un coup — un rayon d'impact bien plus large, et chacun nécessite son propre basculement. Zaris utilise tous les cœurs dans un seul nœud avec un seul domaine de défaillance et une réplication intégrée, de sorte que la perte d'un nœud revient à un propriétaire qui change de main, et non à une panne multi-shard corrélée.
Cluster 4 cœurs — mesuré, par souci d'exhaustivité
Même sur de petits nœuds 4 cœurs, Zaris devance Redis à chaque taille de cluster, et les deux montent en charge de façon quasi linéaire jusqu'à trois nœuds. La marge est modeste ici ; c'est sur les plus gros nœuds que Zaris prend le large.
Encore plus rapide à l'échelle : le client natif
Les chiffres ci-dessus utilisent le protocole Redis en remplacement direct. Zaris possède aussi son propre client binaire natif qui parle directement au moteur. Sur des nœuds 8 cœurs, il devance même les chiffres RESP à l'échelle — 11,4 M à 2 nœuds, 18,5 M à 3 — et dépasse Redis jusqu'à 2,4×.†
† Ces chiffres natifs utilisent un mode serveur à haut débit (opt-in, pour les stores à facteur de réplication 1) piloté par le client natif .NET. À un seul nœud, il est à peu près au niveau de RESP (~5,0 M vs 5,56 M) ; son avantage apparaît à mesure que vous montez en charge. Il nécessite la build du client natif présente dans le dépôt de benchmark, nous le présentons donc comme une option avancée plutôt que comme le choix par défaut. Les chiffres RESP en remplacement direct ci-dessus ne nécessitent rien de particulier.
Latence par opération : aucune pénalité de compatibilité
Une seule opération en vol (à vide), nœud 8 cœurs. Le front-end en protocole Redis de Zaris est indiscernable de Redis en latence — la couche de compatibilité n'ajoute aucun coût mesurable.
Note honnête : la latence par opération du client natif (~125 µs) est mesurée avec le client managé .NET, tandis que Redis et Zaris-RESP sont mesurés avec le client C memtier — cela compare donc des stacks client, pas seulement des protocoles. La force du chemin natif est le débit agrégé à l'échelle, pas la latence sur une seule opération.
Mémoire : le vrai écart est ~2,5×, pas 10×
Même jeu de données — 1 000 000 de clés × valeurs de 100 octets (~100 Mo bruts) sur un seul nœud. Un instantané résident brut plaçait Zaris à 2,29 GiB contre 222 MiB pour Redis — mais décomposer le tas raconte une histoire plus juste. Seulement environ 0,5 GiB sont des données vivantes — soit environ 2,5× Redis par enregistrement, le coût d'un moteur managé (.NET) qui conserve des métadonnées par enregistrement (labels, entité, type de contenu, TTL absolu, une horloge de réplication) et des structures de possession. Le reste est de la mémoire que le ramasse-miettes .NET a engagée mais pas encore rendue à l'OS sous un barattage d'écritures soutenu (la posture de rétention du GC serveur par défaut) ; une limite de tas GC fait redescendre l'ensemble de travail. Le vrai écart par enregistrement est donc d'environ 2–3×, et c'est réglable — pas le 10× que suggère le chiffre résident. Pour les charges de travail à petites valeurs limitées par la mémoire, Redis reste plus léger ; Zaris échange un peu de mémoire contre du débit, de la mise à l'échelle par cœurs et de la haute disponibilité intégrée.
Les mises en garde honnêtes
Mémoire : ~2,5× par enregistrement, pas 10×
Un instantané résident brut a montré 2,29 GiB vs 222 MiB pour Redis pour 1 M × 100 o — mais une décomposition du tas ne place que ~0,5 GiB de cela dans les données vivantes (~2,5× Redis par enregistrement, pour les métadonnées + la réplication). Le reste est de la mémoire de travail GC que le runtime retient sous le barattage d'écritures, qu'une limite de tas GC fait redescendre. À pondérer tout de même pour les charges de travail à petites valeurs limitées par la mémoire.
Les chiffres natifs sont en opt-in
Les chiffres natifs de 11–18 M utilisent un mode serveur à haut débit en opt-in (RF1) plus le client natif .NET du dépôt de benchmark. Les chiffres RESP en remplacement direct — qui dépassent déjà Redis — ne nécessitent rien de particulier.
La latence native est plus élevée
Par opération unique, le client natif managé mesure ~125 µs vs ~81–83 µs pour Redis/RESP via le client C memtier. Cela compare des stacks client ; la force du natif est le débit à l'échelle.
La marge dépend de la taille du nœud
Sur de petits nœuds 4 cœurs, Zaris ne mène que légèrement. Les victoires décisives (+70–87 %) sont sur des nœuds 8 cœurs de production, parce que Zaris monte en charge avec les cœurs et une instance Redis unique non.
Une charge de travail, un cloud
Valeurs de 100 octets, un mélange lecture/écriture 1:1, clés aléatoires, sur des SKU Azure AMD Zen4 spécifiques. Des tailles, des ratios et du matériel différents feront bouger les chiffres.
Mesurez les vôtres
L'ensemble du harnais — scripts, générateurs de charge, méthodologie — est open source. Reproduisez chaque chiffre sur votre cluster, votre taille de nœud et votre charge de travail, c'est la seule comparaison qui compte.
Ne nous croyez pas sur parole — mesurez-le
L'ensemble du harnais de benchmark est open source : les scripts, les générateurs de charge et la méthodologie exacte. Montez un cluster, exécutez-le sur votre matériel et votre charge de travail, et comparez.