Optimizing metadata performance for web-scale applications

Enterrado en la parte inferior de la pila de software de la mayoría de las aplicaciones hay un motor de datos, un almacén de clave-valor integrado que clasifica e indexa los datos. Hasta ahora, los motores de datos, a veces llamados motores de almacenamiento, han recibido poca atención, haciendo su trabajo entre bastidores, debajo de la aplicación y por encima del almacenamiento.

Un motor de datos generalmente maneja las operaciones básicas de administración de almacenamiento, en particular para crear, leer, actualizar y eliminar datos (CRUD). Además, el motor de datos debe proporcionar de manera eficiente una interfaz para lecturas secuenciales de datos y actualizaciones atómicas de varias claves al mismo tiempo.

Las organizaciones aprovechan cada vez más los motores de datos para ejecutar diferentes actividades sobre la marcha, en datos en vivo, mientras están en tránsito. En este tipo de implementación, los motores de datos populares como RocksDB están desempeñando un papel cada vez más importante en la gestión de cargas de trabajo intensivas en metadatos y en la prevención de cuellos de botella en el acceso a los metadatos que pueden afectar el rendimiento de todo el sistema.

Si bien los volúmenes de metadatos aparentemente consumen una pequeña porción de los recursos en relación con los datos, el impacto del más mínimo cuello de botella en la experiencia del usuario final se vuelve incómodamente evidente, lo que subraya la necesidad de un rendimiento inferior al milisegundo. Este desafío es particularmente importante cuando se trata de cargas de trabajo modernas con uso intensivo de metadatos, como IoT y análisis avanzados.

Las estructuras de datos dentro de un motor de datos generalmente caen en una de dos categorías, árbol B o árbol LSM. Conocer el patrón de uso de la aplicación le sugerirá qué tipo de estructura de datos es óptima para el perfil de rendimiento que busca. A partir de ahí, puede determinar la mejor manera de optimizar el rendimiento de los metadatos cuando las aplicaciones crezcan a escala web.

Pros y contras del árbol B

Los árboles B están completamente ordenados por la clave dada por el usuario. Por lo tanto, los árboles B son adecuados para cargas de trabajo en las que hay muchas lecturas y búsquedas, pequeñas cantidades de escritura y los datos son lo suficientemente pequeños como para caber en la DRAM. Los árboles B son una buena opción para bases de datos pequeñas de propósito general.

Sin embargo, los árboles B tienen importantes problemas de rendimiento de escritura debido a varias razones. Estos incluyen una mayor sobrecarga de espacio requerida para lidiar con la fragmentación, la amplificación de escritura que se debe a la necesidad de clasificar los datos en cada escritura y la ejecución de escrituras simultáneas que requieren bloqueos, lo que afecta significativamente el rendimiento general y la escalabilidad del sistema.

Pros y contras del árbol LSM

Los árboles LSM están en el centro de muchas plataformas de datos y almacenamiento que necesitan un rendimiento intensivo de escritura. Estas incluyen aplicaciones que tienen muchas inserciones nuevas y actualizaciones de claves o registros de escritura, algo que ejerce presión sobre las transacciones de escritura tanto en la memoria como cuando la memoria o el caché se vacían en el disco.

Un LSM es una estructura parcialmente ordenada. Cada nivel del árbol LSM es una matriz ordenada de datos. El nivel más alto se mantiene en la memoria y generalmente se basa en estructuras similares a árboles B. Los otros niveles son conjuntos ordenados de datos que normalmente residen en un almacenamiento persistente más lento. Finalmente, un proceso fuera de línea, también conocido como compactación, toma datos de un nivel superior y los fusiona con un nivel inferior.

Las ventajas de LSM sobre B-tree se deben al hecho de que las escrituras se realizan completamente en la memoria y se usa un registro de transacciones (un registro de escritura anticipada o WAL) para proteger los datos mientras esperan ser vaciados de la memoria a persistentes. almacenamiento. La velocidad y la eficiencia aumentan porque LSM utiliza un proceso de escritura de solo agregar que permite escrituras secuenciales rápidas sin los desafíos de fragmentación a los que están sujetos los árboles B. Las inserciones y actualizaciones se pueden realizar mucho más rápido, mientras que el sistema de archivos se organiza y reorganiza continuamente con un proceso de compactación en segundo plano que reduce el tamaño de los archivos necesarios para almacenar datos en el disco.

