saltar al contenido

Vacío de base de datos

Una nueva era de dispositivos de almacenamiento masivo

Una de las principales razones para la aspiración de bases de datos es el almacenamiento, no solo por la capacidad, sino también para extender la vida útil de los dispositivos. Sugerencia: si ya conoce la diferencia entre los discos duros y las tecnologías de bases de datos, vaya a la última parte para ver cómo logramos nuestro éxito con nuestra tecnología de aspiración.

Las unidades de disco duro (HDD) han dominado el mercado durante muchos años. Recientemente ha surgido una nueva tecnología con unidades de estado sólido (SSD). Ambas tecnologías han experimentado un tremendo desarrollo con mejoras en velocidad, confiabilidad, capacidad y precio. A medida que los SSD se vuelven más baratos, han reemplazado a los HDD en muchas aplicaciones.

La mayoría de los desarrolladores comprenden bien cómo funcionan los HDD a nivel conceptual, pero existen muchos conceptos erróneos en el caso de los SSD. Por lo tanto, daremos una breve introducción a ambas tecnologías para preparar el escenario para la siguiente discusión.

Mayor vida útil del hardware

Unidades de disco duro (HDD)

Los discos duros almacenan datos en platos magnéticos giratorios mediante cabezales de lectura / escritura montados en brazos robóticos. Debido al uso de partes móviles, las lecturas y escrituras en HDD producen una alta latencia en comparación con los circuitos integrados (IC). Dependiendo del modelo de HDD real, es posible que los datos no se escriban inmediatamente, sino que se almacenen en el controlador para escribirlos más tarde. Este enfoque mejorará el rendimiento de escritura a costa de la durabilidad. Para minimizar el impacto en la durabilidad, los discos duros a menudo están equipados con un condensador grande o una batería de respaldo que permite escribir los datos o almacenarlos en una memoria volátil en caso de un corte de energía.

Debido a cómo funcionan los discos duros, los datos siempre se leen y escriben en unidades de páginas. Los discos duros modernos tienen un tamaño de página de 4096 bytes (o 4 KiB) y la distribución real de los datos en el plato no es directamente visible para el host.

Unidades de estado sólido (SSD)

Los SSD almacenan datos en circuitos integrados especiales sin partes móviles, lo que proporciona una baja latencia en sus operaciones de lectura y escritura. en comparación con los discos duros. Estos circuitos integrados se ensamblan de una manera particular para que los SSD sean rentables. Estos circuitos integrados se denominarán memoria flash a partir de ahora. La descripción aquí está simplificada y no es del todo precisa, ya que los detalles también dependen del fabricante real y del modelo del SSD.

Los SSD usan el mismo tamaño de página que los discos duros modernos, aunque la sobrecarga de acceder a una página es casi insignificante en comparación con la de un HDD. Leer una pequeña cantidad de bytes desde un SSD es mucho más eficiente que desde un HDD. La discusión aquí asume que el tamaño de página presentado al anfitrión es el mismo que el tamaño de página de la memoria flash. Al igual que con el disco duro, el host no puede ver directamente el diseño real de los datos en la memoria flash.

La memoria flash está organizada en varios sectores y cada sector tiene varias páginas. Cada página se puede escribir un número limitado de veces y antes de que se pueda actualizar la página, se debe borrar todo el sector donde reside la página. Este esquema tiene algunas ramificaciones.

Cuando se actualizan los datos, los SSD los escriben en una página "nueva" (copia al escribir) o en una página en la que aún no se ha escrito desde la última vez que se borró el sector. Esta escritura hace que la página esté "en uso". Se dice que la página que contiene los datos antiguos está "obsoleta".

Además de las escrituras normales, las páginas en uso se copian regularmente desde sectores con muchas páginas obsoletas a sectores con páginas nuevas. Un sector que tiene todas sus páginas marcadas como obsoletas se borra, lo que hace que todas las páginas de ese sector estén frescas. Esto tiene el efecto neto de más páginas nuevas disponibles para escrituras normales. Borrar un sector puede ser una operación costosa y, a menudo, es el cuello de botella para el rendimiento de escritura. Este proceso se conoce como recolección de basura.

La recolección de basura más eficiente es posible con más sectores con muchas páginas obsoletas. En principio, existen tres tipos de cambios de datos; creaciones de datos, actualizaciones de datos y eliminaciones de datos. Los discos duros tradicionales no se ocupan de la eliminación de datos, ya que el sistema de archivos ignora las páginas. Para una unidad de estado sólido, la recolección de basura se puede realizar de manera más eficiente si conoce estas páginas ignoradas. Esto se implementa mediante el comando ATA TRIM o el comando SCSI UNMAP.

Hay muchos otros aspectos sobre los SSD que no es necesario mencionar aquí para la siguiente discusión. Consulte Wikipedia para obtener más detalles.

Tecnologías de base de datos

