An in-depth look at database and cache internals, and the tradeoffs in each. ScyllaDB quiere reconocer públicamente a dormando (Memcachediner) y a Danny Kopping por sus contribuciones a este proyecto, así como agradecerles su apoyo y paciencia. durmiendo Danny Kopping Los ingenieros detrás de ScyllaDB – la base de datos para el rendimiento previsible a escala – se unieron con Memcached mantenedor dormando para comparar ambas tecnologías frente a frente, de una manera colaborativa y neutral al vendedor. Los resultados revelan que: Tanto Memcached como ScyllaDB maximizaron los discos y el ancho de banda de la red, mientras que estaban estresados en condiciones similares, manteniendo un rendimiento similar en general. Mientras que ScyllaDB requirió cambios en la modelización de datos para saturar completamente el rendimiento de la red, Memcached requirió hilos de IO adicionales para saturar el I/O del disco. Aunque ScyllaDB mostró mejores latencias en comparación con las solicitudes de tuberías Memcached al disco, las latencias Memcached fueron mejores para las solicitudes individuales. Este documento explica nuestra motivación para estas pruebas, proporciona un resumen de los escenarios y resultados probados, y luego presenta recomendaciones para cualquiera que pueda decidir entre ScyllaDB y Memcached. También hay con una mirada más extensa a las pruebas y resultados y enlaces a las configuraciones específicas que puede utilizar para realizar las pruebas usted mismo. un Gitbook detallado para este proyecto, Bonus: dormando y yo discutimos recientemente este proyecto en P99 CONF, una conferencia altamente técnica sobre rendimiento y ingeniería de baja latencia. Observa la demanda Bonus: dormando y yo discutimos recientemente este proyecto en P99 CONF, una conferencia altamente técnica sobre rendimiento y ingeniería de baja latencia. Watch on demand Observa la demanda ¿Por qué hemos hecho esto? En primer lugar, ScyllaDB ha invertido mucho tiempo y recursos de ingeniería optimizando nuestra base de datos para ofrecer latencias bajas predecibles para aplicaciones intensivas de datos en tiempo real. La arquitectura no compartida, y (abandonando completamente la caché de la página de Linux) son algunos ejemplos notables de tales optimizaciones. Conexión Shard-per-Core Calendario de usuario de I/O Implementación de cache interno En segundo lugar: el rendimiento se converge con el tiempo. Las cachés en memoria han sido (durante mucho tiempo) consideradas como uno de los componentes de infraestructura más rápidos. Sin embargo, han pasado algunos años desde que las soluciones de caché comenzaron a mirar al ámbito de los discos flash. If an in-memory cache can rely on flash storage, then why can’t a persistent database also work as a cache? En primer lugar, hablamos de lo anterior y recientemente exploró cómo los equipos específicos han tenido éxito . 7 razones para no colocar una caché delante de tu base de datos Sustituye su caché por ScyllaDB Cuarto: En el P99 CONF del año pasado, Danny Kopping nos dio un discurso esclarecedor, , donde explicó cómo Memcached Extstore ayudó a Grafana Labs a escalar su huella de caché 42x mientras bajaba los costos. Esconderme si puedes Y finalmente, a pesar de las críticas (validas) que reciben los indicadores de rendimiento, siguen desempeñando un papel importante en impulsar la innovación. Ahora pasemos a la comparación. Instalación instancias Las pruebas se llevaron a cabo utilizando los siguientes tipos de instancias de AWS: Cargador: c7i.16xlarge (64 vCPUs, 128GB de RAM) Memcached: i4i.4xlarge (16 vCPUs, 128GB de RAM, 3.75TB NVMe) ScyllaDB: i4i.4xlarge (16 vCPUs, 128GB de RAM, 3.75TB de NVMe) Todas las instancias pueden 25Gbps de ancho de banda de la red. Tenga en cuenta que especialmente durante las pruebas para maximizar la capacidad prometida de la red, notamos . arriba de reducción del ancho de banda hasta la capacidad de base de las instancias Optimizaciones y configuraciones Para superar los obstáculos potenciales, se aplicaron las siguientes optimizaciones y configuraciones: AWS: Todas las instancias usaron una estrategia de colocación de clusters, siguiendo los documentos de AWS: “Esta estrategia permite que las cargas de trabajo logren el rendimiento de red de baja latencia necesario para la comunicación de nodo a nodo estrechamente unida que es típica de las aplicaciones de computación de alto rendimiento (HPC).” Memcached: Versión 1.6.25, compilada con Extstore habilitado. Salvo donde se denote, ejecuta con 14 cables, apilados a CPUs específicos. Los 2 vCPUs restantes se asignaron a la CPU 0 (core & HT sibling) para manejar IRQs de red, según lo especificado por el modo sq_split en seastar perftune.py. Las operaciones CAS fueron deshabilitadas para ahorrar espacio en sobrecarga por elemento. Los argumentos de la línea de comandos completos fueron:taskset -c 1-7,9-15 /usr/local/memcached/bin/memcached -v -A -r -m 114100 -c 4096 -lock-memory -threads 14 - scylla -C ScyllaDB: Configuración por defecto de ScyllaDB Enterprise 2024.1.2 AMI (ami-id: ami-018335b47ba6bdf9a) en un i4i.4xlarge. estrés Para los cargadores Memcached, usamos , parte de la suite de pruebas oficial de memcached. Los perfiles de estrés aplicables están en la El repositorio de GitHub. mcshredder Fey-Mendes y Shredders Para ScyllaDB, usamos , como se envió con ScyllaDB, y especificó cargas de trabajo comparables como las utilizadas para Memcached. Casas de estrés Pruebas y resultados La siguiente es un resumen de las pruebas que hemos realizado y sus resultados.Si desea una descripción y análisis más detallados, vaya a . La extensión de este proyecto Eficiencia de la memoria RAM Cuanto más elementos puedas encajar en la RAM, mejor es tu posibilidad de obtener hits de caché.Más hits de caché resultan en un acceso significativamente más rápido que ir al disco. Este proyecto comenzó midiendo cuántos elementos podíamos almacenar en cada almacenamiento de datos. A lo largo de nuestras pruebas, la clave estaba entre 4 y 12 bytes (key0 .. keyN) para Memcached, y 12 bytes para ScyllaDB. Memorias Memcached almacenó aproximadamente 101M de artículos hasta que comenzó la expulsión. Es eficiente en la memoria. De la memoria asignada 114G de Memcached, esto es aproximadamente 101G de valores, sin considerar el tamaño de la clave y otras banderas: ScyllaDB ScyllaDB almacenó entre 60 a 61 millones de artículos antes de que comenzaran las expulsiones. Esto no es sorprendente, dado que su protocolo requiere más datos para almacenarse como parte de una escritura (como el timestamp de escritura desde la época, la vida de la fila, etc.). ScyllaDB también persiste datos en el disco a medida que se va, lo que significa que los filtros de Bloom (y, opcionalmente, los índices) deben almacenarse en la memoria para búsquedas posteriores de disco. Takeaways Memcached almacena aproximadamente un 65% más de elementos en memoria que ScyllaDB. Las filas de ScyllaDB tienen una superioridad por elemento para soportar una orientación de columna amplia. En ScyllaDB, los filtros Bloom, el cache de índice y otros componentes también se almacenan en la memoria para soportar búsquedas de disco eficientes, lo que contribuye a otra capa de sobrecarga. Carga de trabajo solo de lectura in-memory El La carga de trabajo (aunque poco realista) para una caché es aquella en la que todos los datos se encajan en la memoria RAM, por lo que las lecturas no requieren acceso al disco y no se producen evicciones o omisiones.Tanto ScyllaDB como Memcached emplean la lógica LRU (Least Recently Used) para liberar la memoria: Cuando el sistema se ejecuta bajo presión, los elementos se expulsan de la cola de la LRU; estos son típicamente los elementos menos activos. El ideal Tomar evicciones y omisiones de caché de la imagen ayuda a medir y establecer una línea de base de rendimiento para ambos almacenes de datos. Se centra en lo que más importa para estos tipos de cargas de trabajo: rendimiento de lectura y latencia de solicitud. En esta prueba, primero calentamos ambas tiendas con los mismos tamaños de carga útil utilizados durante la prueba anterior. Memcached Memcached logró un impresionante 3 Millones de Gets por segundo, maximizando completamente el ancho de banda de AWS NIC (25 Gbps)! Memcached mantuvo un ritmo constante de 3M rps, maximizando completamente el rendimiento de NIC El paredón muestran que p99.999 respuestas completadas por debajo de 1ms: Resultados estado: cmd_get : Opciones totales: 5503513496 Tasa: 3060908/s === horas mg === horas 1-10o 0 0.000% 10-99us 343504394 6.238% 100-999us 5163057634 93.762% 1-2ms 11500 0.00021% ScyllaDB Para leer más líneas en ScyllaDB, necesitábamos diseñar un mejor modelo de datos para las solicitudes del cliente debido a las características del protocolo (en particular, sin pipelining).Con una clave de agrupamiento, podíamos maximizar completamente la caché de ScyllaDB, lo que resultó en una mejora significativa en el número de líneas cacheadas. Ingerimos 5M particiones, cada una con 16 claves de agrupamiento, para un total de 80M líneas cacheadas. Como resultado, el número de registros dentro de la caché mejoró significativamente en comparación con los números de valor clave mostrados anteriormente. Como dormando señaló correctamente (gracias!), esta configuración es significativamente diferente a la configuración anterior de Memcached. Mientras que la carga de trabajo de Memcached siempre logra un par de valores de clave individual, una única solicitud en ScyllaDB resulta en que se devuelven varias filas. Explicamos las razones de estos cambios Allí, cubrimos características del protocolo CQL (como la sobrecarga por elemento [en comparación con memcached] y ningún soporte para el pipelining) que hacen que las particiones amplias sean más eficientes en ScyllaDB que las capturas de clave única. En la escritura detallada Con estos ajustes, nuestros cargadores realizaron un total de 187K de lecturas por segundo durante 30 minutos. Similar a memcached, ScyllaDB también maximizó el rendimiento NIC. Se sirvió aproximadamente 3M filas por segundo únicamente a partir de datos en memoria: ScyllaDB expone información de latencia del lado del servidor, que es útil para analizar la latencia sin la red. Durante la prueba, la latencia p99 del lado del servidor de ScyllaDB permaneció dentro de los límites de 1ms: Los percentiles del lado del cliente son, no es de extrañar, más altos que la latencia del lado del servidor con un P99 de lectura de 0,9ms. Takeaways Tanto Memcached como ScyllaDB saturaron completamente la red; para evitar la saturación de los paquetes de red máximos por segundo, Memcached se basó en el pipelining de solicitudes, mientras que ScyllaDB se cambió a una orientación de columna amplia. La caché de ScyllaDB mostró ganancias considerables siguiendo un esquema de columna amplia, capaz de almacenar más elementos en comparación con la anterior orientación simple de valor clave. A nivel de protocolo, el protocolo de Memcached es más simple y ligero, mientras que el CQL de ScyllaDB ofrece características más ricas, pero puede ser más pesado. Añadir discos a la imagen Medir el rendimiento del almacenamiento flash introduce su propio conjunto de desafíos, lo que hace que sea casi imposible caracterizar completamente una carga de trabajo dada de manera realista. Para las pruebas relacionadas con los discos, decidimos medir la situación más pesimista: Compare ambas soluciones que sirven datos (principalmente) desde el almacenamiento de bloques, sabiendo que: La probabilidad de que las cargas de trabajo realistas hagan esto está cerca de cero Los usuarios deben esperar números entre la carga de trabajo de caché optimista anterior y la carga de trabajo de disco pesimista en la práctica Memcached Extstore El En un nivel alto, permite a memcached mantener su tabla hash y claves en la memoria, pero almacenar valores en el almacenamiento externo. Página de Wiki Durante nuestras pruebas, poblamos memcached con artículos de 1.25B con un tamaño de valor de 1KB y un tamaño de teclado de hasta 14 bytes: Con Extstore, almacenamos alrededor de 11X el número de elementos en comparación con la carga de trabajo anterior en la memoria hasta que las evicciones comenzaron a entrar (como se muestra en el panel de la mano derecha en la imagen anterior).Aunque 11X es un número ya impresionante, el total de datos almacenados en flash fue sólo 1,25TB del total de 3.5TB proporcionados por la instancia de AWS. Read-Only Performance Para las pruebas de rendimiento reales, destacamos Extstore contra los tamaños de artículo de 1KB y 8KB. La tabla siguiente resume los resultados: Test Type Items per GET Payload Size IO Threads GET Rate P99 perfrun_metaget_pipe 16 1KB 32 188K/s 4~5 ms perfrun_metaget 1 1KB 32 182K/s <1ms perfrun_metaget_pipe 16 1KB 64 261K/s 5~6 ms perfrun_metaget 1 1KB 64 256K/s 1~2ms perfrun_metaget_pipe 16 8KB 16 92K/s 5~6 ms perfrun_metaget 1 8KB 16 90K/s <1ms perfrun_metaget_pipe 16 8KB 32 110K/s 3~4 ms perfrun_metaget 1 8KB 32 105K/s <1ms perfrun_metaget_pipe 16 1 kB 32 188 k/s Entre 4 y 5 ms Página principal_metaget 1 1 kB 32 182 k/s < 1 ms perfrun_metaget_pipe 16 1 kB 64 261 k/s 5 a 6 ms Página principal_metaget 1 1 kB 64 256 k/s 1 - 2 ms perfrun_metaget_pipe 16 8 kB 16 92 k/s 5 a 6 ms Página principal_metaget 1 8 kB 16 90 k/s < 1 ms perfrun_metaget_pipe 16 8 kB 32 110 k/s De 3 a 4 ms Página principal_metaget 1 8 kB 32 105 k/s < 1 ms ScyllaDB Populamos ScyllaDB con el mismo número de elementos que se utilizó para memcached. Aunque ScyllaDB mostró tasas de GET más altas que memcached, lo hizo bajo latencias de cola ligeramente más altas en comparación con las cargas de trabajo no de tuberías de memcached. Esto se resume a continuación: Test Type Items per GET Payload Size GET Rate Server-side P99 Client-side P99 1KB Read 1 1KB 268.8K/s 2ms 2.4ms 8KB Read 1 8KB 156.8K/s 1.54ms 1.9ms 1 kB de lectura 1 1 kB 268.8 K/s 2 ms 2.4 ms 8 kB de lectura 1 8 kB 156.8 K/s 1.45 ms 1.9 ms Takeaways Extstore requirió un ajuste considerable a sus configuraciones para saturar completamente el almacenamiento de flash I/O. Debido a la arquitectura Memcached, las cargas de pago más pequeñas no pueden aprovechar plenamente el espacio disponible en el disco, lo que proporciona ganancias menores en comparación con ScyllaDB. Las tasas de ScyllaDB eran en general más altas que Memcached en una orientación de valor clave, especialmente bajo tamaños de carga útil más altos. Las latencias eran mejores que las solicitudes de tuberías, pero ligeramente más altas que los GET individuales en Memcached. Sobreescribir la carga de trabajo Siguiendo nuestros resultados anteriores de Disco, luego comparamos ambas soluciones en una carga de trabajo de lectura en su mayoría dirigida al mismo rendimiento (250K ops/sec). , con un 10% de sobrescripciones aleatorias. Se considera un "escenario de peor situación". Test “básico” para Extstore Memcached Memcached logró una tasa de un poco por debajo de 249K durante la prueba.Aunque las tasas de escritura permanecieron estables durante la duración de la prueba, observamos que las lecturas fluctuaron ligeramente : A lo largo de la carrera También hemos observado ligeramente las métricas a pesar de las reducidas proporciones de lectura, pero las latencias siguen siendo bajas. Estos resultados se resumen a continuación: extstore_yo_queue Operation IO Threads Rate P99 Latency cmd_get 64 224K/s 1~2 ms cmd_set 64 24.8K/s <1ms CMD_GET 64 224 k/s 1 a 2 ms cmd_sitio 64 24,8 K/s < 1 ms ScyllaDB La prueba de ScyllaDB se ejecutó utilizando 2 cargadores, cada uno con la mitad de la tasa de meta. Aunque ScyllaDB logró un rendimiento ligeramente mayor (259.5K), las latencias de escritura se mantuvieron bajas a lo largo de la carrera y las latencias de lectura fueron más altas (similar a las de memcached): La siguiente tabla resume los resultados de ejecución del lado del cliente en los dos cargadores: Loader Rate Write P99 Read P99 loader1 124.9K/s 1.4ms 2.6 ms loader2 124.6K/s 1.3ms 2.6 ms Cargador1 124.9 K/s 1.4 ms 6.2 ms cargador2 124.6 K/s 1.3 ms 6.2 ms Takeaways Tanto Memcached como ScyllaDB tenían tasas de escritura estables, con lecturas que fluctuaban ligeramente a lo largo de la carrera. ScyllaDB escribe aún cuenta para el comitlog overhead, que se sienta en el camino de escritura caliente Las latencias del lado del servidor de ScyllaDB fueron similares a las observadas en los resultados de Memcached, aunque las latencias del lado del cliente fueron ligeramente mayores. Lee un análisis más detallado en el Gitbook para este proyecto envuelve Tanto memcached como ScyllaDB lograron maximizar la utilización del hardware subyacente en todas las pruebas y mantener las latencias previsiblemente bajas. Si su carga de trabajo existente puede acomodar un modelo de valor clave simple y se beneficia de la pipelining, entonces memcached debería ser más adecuado a sus necesidades. Otra razón para adherirse a Memcached: facilita el tráfico mucho más allá de lo que un NIC puede soportar. , dormando mencionó que podría escalarlo por más de 55 millones de lectops/sec para un servidor considerablemente más grande. Dado que, usted podría hacer uso de tipos de instancia más pequeños y / o más baratos para mantener una carga de trabajo similar, siempre que la memoria disponible y la huella de disco sea suficiente para sus necesidades de carga de trabajo. Hacker Noticias Thread Un ángulo diferente a considerar es el tamaño del conjunto de datos. Aunque Extstore proporciona grandes ahorros de costos al permitir almacenar artículos más allá de la RAM, hay un límite a cuántas claves pueden caber por GB de memoria. Las cargas de trabajo con artículos muy pequeños deben observar ganancias menores en comparación con aquellos con artículos más grandes. Si es así, ejecutar ScyllaDB como un cache distribuido replicado le proporciona mayor resiliencia y operaciones no-stop, con la ventaja de ser (y como ) que la replicación reduce a la mitad su tamaño de caché efectivo. Desafortunadamente, Extstore no soporta reinicios calientes y, por lo tanto, el fracaso o el mantenimiento de un nodo único es propenso a elevar su ratio de falta de caché. Si esto es aceptable o no depende de la semántica de su aplicación: Si una falta de caché corresponde a una vuelta a la base de datos, entonces la latencia de fin a fin será momentáneamente mayor. Encuentran correctamente los estados En cuanto al hashing consistente, los clientes memcached son responsables de distribuir claves a través de sus servidores distribuidos. Esto puede introducir algunos hiccups, ya que diferentes configuraciones de clientes causarán que las claves se asignen de manera diferente, y algunas implementaciones pueden no ser compatibles entre sí. ScyllaDB adopta un enfoque diferente: el hashing consistente se realiza a nivel de servidor y se propaga a los clientes cuando se establece la conexión por primera vez. Memcached’s ConfiguringClient wiki Así que ¿quién ganó (o quién perdió)? Bueno... Esto no tiene que ser una competencia, ni una lista exhaustiva que describa cada consideración individual para cada solución.Tanto ScyllaDB como memcached usan diferentes enfoques para utilizar de manera eficiente la infraestructura subyacente. Cuando se configure correctamente, ambos tienen el potencial de proporcionar grandes ahorros de costes. Estábamos encantados de ver que ScyllaDB coincide con los números del Memcached reconocido por la industria. Por supuesto, no teníamos expectativas de que nuestra base de datos sea “más rápida”.
