infoq Arquitecto Mensual

A mediados de este año, un ex ingeniero de Google y Amazon lanzó Dragonfly, un sistema de almacenamiento en caché de datos de memoria de código abierto que creó, escrito en C/C++ y distribuido en base a la licencia BSL (Business Source License). .

Según los resultados de pruebas comparativas anteriores, Dragonfly puede ser el sistema de almacenamiento de memoria más rápido del mundo. Proporciona soporte para los protocolos Memcached y Redis, pero puede realizar consultas y ejecutarse con un mayor rendimiento. . En comparación con Redis, Dragonfly logra una mejora de rendimiento 25 veces mayor bajo cargas de trabajo típicas; un solo servidor Dragonfly puede manejar millones de solicitudes por segundo en la prueba de almacenamiento de 5 GB; Dragonfly requiere un 30 % menos de memoria que Redis.

Como software de código abierto, Dragonfly recibió 9,2 mil estrellas de GitHub y 177 ramas de bifurcación en solo dos meses. Aunque en los últimos años han surgido muchos sistemas similares de almacenamiento de datos en memoria compatibles con Redis, como KeyDB y Skytable, ninguno de ellos ha sido tan "sensacional" como este. Después de todo, Redis existe desde hace más de diez años. En este momento, diseñar un sistema de almacenamiento en caché desde cero puede abandonar el bagaje histórico y hacer un mejor uso de los recursos.

Para luchar contra el recién surgido Dragonfly, el cofundador y director de tecnología de Redis, Yiftach Shoolman, el arquitecto jefe de Redis Labs, Yossi Gottlieb, y el ingeniero de rendimiento de Redis Labs, Filipe Oliveira, publicaron conjuntamente un artículo titulado "13 años finalmente". ¿Redis necesita una nueva arquitectura?

En el artículo, dieron específicamente los resultados de la prueba comparativa de Redis 7.0 frente a Dragonfly que consideran más justos: el rendimiento de Redis es entre un 18% y un 40% mayor que el de Dragonfly, así como algunas opiniones sobre la arquitectura de Redis y reflexiones para demostrar "por qué la arquitectura de Redis sigue siendo la mejor arquitectura para el almacenamiento de datos en memoria en tiempo real (cachés, bases de datos y todo lo demás)".

Aunque enfatizan que la arquitectura de Redis sigue siendo la mejor de su tipo, no pueden ignorar algunas ideas y tecnologías frescas e interesantes proporcionadas por este nuevo software. Dragonfly dijo que algunas de ellas incluso pueden ingresar a Redis. el futuro (por ejemplo, se ha estudiado io_uring, diccionarios más modernos, uso más estratégico de hilos, etc.).

Además, Redis señaló que el método de comparación del punto de referencia Dragonfly "no es representativo de cómo opera Redis en el mundo real". En respuesta, algunos internautas en Reddit respondieron:

Otros dijeron que este artículo era una negación cortés por parte del equipo de Redis de que "Dragonfly es el sistema de caché más rápido", pero más internautas dijeron que Redis emitió la "lucha" del artículo. atrás" significa que su departamento de marketing ha perdido:

Por supuesto, hemos estado buscando direcciones innovadoras para mejorar el rendimiento y ampliar las funciones de Redis, pero aquí queremos hablar sobre nuestras propias opiniones y pensamientos. explica por qué Redis sigue siendo hoy una de las mejores soluciones para el almacenamiento de datos en memoria en tiempo real, incluidos cachés, bases de datos y todo lo demás.

A continuación, nos centraremos en las opiniones de Redis sobre las diferencias de velocidad y arquitectura, y luego haremos comparaciones basadas en esto. Al final del artículo, también proporcionaremos resultados de referencia e información detallada sobre la comparación del rendimiento con el proyecto Dragonfly. Puede compararlo y consultarlo usted mismo.

El punto de referencia Dragonfly en realidad compara una instancia de Redis de proceso único independiente (que solo puede usar un único núcleo) con una instancia Dragonfly de subprocesos múltiples (que puede usar todos los núcleos disponibles en la VM/servidor). Obviamente, una comparación tan cruda no representa el estado de ejecución de Redis en escenarios reales. Como creadores de tecnología, queremos comprender con mayor precisión las diferencias entre nuestra propia tecnología y otras soluciones, por lo que aquí hacemos un pequeño ajuste de equidad: el clúster Redis 7.0 con 40 fragmentos (que puede usar la mayoría de los núcleos de instancia) compara el rendimiento con el tipo de instancia más grande utilizado por el equipo Dragonfly en los puntos de referencia (AWS c4gn.16xlarge).