Las bases de datos tradicionales utilizan estructuras de datos que minimizan el número de páginas leídas. Este enfoque es crucial cuando se utilizan discos duros tradicionales, ya que el tiempo que se tarda en recuperar los datos es proporcional al número de páginas leídas. Esto también es cierto para los SSD hasta cierto punto, ya que los canales de E / S están optimizados para los HDD, pero los datos se pueden recuperar un orden de magnitudes más rápido desde un SSD que desde un HDD.

Las bases de datos normalmente implementan durabilidad (una de las propiedades de ÁCIDO) utilizando un registro de transacciones, que puede incluir o no los datos reales del usuario. Es probable que las páginas escritas para el registro de transacciones y las páginas escritas para la imagen de base de datos actualizada terminen en el mismo sector, ya que se escriben aproximadamente al mismo tiempo. Esto es especialmente cierto para transacciones pequeñas. Las páginas del registro de transacciones normalmente se volverán obsoletas antes de las páginas escritas recientemente de la imagen de la base de datos. Esto significa que esos sectores pueden terminar pronto con algunas páginas obsoletas que ocuparán espacio, o que los sectores pronto alcancen el umbral para la recolección de basura. El rendimiento puede disminuir en ambos casos.

Vacío de base de datos

RDM 15.0

Adoptamos un enfoque diferente con RDM 15.0. En el nivel del sistema de archivos, la base de datos consta de varios archivos de paquete que contienen datos de usuario, índices y metadatos necesarios para la recuperación y la aspiración. Estos archivos de paquete se denominan colectivamente "paquete".

La perspectiva del sistema de archivos del paquete

Esta sección describe algunas características del paquete observadas por el sistema de archivos y cómo afectan el rendimiento de E / S del SSD.

Un paquete consta de varios archivos de paquete, cada uno con un tamaño máximo de 2 GiB. Los archivos de paquete se escriben secuencialmente agregándolos al final. El tamaño total de los archivos del paquete se mantiene por debajo de un umbral. Cuando se eliminan los archivos de paquete, siempre se eliminan en el orden en que se crearon.

Dado que los archivos de paquete se escriben secuencialmente, es probable que una secuencia de páginas para un paquete determinado se agrupe, especialmente en una gran carga de transacciones, en comparación con otras cargas de E / S. Cuando se asume dicha agrupación en clústeres, no es probable que estos sectores estén sujetos a la recolección de basura hasta que se elimine el archivo del paquete.

Si la suposición anterior no es el caso, es posible que la carga de la base de datos deba mantenerse en una partición separada o en un SSD separado para lograr el rendimiento necesario. Estos detalles están fuera de nuestro control, pero desde la perspectiva del diseño de la base de datos, esto es lo mejor que podemos hacer para lograr el rendimiento de E / S en un SSD.

Aspiración en Raima Database Manager (RDM)

La implementación del paquete se discutirá en esta sección. Comenzaremos con observaciones de versiones anteriores de RDM y presentaremos el diseño RDM 15.0. Si desea profundizar en los detalles técnicos, puede obtener más información en nuestra documentación.

Versiones anteriores de RDM

RDMe 12.0 y anteriores ("RDMe") usaban un registro de transacciones. Esto significaba que los datos se escribían normalmente dos veces: primero en el registro de transacciones y luego en los archivos reales de la base de datos. RDMe también almacenaba elementos con una longitud fija y, en algunos casos, el contenido adicional tenía que almacenarse por separado en otro lugar. Este diseño resultó en un desperdicio de espacio y una sobrecarga adicional cuando el contenido tuvo que dividirse. Tampoco fue posible hacer ningún tipo de compresión sobre los datos.

RDM 14.0 es la primera versión de RDM que ha utilizado un almacén de valores clave en memoria (índice de ID) y un formato de paquete para la gestión de datos en lugar del registro de transacciones tradicional y las ranuras de datos de longitud fija. Sin embargo, reutilizó el espacio en los archivos del paquete. Siempre se realizaba una actualización del paquete utilizando una copia en escritura de la página original a la que tenía espacio disponible. El índice de identificación mantuvo un registro de este espacio no utilizado. Este seguimiento y las estructuras de datos necesarias para utilizar de manera eficiente el espacio no utilizado resultaron ser bastante costosos. También evitó la reutilización del espacio en combinación con la escritura masiva. El rendimiento de E / S tampoco fue óptimo, ya que los datos se escribieron en páginas cuando solo se actualizó una fracción de la página.

RDM 14.1 y RDM 14.2 adoptaron un enfoque ligeramente diferente. En las siguientes secciones, discutiremos principalmente el diseño 15.0 que es similar al diseño 14.2. El diseño 15.0 también comparte algunas características con el diseño 14.1.

RDM 15.0

RDM 15.0 aborda todos los problemas anteriores adoptando un enfoque completamente diferente. Todavía copia al escribir, pero nunca reutiliza el espacio no utilizado en los archivos del paquete. En cambio, siempre escribe hasta el final del último archivo de paquete con estructuras de datos que no utilizan un índice de identificación. Esto significa poder evitar escribir en páginas con solo un espacio parcial disponible.

