Zaris vs Redis, medido con honestidad
Rendimiento totalmente medido en Azure sobre el protocolo Redis — clústeres de 4 y 8 núcleos hasta tres nodos, cada cifra verificada por CPU del servidor. En nodos de producción de 8 núcleos Zaris supera a Redis en cada tamaño de clúster y se adelanta aún más a medida que añades núcleos. También mostramos la contrapartida honesta: Zaris usa más memoria. Cada cifra aquí es reproducible desde el repositorio de benchmarks de código abierto.
Metodología — y transparencia total
- Generador de cargamemtier_benchmark (Docker, red del host) para Redis y Zaris-RESP; un generador de cliente nativo personalizado y de código abierto (NativeBench) para las cifras nativas. Ambos manejan valores de 100 bytes, lectura/escritura 1:1.
- ServidoresAzure F4als_v6 (4 núcleos) y F8als_v6 (8 núcleos) — AMD Zen4 de última generación — en una sola VNet. Carga de cliente desde VMs F16als_v6 (16 núcleos).
- Justo con RedisA Redis se le da su mejor configuración:
--io-threads= número de núcleos con--io-threads-do-reads, persistencia desactivada y un Redis Cluster real. La carga se fija al nodo propietario de cada clave, de modo que cada motor se mide de forma idéntica. - Regla de paradaAumentamos la carga de cliente hasta que el rendimiento del servidor se aplana y la CPU del nodo se satura — verificado con
mpstat/docker stats, no con un número de clientes fijo. Una cifra solo cuenta cuando el límite es el servidor, no el cliente.
Nuestras reglas de honestidad
- Cada cifra de rendimiento se verificó por CPU del servidor en saturación — sin picos escogidos a conveniencia.
- Mostramos dónde Zaris se queda atrás, no solo dónde gana — incluido su mayor uso de memoria.
- Redis recibe su mejor configuración multinúcleo, no una degradada.
- Una carga de trabajo (100 B, 1:1) en SKUs específicas de Azure. La tuya será distinta — ejecútalo tú mismo.
Clúster de 8 núcleos: Zaris supera a Redis en cada tamaño
Clúster con protocolo Redis en nodos de 8 núcleos, con la CPU de cada nodo verificada saturada a la vez. Zaris lidera en un nodo (+87%), dos nodos (+70%) y tres (+81%) — un reemplazo directo, sin cambios en la aplicación.
Ambos escalan de forma casi lineal entre nodos; Zaris es simplemente mayor por nodo porque usa todos los núcleos, mientras que una sola instancia de Redis ejecuta comandos en un solo hilo. La memoria residente de Zaris rondó los 0.7–1.4 GiB por nodo con estas cargas — en su mayoría memoria de trabajo del GC que el entorno de ejecución retiene bajo la rotación de escrituras, no datos activos (la sobrecarga por registro es ~2.5× Redis; ver Memoria más abajo).
Zaris escala con los núcleos. Una sola instancia de Redis no.
Redis ejecuta comandos en un solo hilo por nodo, por lo que añadir núcleos apenas mueve su techo. El front-end RESP de Zaris es totalmente multihilo. Duplica los núcleos (4→8) en un solo nodo y Zaris casi se duplica (2.89M → 5.56M, 1.9×) mientras que Redis gana poco (2.45M → 2.97M, 1.2×). Por eso la ventaja crece desde un pequeño porcentaje en máquinas de 4 núcleos hasta +87% en 8 núcleos.
En nodos pequeños de 4 núcleos los dos están cerca (Zaris 2.89M vs Redis 2.45M). Cuanto mayor es la máquina, mayor es la ventaja de Zaris — así que en el hardware de producción que realmente desplegarías, Zaris gana de forma decisiva.
Puedes igualar los núcleos — pero no sin perder disponibilidad
La réplica habitual: ejecutar varias instancias de Redis por máquina para usar todos los núcleos. Puedes — pero cada instancia posee una porción del espacio de claves, así que una sola máquina ahora aloja múltiples shards. Cuando esa máquina cae, no pierdes un shard, pierdes todos a la vez — un radio de impacto mucho mayor, y cada uno necesita su propia conmutación por error. Zaris usa todos los núcleos en un nodo con un dominio de fallos y replicación integrada, de modo que la pérdida de un nodo es un propietario que cambia de manos, no una interrupción correlacionada de múltiples shards.
Clúster de 4 núcleos — medido, para completar
Incluso en nodos pequeños de 4 núcleos Zaris aventaja a Redis en cada tamaño de clúster, y ambos escalan de forma casi lineal hasta tres nodos. El margen es modesto aquí; es en los nodos más grandes donde Zaris se adelanta.
Aún más rápido a escala: el cliente nativo
Las cifras anteriores usan el protocolo Redis directo. Zaris también tiene su propio cliente binario nativo que habla directamente con el motor. En nodos de 8 núcleos se adelanta incluso a las cifras RESP a escala — 11.4M en 2 nodos, 18.5M en 3 — y supera a Redis hasta en 2.4×.†
† Estas cifras nativas usan un modo de servidor de alto rendimiento (opcional, para almacenes con factor de replicación 1) impulsado por el cliente nativo de .NET. En un solo nodo está más o menos a la par con RESP (~5.0M vs 5.56M); su ventaja se aprecia al escalar horizontalmente. Necesita la compilación del cliente nativo del repositorio de benchmarks, por lo que lo presentamos como una opción avanzada en lugar de la predeterminada. Las cifras RESP directas de arriba no necesitan nada especial.
Latencia por operación: sin penalización por compatibilidad
Una sola operación en curso (sin carga), nodo de 8 núcleos. El front-end con protocolo Redis de Zaris es indistinguible de Redis en latencia — la capa de compatibilidad no añade ningún coste medible.
Nota honesta: la latencia por operación del cliente nativo (~125 µs) se mide con el cliente gestionado de .NET, mientras que Redis y Zaris-RESP se miden con el cliente C memtier — así que esto compara pilas de cliente, no solo protocolos. La fortaleza de la ruta nativa es el rendimiento agregado a escala, no la latencia de una sola operación.
Memoria: la diferencia real es ~2.5×, no 10×
Mismo conjunto de datos — 1,000,000 de claves × valores de 100 bytes (~100 MB en bruto) en un solo nodo. Una instantánea residente en bruto situó a Zaris en 2.29 GiB frente a los 222 MiB de Redis — pero desglosar el heap cuenta una historia más veraz. Solo unos 0.5 GiB son datos activos — aproximadamente 2.5× Redis por registro, el coste de un motor gestionado (.NET) que mantiene metadatos por registro (etiquetas, entidad, tipo de contenido, TTL absoluto, un reloj de replicación) y estructuras de propiedad. El resto es memoria que el recolector de basura de .NET ha comprometido pero aún no ha devuelto al SO bajo una rotación de escrituras sostenida (la postura de retención predeterminada del GC de servidor); un límite del heap del GC reduce de nuevo el conjunto de trabajo. Así que la diferencia real por registro es de aproximadamente 2–3×, y es ajustable — no el 10× que sugiere la cifra residente. Para cargas de trabajo de valores diminutos limitadas por memoria Redis sigue siendo más ligero; Zaris cambia algo de memoria por rendimiento, escalado con núcleos y HA integrada.
Las advertencias honestas
Memoria: ~2.5× por registro, no 10×
Una instantánea residente en bruto mostró 2.29 GiB frente a los 222 MiB de Redis para 1M × 100 B — pero un desglose del heap sitúa solo ~0.5 GiB de eso en datos activos (~2.5× Redis por registro, para metadatos + replicación). El resto es memoria de trabajo del GC que el entorno de ejecución retiene bajo la rotación de escrituras, que un límite del heap del GC reduce. Aun así, tenlo en cuenta para cargas de trabajo de valores diminutos limitadas por memoria.
Las cifras nativas son opcionales
Las cifras nativas de 11–18M usan un modo de servidor de alto rendimiento opcional (RF1) más el cliente nativo de .NET del repositorio de benchmarks. Las cifras RESP directas — que ya superan a Redis — no necesitan nada especial.
La latencia nativa es mayor
Por operación individual, el cliente nativo gestionado mide ~125 µs frente a ~81–83 µs de Redis/RESP a través del cliente C memtier. Eso compara pilas de cliente; la fortaleza de lo nativo es el rendimiento a escala.
El margen depende del tamaño del nodo
En nodos pequeños de 4 núcleos Zaris lidera solo ligeramente. Las victorias decisivas (+70–87%) se dan en nodos de producción de 8 núcleos, porque Zaris escala con los núcleos y una sola instancia de Redis no.
Una carga de trabajo, una nube
Valores de 100 bytes, una mezcla de lectura/escritura 1:1, claves aleatorias, en SKUs específicas de Azure AMD Zen4. Tamaños, proporciones y hardware diferentes moverán las cifras.
Mide la tuya
Todo el arnés — scripts, generadores de carga, metodología — es de código abierto. Reproduce cada cifra en tu clúster, tamaño de nodo y carga de trabajo, que es la única comparación que importa.
No nos creas sin más — mídelo
Todo el arnés de benchmarks es de código abierto: los scripts, los generadores de carga y la metodología exacta. Levanta un clúster, ejecútalo en tu hardware y carga de trabajo, y compara.