En esta ronda de pruebas, vimos que Redis logró entre un 18% y un 40% más de rendimiento que Dragonfly, y esto solo utilizó 40 del total de 64 núcleos virtuales.

En nuestra opinión, cada desarrollador de un proyecto multiproceso guiará las decisiones arquitectónicas en función de los puntos débiles experimentados en trabajos anteriores antes de comenzar el proyecto. También reconocemos que ejecutar un único proceso de Redis en un dispositivo multinúcleo (que a menudo proporciona docenas de núcleos y cientos de GB de memoria) tiene el problema de la subutilización de recursos. Sin embargo, Redis no tuvo esto en cuenta cuando se diseñó originalmente, y muchos proveedores de servicios de Redis han ideado las soluciones correspondientes para ocupar un lugar en el mercado.

Redis se escala horizontalmente ejecutando múltiples procesos (usando un clúster de Redis), incluso en el contexto de una única instancia de nube. En Redis Company, llevamos este concepto más allá y creamos Redis Enterprise. Redis Enterprise proporciona una capa de gestión que permite a los usuarios ejecutar Redis a escala, con funciones como alta disponibilidad, conmutación por error instantánea, persistencia de datos y copia de seguridad habilitadas de forma predeterminada.

A continuación, planeamos compartir algunos de los principios utilizados detrás de escena para mostrarle cómo diseñamos buenas prácticas de ingeniería para aplicaciones de producción de Redis.

Al ejecutar varias instancias de Redis por máquina virtual, podemos:

No permitimos que un solo proceso de Redis supere los 25 GB de tamaño (el límite superior es 50 cuando se ejecuta Redis en Flash GB). De esta manera, podemos:

Ejecutar de manera flexible el almacenamiento de datos en memoria de manera escalable horizontalmente es la clave del éxito de Redis. Echemos un vistazo a las razones específicas:

Aún apreciamos las ideas interesantes y las soluciones técnicas propuestas por la comunidad. Se espera que algo de esto llegue a Redis en el futuro (ya hemos comenzado a trabajar en io_uring, diccionarios más modernos, estrategias de uso de subprocesos más ricas, etc.). Pero en el futuro previsible, no renunciaremos a los principios arquitectónicos básicos, como el intercambio ilimitado y el multiproceso, a los que se adhiere Redis. Este diseño no solo proporciona rendimiento, escalabilidad y resiliencia óptimos, sino que también admite varias arquitecturas de implementación necesarias para una plataforma de datos en memoria en tiempo real.

Apéndice: Detalles de la prueba comparativa de Redis 7.0 frente a Draonfly

Versión:

Destino:

Configuración del cliente:

Optimización de la configuración y utilización de recursos:

Finalmente, también descubrimos que ni Redis ni Dragonfly están limitados por los paquetes de red por segundo o el ancho de banda de transmisión. Hemos confirmado que cuando se usa TCP para pasar una carga de paquetes de aproximadamente 300 B entre 2 máquinas virtuales (que actúan como cliente y servidor respectivamente, y ambas usan instancias c6gn.16xlarge), el volumen de transmisión de paquetes por segundo puede alcanzar más de 10 millones. El ancho de banda de transmisión supera los 30 Gbps.

La latencia de un solo canal GET es inferior a 1 milisegundo:

30 canales GET:

La latencia de un único canal SET es inferior a 1 milisegundo:

30 canales SET:

comando memtier_benchmark para cada variante:

Latencia de un solo canal GET por debajo de 1 ms

30 canales GET

Latencia de un solo canal SET inferior a 1 milisegundo

30 canales SET

En esta prueba de comparación, probamos el cliente (usado para ejecutar memtier_benchmark) y el servidor (usado para ejecutar Redis y Dragonfly) utiliza el mismo tipo de máquina virtual, las especificaciones específicas son:

Enlace de referencia:

/article/AlF5NIhHdskayl0MTyQG