Sin embargo, LSM tiene sus propias desventajas. Por ejemplo, el rendimiento de lectura puede ser deficiente si se accede a los datos en fragmentos pequeños y aleatorios. Esto se debe a que los datos están dispersos y encontrar los datos deseados rápidamente puede ser difícil si la configuración no está optimizada. Hay formas de mitigar esto con el uso de índices, filtros de floración y otros ajustes para tamaños de archivos, tamaños de bloques, uso de memoria y otras opciones ajustables, suponiendo que las organizaciones de desarrolladores tengan el conocimiento para manejar estas tareas de manera efectiva.

Ajuste de rendimiento para tiendas de valores clave

Los tres factores principales de rendimiento en un almacén de clave-valor son la amplificación de escritura, la amplificación de lectura y la amplificación de espacio. Cada uno tiene implicaciones significativas en las características eventuales de rendimiento, estabilidad y eficiencia de la aplicación. Tenga en cuenta que el ajuste del rendimiento para un almacén de valores clave es un desafío vivo que se transforma y evoluciona constantemente a medida que la utilización de la aplicación, la infraestructura y los requisitos cambian con el tiempo.

Amplificación de escritura

La amplificación de escritura se define como el número total de bytes escritos dentro de una operación de escritura lógica. A medida que los datos se mueven, copian y clasifican dentro de los niveles internos, se reescriben una y otra vez o se amplifican. La amplificación de escritura varía según el tamaño de los datos de origen, la cantidad de niveles, el tamaño de la tabla de memoria, la cantidad de sobrescrituras y otros factores.

Leer amplificación

Este es un factor definido por la cantidad de lecturas de disco que provoca una solicitud de lectura de aplicación. Si tiene una consulta de datos de 1K que no se encuentra en las filas almacenadas en memtable, la solicitud de lectura va a los archivos en almacenamiento persistente, lo que ayuda a reducir la amplificación de lectura. El tipo de consulta (por ejemplo, consulta de rango versus consulta de punto) y el tamaño de la solicitud de datos también afectarán la amplificación de lectura y el rendimiento general de lectura. El rendimiento de las lecturas también variará con el tiempo a medida que cambien los patrones de uso de la aplicación.

Amplificación del espacio

Esta es la proporción de la cantidad de almacenamiento o espacio de memoria consumido por los datos dividida por el tamaño real de los datos. Esto se verá afectado por el tipo y tamaño de los datos escritos y actualizados por la aplicación, dependiendo de si se usa compresión, el método de compactación y la frecuencia de compactación.

La amplificación del espacio se ve afectada por factores tales como tener una gran cantidad de datos obsoletos que aún no se han recolectado como basura, experimentar una gran cantidad de inserciones y actualizaciones, y la elección del algoritmo de compactación. Muchas otras opciones de ajuste pueden afectar la amplificación del espacio. Al mismo tiempo, los equipos pueden personalizar la forma en que se comportan la compresión y la compactación, o establecer la profundidad del nivel y el tamaño objetivo de cada nivel, y ajustar cuándo se produce la compactación para ayudar a optimizar la ubicación de los datos. Estos tres factores de amplificación también se ven afectados por la carga de trabajo y el tipo de datos, la infraestructura de almacenamiento y memoria, y el patrón de utilización de la aplicación. ‍

Ajuste multidimensional: optimización tanto de escrituras como de lecturas

En la mayoría de los casos, las estructuras de datos de almacenamiento clave-valor existentes se pueden ajustar para que sean lo suficientemente buenas para las velocidades de escritura y lectura de la aplicación, pero no pueden ofrecer un alto rendimiento para ambas operaciones. El problema puede volverse crítico cuando los conjuntos de datos aumentan. A medida que los volúmenes de metadatos continúan creciendo, pueden empequeñecer el tamaño de los datos en sí. En consecuencia, no pasa mucho tiempo antes de que las organizaciones lleguen a un punto en el que comiencen a negociar entre rendimiento, capacidad y costo.