El espacio no utilizado en los archivos del paquete se borra con un proceso llamado "aspirado". La aspiración es similar a la recolección de basura que se discutió anteriormente, excepto que la aspiración opera en archivos de paquete en lugar de sectores en un SSD. Si se hace bien, pasar la aspiradora mejorará considerablemente la recolección de basura.

Espacio en disco frente a páginas utilizadas

La aspiración tiene dos objetivos principales comparados entre sí: disminuir la cantidad total de espacio en disco para una base de datos y disminuir el número de páginas en las que realmente reside la base de datos. Optimizar para uno podría funcionar en contra del otro. RDM 15.0 aspira siempre el archivo pack más antiguo ”, lo que favorecerá el primer objetivo. Si no se hace referencia al archivo de paquete más antiguo y, por lo demás, no es necesario, se elimina y solo entonces realmente eliminamos el archivo del paquete. RDM 14.1 favoreció el segundo objetivo al aspirar el archivo del paquete con el "en uso" relativo más bajo. RDM 15.0 puede salirse con la suya con menos metadatos en el paquete, ya que solo aspira los archivos del paquete más antiguos. Este enfoque también tiene la ventaja de no tener que copiar los metadatos de los datos eliminados como parte de la aspiración, lo que reduce aún más el costo de la aspiración. Y finalmente, la optimización del espacio en disco también mejora el rendimiento de SSD.

Leer vs escribir

Un aspecto que no debe pasarse por alto es la lectura frente a la escritura. Como hemos señalado anteriormente, la aspiración agresiva limitará el tamaño general de la base de datos. A menudo, lo que es más importante, la aspiración agresiva agrupará los datos que están en uso junto con menos espacio desperdiciado en el medio. Esto es importante cuando se trata de lo que realmente se encuentra en cada página. Mantener los datos agrupados puede significar que más datos en uso pueden caber en menos páginas y, por lo tanto, pueden permanecer en el conjunto de trabajo de la memoria caché del sistema de archivos, reduciendo o eliminando potencialmente la E / S costosa al dispositivo de bloque subyacente. 

Compensación entre escrituras y tamaño total También existe una compensación entre la cantidad de datos escritos y el tamaño total del paquete. Dependiendo de cómo deba diseñarse la aplicación, o cómo el administrador o el usuario tengan que configurar el sistema, puede ser difícil saber exactamente cómo lograr el equilibrio correcto entre los dos. Ese es probablemente el principal desafío con este enfoque. Sin embargo, tenga en cuenta que las alternativas a este enfoque no son muy eficientes. Hemos visto lo ineficiente que puede ser reutilizar el espacio dentro de los archivos del paquete o usar un registro de transacciones.

El resultado neto de este enfoque es que los datos se pueden escribir varias veces como RDM 12.0 y anteriores, pero la diferencia aquí es que las escrituras para RDM 15.0 están agrupadas y, con un umbral adecuado para la aspiración, producirán un excelente rendimiento de E / S y harán recolección de basura en el SSD muy eficiente como se discutió anteriormente.

Formato de archivo de paquete

El formato del archivo del paquete es importante para una aspiración eficiente. Primero, un par de observaciones. En principio, la aspiración se puede realizar de varias formas. RDM 14.1 tenía la capacidad de realizar un vacío agrupado por el ID de ranura en el índice de ID o agrupado por la posición anterior en el archivo del paquete. Ambos se basaron en un índice de identificación y ciertos metadatos en los archivos del paquete.

El enfoque que toma RDM 15.0 es atravesar las estructuras de datos y mover todo lo que reside actualmente en los archivos de paquete que están sujetos a aspiración agregándolo al último archivo de paquete. Las estructuras de datos que contienen referencias a datos que se copian también deben moverse. Por lo tanto, las estructuras de datos en RDM 15.0 tienen información sobre el archivo de paquete más antiguo al que se puede acceder directa o indirectamente. Esto hace posible aspirar el contenido de manera eficiente sin tener que atravesar más datos de los necesarios. Este enfoque también tiene la ventaja de que el contenido se agrupa en función de sus claves, lo que hace que las búsquedas posteriores sean más eficientes.

Necesidad de candados

Además, se puede aspirar sin adquirir bloqueos de escritura. Esto significa que los lectores no se ven particularmente afectados por la aspiración. Las actualizaciones se ven afectadas porque la aspiración de una tabla determinada no se puede realizar en paralelo mientras hay una actualización en curso para esa tabla; sin embargo, se espera que la cantidad de datos que se va a aspirar pueda ser un orden de magnitud menor que la cantidad de datos escritos para una actualización, aunque a menudo puede ser un factor de dos o tres dependiendo de cuán agresivamente aspiramos.

Conclusión

Hemos visto que el formato de archivo para RDM 15.0 es especialmente adecuado para minimizar la E / S del disco y tiene propiedades muy adecuadas para el almacenamiento persistente, incluidos SSD y memoria flash. Al minimizar el disco, la E / S de los dispositivos tendrá una vida útil más larga. Se han omitido muchos detalles para simplificar la discusión. Esperamos que lo hayas disfrutado.

 

por Sverre Hvammen Johansen y Daigoro Toyama