Zaris vs. Redis, ehrlich gemessen
Vollständig gemessener Durchsatz auf Azure über das Redis-Protokoll — 4-Core- und 8-Core-Cluster bis zu drei Nodes, jede Zahl serverseitig CPU-verifiziert. Auf produktionsgroßen 8-Core-Nodes schlägt Zaris Redis bei jeder Cluster-Größe und baut den Vorsprung mit jedem zusätzlichen Core weiter aus. Wir zeigen auch den ehrlichen Kompromiss: Zaris benötigt mehr Speicher. Jede Zahl hier ist aus dem Open-Source-Benchmark-Repository reproduzierbar.
Methodik — und volle Transparenz
- Lastgeneratormemtier_benchmark (Docker, Host-Netzwerk) für Redis und Zaris-RESP; ein eigener Open-Source-Lastgenerator mit nativem Client (NativeBench) für die nativen Werte. Beide arbeiten mit 100-Byte-Werten und einem Lese-/Schreib-Verhältnis von 1:1.
- ServerAzure F4als_v6 (4 Cores) und F8als_v6 (8 Cores) — aktuelle AMD-Zen4-Generation — in einem VNet. Die Client-Last kommt von F16als_v6-VMs (16 Cores).
- Fair gegenüber RedisRedis wird bewusst bestmöglich aufgestellt:
--io-threads= Anzahl der Cores mit--io-threads-do-reads, Persistenz aus und ein echter Redis Cluster. Die Last wird auf den jeweils besitzenden Node jedes Keys gelenkt, sodass jede Engine identisch gemessen wird. - AbbruchregelWir erhöhen die Client-Last, bis der Server-Durchsatz abflacht und die Node-CPU saturiert ist — verifiziert mit
mpstat/docker stats, nicht mit einer festen Client-Anzahl. Eine Zahl zählt nur, wenn der Server, nicht der Client, das Limit ist.
Unsere Ehrlichkeitsregeln
- Jede Durchsatzzahl wurde bei Sättigung serverseitig CPU-verifiziert — keine herausgepickten Spitzenwerte.
- Wir zeigen, wo Zaris zurückliegt, nicht nur, wo es gewinnt — einschließlich des höheren Speicherbedarfs.
- Redis erhält seine beste Multi-Core-Konfiguration, keine gedrosselte.
- Ein Workload (100 B, 1:1) auf bestimmten Azure-SKUs. Ihre Werte werden abweichen — führen Sie es selbst aus.
8-Core-Cluster: Zaris schlägt Redis bei jeder Größe
Cluster über das Redis-Protokoll auf 8-Core-Nodes, die CPU jedes Nodes gleichzeitig nachweislich gesättigt. Zaris liegt bei einem Node (+87%), zwei Nodes (+70%) und drei (+81%) vorn — ein Drop-in-Ersatz, ohne Änderungen an der Anwendung.
Beide skalieren nahezu linear über Nodes hinweg; Zaris liegt pro Node schlicht höher, weil es jeden Core nutzt, während eine einzelne Redis-Instanz Befehle in einem Thread ausführt. Der residente Speicher von Zaris lag bei diesen Lasten bei etwa 0.7–1.4 GiB pro Node — überwiegend GC-Arbeitsspeicher, den die Runtime unter Schreib-Churn hält, nicht Live-Daten (der Overhead pro Datensatz beträgt ~2.5× Redis; siehe Speicher weiter unten).
Zaris skaliert mit den Cores. Eine einzelne Redis-Instanz nicht.
Redis führt Befehle in einem einzelnen Thread pro Node aus, sodass zusätzliche Cores seine Obergrenze kaum verschieben. Das RESP-Front-End von Zaris ist vollständig Multi-Threaded. Verdoppeln Sie die Cores (4→8) auf einem einzelnen Node, steigert Zaris sich nahezu auf das Doppelte (2.89M → 5.56M, 1.9×), Redis dagegen nur wenig (2.45M → 2.97M, 1.2×). Deshalb wächst der Vorsprung von wenigen Prozent auf 4-Core-Maschinen auf +87% auf 8 Cores.
Auf kleinen 4-Core-Nodes liegen beide dicht beieinander (Zaris 2.89M vs. Redis 2.45M). Je größer die Maschine, desto größer der Vorsprung von Zaris — auf der Produktionshardware, die Sie tatsächlich einsetzen würden, gewinnt Zaris also deutlich.
Sie können die Cores ausreizen — aber nicht ohne Verfügbarkeit einzubüßen
Der übliche Einwand: mehrere Redis-Instanzen pro Maschine betreiben, um alle Cores zu nutzen. Das geht — doch jede Instanz besitzt einen Teil des Keyspace, sodass eine einzelne Maschine nun mehrere Shards hostet. Fällt diese Maschine aus, verlieren Sie nicht einen Shard, sondern alle gleichzeitig — ein weitaus größerer Schadensradius, und jeder Shard braucht sein eigenes Failover. Zaris nutzt alle Cores mit: ein Node, ein Ausfallbereich, integrierte Replikation — ein Node-Verlust bedeutet, dass ein Besitzer wechselt, nicht dass mehrere Shards korreliert ausfallen.
4-Core-Cluster — der Vollständigkeit halber gemessen
Selbst auf kleinen 4-Core-Nodes liegt Zaris bei jeder Cluster-Größe knapp vor Redis, und beide skalieren bis zu drei Nodes nahezu linear. Der Abstand ist hier moderat; erst auf den größeren Nodes setzt sich Zaris ab.
Bei Skalierung noch schneller: der native Client
Die obigen Zahlen nutzen das Drop-in-Redis-Protokoll. Zaris hat außerdem einen eigenen nativen Binär-Client, der direkt mit der Engine spricht. Auf 8-Core-Nodes übertrifft er bei Skalierung sogar die RESP-Werte — 11.4M bei 2 Nodes, 18.5M bei 3 — und schlägt Redis um bis zu 2.4×.†
† Diese nativen Werte nutzen einen Server-Modus für hohen Durchsatz (optional, für Stores mit Replikationsfaktor 1), angesteuert vom nativen .NET-Client. Auf einem einzelnen Node liegt er etwa gleichauf mit RESP (~5.0M vs. 5.56M); sein Vorteil zeigt sich beim Hochskalieren. Er benötigt den nativen Client-Build im Benchmark-Repository, weshalb wir ihn als fortgeschrittene Option statt als Standard präsentieren. Die Drop-in-RESP-Werte oben brauchen nichts Besonderes.
Latenz pro Operation: keine Kompatibilitätsstrafe
Eine einzelne Operation in Bearbeitung (ohne Last), 8-Core-Node. Das Redis-Protokoll-Front-End von Zaris ist bei der Latenz von Redis nicht zu unterscheiden — die Kompatibilitätsschicht verursacht keine messbaren Kosten.
Ehrlicher Hinweis: Die Latenz pro Operation des nativen Clients (~125 µs) wurde mit dem verwalteten .NET-Client gemessen, Redis und Zaris-RESP dagegen mit dem C-Client memtier — verglichen werden also Client-Stacks, nicht nur Protokolle. Die Stärke des nativen Pfads ist der aggregierte Durchsatz bei Skalierung, nicht die Latenz einzelner Operationen.
Speicher: Der reale Abstand beträgt ~2.5×, nicht 10×
Gleicher Datensatz — 1.000.000 Keys × 100-Byte-Werte (~100 MB roh) auf einem Node. Ein roher Resident-Snapshot ergab für Zaris 2.29 GiB gegenüber 222 MiB bei Redis — doch die Aufschlüsselung des Heaps erzählt eine ehrlichere Geschichte. Nur etwa 0.5 GiB sind Live-Daten — rund 2.5× Redis pro Datensatz, der Preis einer verwalteten (.NET-)Engine, die pro Datensatz Metadaten (Labels, Entity, Content-Type, absolute TTL, eine Replikationsuhr) sowie Ownership-Strukturen vorhält. Der Rest ist Speicher, den der .NET-Garbage-Collector unter anhaltendem Schreib-Churn committed, aber noch nicht ans Betriebssystem zurückgegeben hat (die Retain-Haltung des Server-GC als Default); ein GC-Heap-Limit bringt das Working Set wieder herunter. Der reale Abstand pro Datensatz beträgt also etwa 2–3×, und einstellbar — nicht die 10×, die der Resident-Wert nahelegt. Für speichergebundene Workloads mit winzigen Werten ist Redis weiterhin schlanker; Zaris tauscht etwas Speicher gegen Durchsatz, Core-Skalierung und integrierte Hochverfügbarkeit.
Die ehrlichen Einschränkungen
Speicher: ~2.5× pro Datensatz, nicht 10×
Ein roher Resident-Snapshot zeigte 2.29 GiB vs. 222 MiB bei Redis für 1M × 100 B — doch eine Heap-Aufschlüsselung ordnet davon nur ~0.5 GiB den Live-Daten zu (~2.5× Redis pro Datensatz, für Metadaten + Replikation). Der Rest ist GC-Arbeitsspeicher, den die Runtime unter Schreib-Churn hält und den ein GC-Heap-Limit senkt. Bei speichergebundenen Workloads mit winzigen Werten sollten Sie es dennoch abwägen.
Die nativen Werte sind optional
Die nativen Werte von 11–18M nutzen einen optionalen Server-Modus für hohen Durchsatz (RF1) plus den nativen .NET-Client aus dem Benchmark-Repository. Die Drop-in-RESP-Werte — die Redis bereits schlagen — brauchen nichts Besonderes.
Die native Latenz ist höher
Pro Einzeloperation misst der verwaltete native Client ~125 µs vs. ~81–83 µs für Redis/RESP über den C-Client memtier. Das vergleicht Client-Stacks; die Stärke des nativen Pfads ist Durchsatz bei Skalierung.
Der Abstand hängt von der Node-Größe ab
Auf kleinen 4-Core-Nodes liegt Zaris nur knapp vorn. Die deutlichen Gewinne (+70–87 %) entstehen auf produktionsgroßen 8-Core-Nodes, weil Zaris mit den Cores skaliert und eine einzelne Redis-Instanz nicht.
Ein Workload, eine Cloud
100-Byte-Werte, ein Lese-/Schreib-Mix von 1:1, zufällige Keys, auf bestimmten Azure-AMD-Zen4-SKUs. Andere Größen, Verhältnisse und Hardware verschieben die Zahlen.
Messen Sie selbst
Das gesamte Harness — Skripte, Lastgeneratoren, Methodik — ist Open Source. Reproduzieren Sie jede Zahl auf Ihrem Cluster, mit Ihrer Node-Größe und Ihrem Workload; nur dieser Vergleich zählt.
Glauben Sie uns nicht einfach — messen Sie nach
Das gesamte Benchmark-Harness ist Open Source: die Skripte, die Lastgeneratoren und die genaue Methodik. Setzen Sie ein Cluster auf, führen Sie es auf Ihrer Hardware und mit Ihrem Workload aus und vergleichen Sie.