Let’s look at the performance-related complexities that teams commonly face with write-heavy workloads and discuss your options for tackling them Las cargas de trabajo de bases de datos pesadas en escritura presentan un conjunto distinto de desafíos que las cargas de trabajo pesadas en lectura. Escalar escritos puede ser costoso, especialmente si usted paga por operación y los escritos son 5X más costosos que las lecturas. El bloqueo puede añadir retrasos y reducir el rendimiento Los obstáculos de I/O pueden conducir a la amplificación de escritura y complicar la recuperación de accidentes Backpressure de la base de datos puede destrozar la carga de entrada Mientras que el coste es importante, en muchos casos, no es un tema que queremos cubrir aquí, en cambio, centrémonos en las complejidades relacionadas con el rendimiento que los equipos se enfrentan comúnmente y discutiremos sus opciones para abordarlas. ¿Qué se entiende por "una carga de trabajo pesada de escritura en tiempo real"? En primer lugar, vamos a aclarar lo que entendemos por una carga de trabajo "en tiempo real de escritura pesada". estamos hablando de cargas de trabajo que: Ingerir una gran cantidad de datos (por ejemplo, más de 50K OPS) Escribe más que lee Están vinculados por los SLA de latencia estricta (por ejemplo, la latencia de milisegundos de un único dígito P99). En la naturaleza, ocurren en todo, desde los juegos en línea hasta las bolsas de valores en tiempo real. Las cargas de trabajo de Internet de las Cosas (IoT) tienden a involucrar pequeñas pero frecuentes copias de datos de series temporales. Aquí, la tasa de ingestión se determina principalmente por el número de puntos finales que recopilan datos.Piense en sensores inteligentes o equipos de monitoreo industrial que envían constantemente flujos de datos para ser procesados y almacenados. Los sistemas de logging y monitorización también tratan con la ingestión de datos frecuente, pero no tienen una tasa de ingestión fija. Las plataformas de juegos en línea necesitan procesar las interacciones de los usuarios en tiempo real, incluyendo cambios en el estado del juego, acciones de los jugadores y mensajes.La carga de trabajo tiende a ser aguda, con aumentos repentinos en la actividad. Las cargas de trabajo de comercio electrónico y de venta al por menor suelen ser pesadas y a menudo involucran el procesamiento de lotes.Estos sistemas deben mantener niveles de inventario precisos, procesar reseñas de clientes, rastrear el estado de los pedidos y gestionar las operaciones del carrito de compras, que normalmente requieren la lectura de los datos existentes antes de realizar actualizaciones. Ad Tech y los sistemas de licitación en tiempo real requieren decisiones divididas en segundos. Estos sistemas manejan el procesamiento complejo de las ofertas, incluyendo el seguimiento de las impresiones y los resultados de las subastas, mientras monitorean simultáneamente las interacciones de los usuarios como los clics y las conversiones. Los sistemas de Bolsa de Valores en tiempo real deben soportar operaciones de comercio de alta frecuencia, actualizaciones constantes de precios de acciones y procesos complejos de ajuste de pedidos, manteniendo la coherencia absoluta de los datos y la latencia mínima. A continuación, echemos un vistazo a las principales consideraciones de arquitectura y configuración que afectan al rendimiento de la escritura. Arquitectura de motores de almacenamiento La elección de la arquitectura del motor de almacenamiento afecta fundamentalmente el rendimiento de escritura en las bases de datos. Existen dos enfoques principales: árboles LSM y árboles B. Las bases de datos conocidas por manejar escritos de manera eficiente, como ScyllaDB, Apache Cassandra, HBase y Google BigTable, utilizan Log-Structured Merge Trees (LSM). Esta arquitectura es ideal para manejar grandes volúmenes de escritos. Puesto que los escritos se adhieren inmediatamente a la memoria, esto permite un almacenamiento inicial muy rápido. Una vez que la “memtable” en la memoria se llena, los escritos recientes se enjuagan al disco en orden ordenado. Por ejemplo, aquí está cómo se ve el camino de escritura de ScyllaDB: Con las estructuras de árboles B, cada operación de escritura requiere localizar y modificar un nodo en el árbol, y esto implica tanto I/O secuencial como aleatorio.A medida que el conjunto de datos crece, el árbol puede requerir nodos adicionales y reequilibrio, lo que lleva a más I/O de disco, lo que puede afectar el rendimiento. Tamaño Payload El tamaño de la carga útil también impacta en el rendimiento. Con pequeñas cargas útiles, el rendimiento es bueno, pero el procesamiento de la CPU es la barrera principal. A medida que el tamaño de la carga útil aumenta, se obtiene un rendimiento general más bajo y la utilización del disco también aumenta. En última instancia, una pequeña escritura suele encajar en todos los buffers y todo se puede procesar bastante rápidamente. Por eso es fácil obtener un alto rendimiento. Para cargas de pago más grandes, necesita asignar buffers más grandes o buffers múltiples. Cuanto más cargas de pago, más recursos (red y disco) se requieren para servir esas cargas de crédito. Compresiones La utilización del disco es algo que se debe observar de cerca con una carga de trabajo pesada de escritura.Aunque el almacenamiento se está volviendo cada vez más barato, todavía no es gratis. La compresión puede ayudar a mantener las cosas en control, así que elija su estrategia de compresión sabiamente. velocidades de compresión más rápidas son importantes para las cargas de trabajo pesadas de escritura, pero también considere sus recursos de CPU y memoria disponibles. Asegúrese de mirar el La compresión básicamente divide sus datos en bloques más pequeños (o pedazos) y luego comprime cada bloque por separado.Al ajustar este ajuste, se da cuenta de que los pedazos más grandes son mejores para leer mientras que los más pequeños son mejores para escribir, y tenga en cuenta su tamaño de carga útil. Parámetros de tamaño de compresor Compasión Para bases de datos basadas en LSM, la estrategia de compresión que elija también influye en el rendimiento de escritura. Compactación implica fusionar múltiples SSTables en menos archivos más organizados, para optimizar el rendimiento de lectura, recuperar espacio en el disco, reducir la fragmentación de datos y mantener la eficiencia general del sistema. Al seleccionar estrategias de compactación, puede apuntarse a la amplificación de baja lectura, lo que hace que las lecturas sean lo más eficientes posible. O, puede apuntarse a la amplificación de baja escritura evitando que la compactación sea demasiado agresiva. O, puede priorizar la amplificación de bajo espacio y tener los datos de purificación de compactación lo más eficientemente posible. (y Cassandra ofrece similares): Varias estrategias de compactación Estrategia de compactación a escala de tamaño (STCS): Se activa cuando el sistema tiene suficientes (cuatro por defecto) SSTables de tamaño similar. Estrategia de compactación nivelada (LCS): El sistema utiliza pequeñas SSTables de tamaño fijo (por defecto 160 MB) distribuidas en diferentes niveles. Estrategia de compactación incremental (ICS): comparte los mismos factores de amplificación de lectura y escritura que STCS, pero fija su problema de amplificación temporal de espacio 2x rompiendo enormes estables en ejes SSTable, que se componen de un conjunto ordenado de SSTables más pequeños (1 GB por defecto), no superpuestos. Estrategia de compactación de ventanas de tiempo (TWCS): Diseñado para datos de series de tiempo. Para las cargas de trabajo de escritura pesada, advertimos a los usuarios para evitar la compactación nivelada a cualquier costo.Esta estrategia está diseñada para casos de uso de lectura pesada.Usarlo puede resultar en una lamentable amplificación de escritura 40x. Batallón En bases de datos como ScyllaDB y Cassandra, el batching puede ser en realidad un poco una trampa, especialmente para cargas de trabajo pesadas de escritura. Si estás acostumbrado a bases de datos relacionales, el batching puede parecer una buena opción para manejar un gran volumen de escritos. Pero en realidad puede ralentizar las cosas si no se hace cuidadosamente. Principalmente, esto es porque los batches grandes o no estructurados terminan creando mucha coordinación y sobrecarga de red entre los nodos. Sin embargo, eso no es realmente lo que quieres en una base de datos distribuida como ScyllaDB. Aquí está cómo pensar en el batch cuando se trata de escritos pesados: Batch by the Partition Key: agrupa tus escritos por la clave de partición para que el batch vaya a un nodo coordinador que también posee los datos. De esta manera, el coordinador no tiene que llegar a otros nodos para obtener datos adicionales. Mantenga los lotes pequeños y dirigidos: Dividir los lotes grandes en los más pequeños por partición mantiene las cosas eficientes. Evita la sobrecarga de la red y permite que cada nodo trabaje solo con los datos que posee. Manténgase en los lotes desconectados: Considerando que sigue los puntos anteriores, es mejor usar los lotes desconectados. los lotes desconectados añaden comprobaciones de consistencia adicionales, lo que puede realmente ralentizar la escritura. Por lo tanto, si se encuentra en una situación difícil de escribir, estructure sus lotes cuidadosamente para evitar los retrasos que pueden introducir los lotes grandes de nodos cruzados. envuelve Hemos ofrecido un par de advertencias, pero no te preocupes.Fue fácil compilar una lista de lecciones aprendidas porque tantos equipos están trabajando con éxito con cargas de trabajo pesadas de escritura en tiempo real.Ahora conoces muchos de sus secretos, sin tener que experimentar sus errores. Si desea aprender más, aquí están algunas perspectivas de primera mano de equipos que abordaron retos bastante interesantes: Zillow: Consumo de registros de múltiples productores de datos, lo que resultó en escritos fuera de orden que podrían resultar en actualizaciones incorrectas Tractian: Preparándose para un crecimiento de 10x en los datos de alta frecuencia de los dispositivos de IoT Fanáticos: Operaciones de escritura pesada como el manejo de pedidos, carros de compras y actualizaciones de productos para este minorista deportivo en línea Zillón Tráfico Fanáticos También, vea el siguiente vídeo, donde vamos a profundizar aún más en estos desafíos de escritura pesada y también te paseamos por lo que estas cargas de trabajo parecen en ScyllaDB.