Cuando surgen problemas de rendimiento, los equipos suelen empezar por volver a fragmentar los datos. La fragmentación es uno de esos males necesarios que cobra un peaje en el tiempo del desarrollador. A medida que se multiplica la cantidad de conjuntos de datos, los desarrolladores deben dedicar más tiempo a particionar los datos y distribuirlos entre fragmentos, en lugar de centrarse en escribir código.

Además de fragmentar, los equipos a menudo intentan ajustar el rendimiento de la base de datos. La buena noticia es que las tiendas clave-valor con todas las funciones, como RocksDB, ofrecen muchas perillas y botones para afinar, casi demasiados. La mala noticia es que el ajuste es un proceso iterativo y lento, y un arte fino en el que los desarrolladores expertos pueden tener dificultades.

Como se mencionó anteriormente, un ajuste importante es la amplificación de escritura. A medida que aumenta la cantidad de operaciones de escritura, aumenta el factor de amplificación de escritura (WAF) y disminuye el rendimiento de E/S, lo que genera un rendimiento degradado e impredecible. Y debido a que los motores de datos como RocksDB son la parte más profunda o “más baja” de la pila de software, cualquier bloqueo de E/S originado en esta capa puede filtrarse en la pila y causar grandes retrasos. En el mejor de los mundos, una aplicación tendría un factor de amplificación de escritura de n, donde n es lo más bajo posible. Un WAF común de 30 afectará drásticamente el rendimiento de la aplicación en comparación con un WAF ideal más cercano a 5.

Por supuesto, existen pocas aplicaciones en el mejor de los mundos, y la amplificación requiere delicadeza o flexibilidad para realizar ajustes iterativos. Una vez modificadas, estas instancias pueden experimentar problemas de rendimiento significativos adicionales si se modifican las cargas de trabajo o los sistemas subyacentes, lo que genera la necesidad de realizar más ajustes, y tal vez un ciclo interminable de ajustes, lo que consume más tiempo del desarrollador. Agregar recursos, si bien es una respuesta, tampoco es una solución a largo plazo.

Hacia motores de datos de última generación

Están surgiendo nuevos motores de datos en el mercado que superan algunas de estas deficiencias en cargas de trabajo intensivas en datos y de baja latencia que requieren una escalabilidad y un rendimiento significativos, como es común con los metadatos. En un artículo posterior, exploraremos la tecnología detrás de Speedb y su enfoque para ajustar los factores de amplificación anteriores.

A medida que se expande el uso de arquitecturas de microservicios de baja latencia, la conclusión más importante para los desarrolladores es que existen opciones para optimizar el rendimiento de los metadatos, ajustando o reemplazando el motor de datos para eliminar problemas anteriores de rendimiento y escala. Estas opciones no solo requieren una intervención menos directa del desarrollador, sino que también satisfacen mejor las demandas de las aplicaciones modernas.

Hilik Yochai es director científico y cofundador de Speedb, la compañía detrás del motor de datos Speedb, un reemplazo directo de RocksDB, y Hive, la comunidad de código abierto de Speedb donde los desarrolladores pueden interactuar, mejorar y compartir conocimientos y mejores prácticas en Speedb y RocksDB. La tecnología de Speedb ayuda a los desarrolladores a desarrollar sus operaciones de datos a hiperescala con escala y rendimiento ilimitados sin comprometer la funcionalidad, mientras se esfuerzan constantemente por mejorar la usabilidad y la facilidad de uso.

—

New Tech Forum ofrece un lugar para explorar y discutir la tecnología empresarial emergente en una profundidad y amplitud sin precedentes. La selección es subjetiva, basada en nuestra elección de las tecnologías que creemos que son importantes y de mayor interés para los lectores de InfoWorld. InfoWorld no acepta garantías de marketing para la publicación y se reserva el derecho de editar todo el contenido aportado. Envíe todas las consultas a newtechforum@infoworld.com.