MetaDB adapta las bases de datos a los metadatos de sistemas de archivos
MetaDB: Putting File-System Structure Back into Distributed Databases · arXiv:2610.32247
En palabras sencillas
Los sistemas de archivos organizan los archivos y las carpetas en directorios. Una base de datos de propósito general puede repartir entre varias máquinas los registros relacionados con un directorio, hacer que muchos cambios compitan por actualizar el mismo registro padre o ralentizar la lista de archivos después de grandes tandas de eliminaciones.
MetaDB es una base de datos distribuida diseñada en torno a esos patrones. Mantiene juntos los datos de cada directorio y procesa algunas actualizaciones de forma asíncrona, es decir, fuera de la transacción principal.
En una prueba de creación simultánea de carpetas dentro de un mismo directorio, ese método alcanzó 10,7 veces el rendimiento de las transacciones basadas en bloqueos, en las condiciones probadas.
La investigación
Los sistemas de archivos crean y eliminan elementos dentro de directorios, pero una base de datos de propósito general puede dispersar los registros relacionados y exigir coordinación estricta para actualizaciones que podrían procesarse más tarde.
¿Puede una base de datos diseñada para estos patrones gestionar la contención en los directorios y las búsquedas con muchas eliminaciones de forma más eficiente?
MetaDB adapta la ubicación de los datos y la gestión de actualizaciones a la estructura de directorios y las necesidades de los metadatos, y prueba el diseño bajo cargas con contención, eliminaciones y uso en producción.
En una prueba con un clúster de producción, los autores usaron mdtest para ejecutar cinco operaciones de metadatos en MetaDB y en una base de datos de propósito general, en un clúster con 10 nodos de backend. Con 20 clientes, 50 hilos por cliente y 2.000 solicitudes por cliente, MetaDB alcanzó entre 2,2 y 4,1 veces el rendimiento de GP-DB en las cinco operaciones. Esto muestra un rendimiento mayor en esa prueba.
El resultado respalda la idea de adaptar el diseño de las bases de datos a las cargas de metadatos. Sin embargo, las observaciones de latencia en producción, realizadas por separado, no aíslan el efecto de la base de datos porque los clústeres diferían sustancialmente en escala.
Las observaciones de latencia en producción proceden de dos clústeres de distinto tamaño: GP-DB tenía 4 nodos de backend que gestionaban 1.000 millones de archivos y directorios, mientras que MetaDB tenía 50 nodos que gestionaban 50.000 millones.
Los autores indican que estas observaciones no constituyen una comparación estricta del rendimiento.
Qué muestran las pruebas
- Una base de datos para metadatos
MetaDB es una base de datos distribuida y consciente de los metadatos que Baidu usa como capa compartida de metadatos para sus sistemas de almacenamiento.
El artículo pregunta cómo gestionar los metadatos de sistemas de archivos cuando la estructura de directorios, las necesidades de consistencia de las actualizaciones y los patrones de eliminación difieren de los supuestos de las bases de datos de propósito general.
- Las actualizaciones de directorio compiten
Una prueba ilustra el problema de contención: en el sistema anterior, el rendimiento de creación cayó de aproximadamente 60.000 consultas por segundo sin contención a unas 6.000 cuando todas las solicitudes se dirigían a un solo directorio.
Las solicitudes competían entonces por actualizar el mismo registro del directorio padre, lo que motivó probar una forma de procesar esas actualizaciones sin bloquear cada una en primer plano.
- La agrupación reduce la contención
Para solicitudes concurrentes de mkdir bajo el mismo directorio, los autores compararon las transacciones basadas en bloqueos con la agrupación asíncrona. Cada cliente enviaba cuatro solicitudes simultáneas mientras aumentaba el número de clientes.
En este experimento, la agrupación alcanzó 10,7 veces el rendimiento de la ejecución basada en bloqueos, una evidencia a favor de este enfoque para el patrón de contención probado.
- Resultados de almacenamiento y producción
Una prueba aparte de eliminaciones comparó cuatro configuraciones de almacenamiento durante una eliminación masiva, con una operación de listado de carpeta simultánea. La configuración que combinó MVCC en memoria con compactación consciente de la localidad tuvo una latencia máxima de listado de 0,7 segundos, inferior y más estable que la de las otras configuraciones probadas.
En otra prueba con un clúster de producción también se observó un rendimiento mayor que con GP-DB en cinco operaciones de metadatos, dentro del alcance de esa prueba.
Detalles
- Autores del paper original
- Zebin Ren, Biao Cao, Kang Chen, Zhihui Yin, Qiushi Chen
- Enviado a arXiv
- Licencia
- CC BY 4.0