Autor: laboratorio Chen / Laboratorio de Big Data
26 de agosto, estudiantes de doctorado de Star Central invitados del Instituto de Ingeniería de Software de la Universidad Normal del Este de China, profesor de ciencia, tutor Palace, para celebrar traer "serie de conferencias de tecnología de base de datos de vanguardia", compartir una base de datos en la vanguardia de la industria del desarrollo E investigación de puntos calientes. Ahora compartiré con ustedes la primera conferencia de la capacitación de Gong Xueqing: el desarrollo de la tecnología de bases de datos en memoria.
- Sistema de gestión de bases de datos basado en disco -
Los sistemas tradicionales de administración de bases de datos (DBMS) generalmente usan diseños basados en disco. La razón es que el diseño inicial de los sistemas de administración de bases de datos estaba restringido por recursos de hardware como CPU única, núcleo único y poca memoria disponible. Toda la base de datos se colocó en la memoria. No es realista y solo se puede colocar en un disco. Dado que el disco es un dispositivo de almacenamiento muy lento (en relación con la velocidad de la CPU), el sistema de gestión de bases de datos desarrollado por la academia y la industria debe adaptarse a las condiciones del hardware en ese momento en la arquitectura. Los sistemas de gestión de bases de datos como Oracle y MySQL todavía se utilizan en la actualidad. Este diseño de arquitectura todavía se utiliza.
Con el desarrollo de la tecnología, la memoria se ha vuelto más barata y la capacidad se ha vuelto más grande. La memoria de una sola computadora se puede configurar a cientos de GB o incluso al nivel de TB. Para una aplicación de base de datos, dicha configuración de memoria es suficiente para cargar todos los datos comerciales en la memoria para su uso. Aunque la cantidad de datos procesados por big data puede ser de petabytes, esos datos generalmente son datos no estructurados. En términos generales, la escala de datos estructurados no es particularmente grande. Por ejemplo, los datos de transacciones de un banco durante 10 a 20 años pueden ser solo decenas de terabytes. Si los datos estructurados de esta escala se colocan en un DBMS basado en disco, frente al procesamiento de transacciones y consultas SQL a gran escala, está limitado por el rendimiento de E / S del disco y, en muchos casos, el sistema de base de datos se convertirá en el cuello de botella de rendimiento de todo el sistema de aplicación.
Si configuramos suficiente memoria para el servidor de la base de datos, ¿podemos seguir usando la arquitectura original y cargar todos los datos estructurados en el búfer de memoria para resolver el problema de rendimiento del sistema de la base de datos? Aunque este método puede mejorar el rendimiento del sistema de base de datos hasta cierto punto, aún está limitado por la velocidad de lectura y escritura del disco en términos de mecanismo de registro y ubicación de datos de actualización, y está lejos de aprovechar el gran sistema de memoria. Los sistemas de administración de bases de datos en memoria y los sistemas tradicionales de administración de bases de datos basados en disco todavía tienen diferencias obvias en el diseño de la arquitectura y el uso de la memoria.
- Modo de gestión de búfer -
En los sistemas tradicionales de gestión de bases de datos, el principal medio de almacenamiento de datos es el disco. Por ejemplo, una tabla lógica generalmente se asigna a un archivo en el disco y el archivo se almacena en el disco en forma de bloque de datos (también conocido como Página). Para los datos estructurados, se guardará un registro en un bloque de datos en el disco, y la ubicación específica del registro se puede indicar mediante el ID del bloque de datos y la compensación / compensación. Esta forma de bloque de datos también se llama Página Ranurada.Como su nombre lo indica, el bloque de datos se divide en muchas ranuras y luego se coloca un Registro en una determinada ranura. Al procesar un registro, el registro se puede obtener del disco a través de la ID de página + Offset que representa la dirección del registro; luego el sistema leerá el bloque de datos almacenando el registro del disco en el búfer (el grupo de búfer se divide en Múltiples cuadros, cada cuadro puede guardar un bloque de disco), y luego leer el registro del búfer al área de trabajo del hilo o transacción para su procesamiento; después del procesamiento, escriba el registro actualizado en el bloque de datos en el búfer, y luego El sistema de administración de la base de datos vuelve a escribir el bloque de datos modificado en el disco. 
Ejemplo de acceso a datos en un sistema de gestión de bases de datos basado en disco
En un sistema de administración de bases de datos basado en disco, el índice completo generalmente se carga en la memoria cuando se procesa una consulta, y el tamaño de un nodo de índice en un índice de árbol B + generalmente es un bloque de datos. Cada valor de clave indexado tiene un elemento de índice correspondiente en el nodo hoja de índice, y el elemento de índice contiene la ubicación de almacenamiento (ID de página + Desplazamiento) del registro correspondiente al valor de clave; cuando se carga un bloque de datos en el búfer de la memoria Durante el tiempo de zona, el DBMS mantiene la conversión entre ID de página + dirección de compensación y dirección de búfer de memoria a través de la estructura de tabla de página. Al acceder a los datos, primero busque el ID de página correspondiente + Desplazamiento en la tabla de páginas. De lo contrario, significa que el registro todavía está en el disco. Primero debe leer el bloque de datos del disco en el búfer y luego en la tabla de páginas. Mantenga una buena relación de mapeo de direcciones. El proceso de implementación específico es que el DBMS buscará primero los marcos disponibles en el búfer y, si no es así, seleccionará la página sucia (Página sucia) para reemplazarla de acuerdo con el algoritmo de reemplazo del búfer; si se selecciona una página sucia para reemplazarla, es necesario reemplazarla. El bloqueo de pestillo se agrega a la posición para garantizar que otras transacciones no accedan a la posición durante el proceso de reemplazo (el bloqueo se introducirá más adelante). Una vez que la página sucia se vuelve a escribir en el disco, el sistema puede leer el bloque de datos de destino en esa posición en el búfer y luego escribir su dirección en el búfer en la tabla de páginas para mantener la relación de asignación de direcciones; después de que se completen estas operaciones Luego suelte el bloqueo del pestillo en el marco. 
Asignación de direcciones de memoria
en DBMS tradicional Para DBMS tradicionales basados en disco, incluso si el búfer de memoria es lo suficientemente grande para cargar todos los datos en la memoria, la asignación de direcciones y la conversión en el proceso de acceso a los datos todavía existen, pero el La sobrecarga de cargar bloques de datos del disco a la memoria. Incluso si todos los datos se han cargado en la memoria, todavía existe una gran brecha entre el rendimiento de un DBMS basado en disco y una base de datos en memoria, esta es una de las razones importantes.
En resumen, una diferencia importante entre la tecnología de implementación del DBMS basado en disco y la base de datos de memoria es: cuando se accede a los datos, el DBMS basado en disco necesita convertir la dirección de los datos en el disco a la dirección en la memoria a través del mapeo de direcciones, mientras que la base de datos de la memoria En el diseño, la dirección de los datos en la memoria se usa directamente.
- Garantía de atributo ACID de transacción -
En un sistema de administración de bases de datos, es necesario asegurar las propiedades ACID de las transacciones en escenarios de acceso concurrente, es decir, la atomicidad, consistencia, aislamiento y durabilidad de las transacciones. Las propiedades ACID de las transacciones se realizan principalmente mediante dos mecanismos en el sistema de gestión de la base de datos, uno es el control de concurrencia y el otro es el mecanismo de registro / recuperación.
- Control de concurrencia
La mayoría de los DBMS tradicionales basados en disco adoptan un control de simultaneidad pesimista basado en bloqueos, es decir, la transacción primero se bloquea cuando se accede a los datos y luego se desbloquea cuando se agotan. Si hay un conflicto cuando otras transacciones acceden a los datos, deben esperar a que se mantenga el bloqueo. La transacción libera el bloqueo. El DBMS tradicional generalmente mantiene una estructura de datos separada en la tabla de bloqueos de memoria para almacenar todos los bloqueos, que son administrados uniformemente por el módulo Administrador de bloqueos, de modo que los datos en los bloqueos de memoria y los búferes se almacenan y administran por separado. Cuando una transacción accede a los datos, primero se aplica al Administrador de bloqueo para el bloqueo correspondiente a los datos y luego accede a los datos; una vez que se completa la ejecución, el bloqueo se libera a través del Administrador de bloqueo. El Administrador de bloqueo puede garantizar que todas las aplicaciones de transacciones y los bloqueos de liberación sigan un estricto protocolo de bloqueo de dos etapas (Protocolo de bloqueo estricto de 2 fases). Al mismo tiempo, la sobrecarga generada por el mecanismo de control de concurrencia no está directamente relacionada con el procesamiento comercial real del usuario y es una sobrecarga adicional que se utiliza para garantizar la coherencia y el aislamiento de las transacciones.
Las bases de datos en memoria también necesitan bloqueos para acceder a los datos, pero a diferencia de los DBMS basados en disco, los bloqueos y los datos se almacenan juntos en la memoria, por lo general, la información del bloqueo se almacena en el encabezado del registro de datos. ¿Por qué el DBMS basado en disco coloca la información de bloqueo en la Tabla de bloqueo por separado, mientras que la base de datos de memoria puede almacenar la información de bloqueo y los datos juntos? Porque en un DBMS basado en disco, es probable que el sistema reemplace el bloque de datos desde el búfer de memoria al disco. Si la información del bloqueo y los datos se juntan, una vez que se reemplaza el bloque de datos, Lock Manager y todas las transacciones no pueden obtener información La información de bloqueo de los datos. Por lo tanto, para el DBMS tradicional basado en disco, el bloqueo debe mantenerse por separado en la memoria y siempre debe mantenerse en la memoria y no puede ser reemplazado. Para las bases de datos en memoria, este escenario no existe.
De hecho, hay dos mecanismos de bloqueo en el sistema de administración de la base de datos, llamados Lock y Latch respectivamente, para proteger la consistencia de los datos de ser destruida por el acceso concurrente. El mecanismo de bloqueo protege el contenido lógico de la base de datos, por lo general tiene una duración prolongada, generalmente todo el proceso de ejecución de la transacción, y el mecanismo de bloqueo debe soportar la reversión de la transacción para deshacer la modificación de datos por la transacción. El mecanismo Latch es para garantizar que las estructuras de datos específicas en la memoria no causen errores debido al acceso concurrente. Por ejemplo, cuando se produce una inserción, eliminación, etc. en una cola compartida durante la programación multiproceso, Latch es necesario para garantizar que la cola durante la operación no se vea afectada por otras operaciones. Interferencia del hilo. El tiempo de espera del Latch está relacionado con la operación, y la operación finaliza cuando se realiza, y no es necesario admitir la reversión de la modificación de datos.
Por lo tanto, si el DBMS tradicional quiere operar en una página en el búfer, necesita agregar Latch; si va a modificar el contenido de la base de datos, necesita agregar Lock, que se mantiene y administra por separado en la tabla de bloqueo. La siguiente figura es una comparación simple de Lock y Latch. 
* En el registro y recuperación
del sistema de gestión de base de datos, el registro y el mecanismo de recuperación es una manera de iniciar la sesión para garantizar la atomicidad y durabilidad de las transacciones. La atomicidad significa que todas las operaciones de una transacción deben realizarse correctamente o deshacerse al mismo tiempo, y se pueden revertir de acuerdo con el registro cuando no se puede realizar la mitad de la ejecución; persistencia significa que si los datos se pierden, se pueden recuperar de acuerdo con el registro.
En el registro y recuperación de DBMS tradicionales, el concepto más importante es WAL (registro de escritura anticipada): registro de escritura anticipada. WAL significa que todas las operaciones de actualización en el sistema tienen registros correspondientes y, antes de que se coloque el registro, no se permite colocar la modificación de los datos. Cada registro en el sistema tiene un LSN (Número de secuencia de registro), y todos los números de LSN aumentan monótonamente El proceso de registro en el disco es escritura continua (escritura secuencial) en el disco. Sin embargo, si el sistema sigue estrictamente un registro correspondiente a una operación e inmediatamente después de que se coloca el registro, el resultado de la actualización de datos de la operación se coloca en el disco, el rendimiento del sistema se verá muy afectado. Por lo tanto, la mayoría de DBMS adoptará la estrategia de gestión de búfer Steal + No Force. Robar significa que el DBMS puede descargar las actualizaciones de las transacciones no confirmadas en el disco sin esperar a que se envíe la transacción antes de descargar las actualizaciones en el disco, lo que mejora la flexibilidad y el rendimiento de la descarga del sistema; si ocurre un bloqueo cuando la transacción no está confirmada, la actualización puede ser posible Se ha escrito en el disco y luego debe revertirse mediante la operación de deshacer del registro. Sin fuerza significa que después de que se haya confirmado la transacción, la actualización de los datos aún se puede almacenar en el búfer de memoria sin escribirse en el disco, y luego escribirse en el disco una vez que se fusiona la actualización de otras transacciones, proporcionando un espacio optimizado para el sistema. Pero el posible riesgo de No Force es: si la transacción se ha confirmado correctamente pero la actualización no se escribe en el disco y se produce un bloqueo en este momento, la actualización de datos que aún se encuentra en la memoria se perderá. Debe basarse en el registro que se ha escrito en el disco (transacción exitosa El requisito previo para el envío es que todos sus registros deben haberse colocado) para la operación de rehacer.
Con el mecanismo WAL y Steal + No Force, el DBMS basado en disco puede proporcionar la máxima flexibilidad para optimizar la E / S del disco. Pero para las bases de datos en memoria, todos los datos se almacenan en la memoria. ¿Sigue siendo necesario este mecanismo? Una cosa que está clara es que la base de datos en memoria todavía necesita el registro, pero es diferente del DBMS basado en disco. Solo la información requerida para las operaciones de rehacer se registra en el registro y la información requerida para deshacer no se registra. Todos pueden pensar por qué es esto. Por otro lado, la base de datos en memoria no registra la actualización del índice durante el proceso de registro, sino que solo registra la actualización de la tabla básica, por lo que el contenido que debe escribirse en el disco durante el proceso de registro es mucho menor. Cuando la base de datos en memoria falla y necesita ser restaurada, primero restaure la tabla básica a partir de los datos de Check Point y los registros guardados en el disco, y luego reconstruya el índice en la memoria.
- Sobrecarga de rendimiento de DBMS orientado a disco -
En 2008, un documento de SIGMOD analizó el costo de rendimiento de la base de datos orientada a disco y dividió el costo de todo el sistema de base de datos. El análisis encontró que: asumiendo que el costo total de un procesamiento comercial es del 100%, de hecho, solo menos del 7% de los recursos están procesando la lógica comercial; el 34% se utiliza para la gestión del búfer, como la carga y reemplazo del búfer, la conversión de direcciones, etc .; el 14% Se ocupa del bloqueo; el 16% se ocupa del bloqueo; luego, el 12% se ocupa del registro; el último 16% se utiliza para procesar índices de árbol B. En otras palabras, después de que los recursos de la máquina se ejecutan a plena capacidad, solo el 7% se utiliza realmente para procesar la lógica empresarial. 
Sobrecarga de rendimiento del sistema de base de datos de disco
Entonces , ¿se puede eliminar la parte costosa para aumentar la proporción de recursos de lógica empresarial? Si la base de datos es de un solo usuario, no hay conflicto de contención concurrente, entonces se pueden guardar los gastos generales de bloqueo y bloqueo. También hay algunas soluciones de un solo subproceso en la historia, como dividir la base de datos en múltiples particiones, cada partición es procesada por un subproceso, etc. Pero tal esquema tiene desventajas obvias: cada partición se procesa en serie. Si hay una transacción larga en ejecución, el procesamiento en serie hará que todas las transacciones posteriores se bloqueen hasta el final de la transacción. Además, la E / S de disco es el cuello de botella de los sistemas orientados a disco al realizar el procesamiento de transacciones a gran escala. Si se realiza una ejecución de un solo subproceso, la CPU estará inactiva al leer datos del disco. Pero para las bases de datos en memoria, todos los datos se almacenan en la memoria y la E / S del disco no es el principal cuello de botella del sistema, por lo que la tecnología utilizada es muy diferente a la anterior. Por supuesto, la tecnología también ha sido objeto de varios intentos en el proceso de desarrollo, algunos avances tecnológicos no son adecuados para el trasfondo real y se olvidan lentamente.
Se puede ver que el sistema de administración de bases de datos basado en disco ha realizado una gran cantidad de trabajo de administración adicional. Aunque estas tareas no se ocupan de la lógica empresarial, son indispensables para garantizar la corrección de la lógica empresarial. Para las bases de datos en memoria, la pregunta es qué optimizaciones deben realizarse para obtener el mejor rendimiento. En comparación con un sistema basado en disco, el almacenamiento principal de una base de datos en memoria es la memoria, pero aún se necesita un disco para Check Point y Logging. En caso de una falla, los datos del punto de control y los registros en el disco se utilizan para restaurar toda la base de datos en memoria.
- Desarrollo histórico de la tecnología de bases de datos de memoria -
El desarrollo de bases de datos en memoria se puede dividir aproximadamente en tres etapas: 10 años de 1984 a 1994; 10 años de 1994 a 2005; y después de 2005 hasta el presente. En la primera etapa, aparecieron las tecnologías de procesamiento relacionadas con la memoria; en la segunda etapa, aparecieron algunos sistemas de bases de datos en memoria; y la tercera etapa es el escenario al que nos enfrentamos ahora.
- 1984-1994
De 1984 a 1994, el mundo académico presentó muchas hipótesis para la gestión de datos de la memoria, como búferes de memoria que pueden contener todos los datos, envío de grupos y técnicas de optimización de envío rápido. Al mismo tiempo, también se propone un método de acceso a datos orientado a la memoria, que ya no usa el enfoque Page ID + Offset como DBMS basado en disco para acceder, sino que usa directamente direcciones de memoria en todas las estructuras de datos. También hay una estructura de índice de árbol T orientada a la memoria y el sistema se divide en múltiples motores de procesamiento de acuerdo con las funciones. Algunos se especializan en el procesamiento de transacciones y otros se especializan en la recuperación, lo que equivale a tener dos núcleos, uno es responsable del procesamiento de transacciones y el otro es responsable de Procesamiento de registros. Además, existe una base de datos de memoria principal relacionada con la partición, que divide la base de datos en muchas particiones, cada partición corresponde a un núcleo (o nodo) y no hay competencia entre procesos. Se puede observar que el desarrollo de la tecnología de bases de datos durante este período ha estado considerando qué tecnologías se pueden utilizar si todos los datos se almacenan en la memoria. Sin embargo, debido a las condiciones del hardware en ese momento, estas tecnologías no se han aplicado a gran escala.
- De
1994 a 2005, algunos sistemas comerciales de bases de datos en memoria aparecieron entre 1994 y 2005, como Dali desarrollado por Bell Labs y Smallbase, el predecesor de Oracle Times Ten. Al mismo tiempo, han aparecido algunos sistemas de optimización orientados a múltiples núcleos, como P * -Time (ahora motor de procesamiento de transacciones SAP-HANA). En ese momento, algunas tecnologías de implementación sin bloqueo también se aplicaron a los sistemas de bases de datos de memoria, a saber, las tecnologías de programación sin bloqueo y las estructuras de datos.
- Resumen de las
dos primeras etapas Las tecnologías de las dos primeras etapas se pueden dividir aproximadamente en las siguientes categorías:
1. Resolver el acceso en dirección del Buffer Pool : reemplace el acceso indirecto con acceso directo a la dirección de memoria; los nodos hoja del índice ya no se colocan en la página ID y Offset son directamente la dirección de memoria.
2. Partición de datos : una tecnología que divide los datos y no realiza un control de acceso simultáneo.
3. Sin bloqueo y consciente de la caché : en comparación con los sistemas de administración de bases de datos orientados a disco que almacenan un nodo de índice en un bloque de datos, un nodo de índice en una base de datos de memoria tiene la longitud de una o varias líneas de caché.
4. Bloqueos de grano grueso : bloquee una tabla o una partición a la vez en lugar de un registro, pero esta técnica ahora se usa menos, porque los escenarios de múltiples núcleos son altamente competitivos para el acceso y los bloqueos de grano grueso pueden reducir el grado de concurrencia. (Actualmente se usa menos)
5. Partición funcional : El sistema se divide de acuerdo con las funciones, y cada hilo es responsable de funciones específicas. (Actualmente se usa menos)
Resumen de tecnología histórica de DBMS- El desarrollo moderno de sistemas de bases de datos -
En el entorno actual, las condiciones del hardware tienen básicamente tres características: 1. Memoria grande y barata; 2. CPU multinúcleo (desde el aumento de la frecuencia hasta el aumento del número de núcleos); 3. Multi-Socket, que significa multi-core y multi-CPU, significa procesamiento El grado de concurrencia puede ser cada vez mayor. Estas son las situaciones actuales a las que se enfrenta la investigación y el desarrollo de sistemas de bases de datos.
En los entornos de hardware modernos
, las E / S de CPU y disco ya no son los principales cuellos de botella para las bases de datos en memoria. Por lo tanto, las técnicas de optimización se consideran actualmente principalmente desde las siguientes perspectivas: - Elimine el mecanismo de búfer tradicional : el mecanismo de búfer tradicional no es aplicable en las bases de datos de memoria. Los bloqueos y los datos no necesitan almacenarse en dos lugares, pero aún se requiere el control de concurrencia, que es diferente del control de concurrencia pesimista tradicional basado en bloqueos Estrategia de control de concurrencia.
- Minimice la sobrecarga del tiempo de ejecución : la E / S de disco ya no es un cuello de botella. El nuevo cuello de botella radica en aspectos como el rendimiento informático y las llamadas a funciones, y es necesario mejorar el rendimiento en tiempo de ejecución.
- Adopción del método de compilación y ejecución : Las bases de datos tradicionales utilizan principalmente el motor de ejecución del modelo volcán.Cada Operador se implementa como un iterador, proporcionando tres interfaces: Inicial, Get-Next y Closed, que se llaman secuencialmente de arriba a abajo. La sobrecarga de llamadas de este motor de ejecución no representa una proporción importante en un sistema de administración de bases de datos basado en disco (la E / S de disco es el principal cuello de botella), pero puede constituir un cuello de botella en una base de datos de memoria. Si desea leer 1 millón de registros, debe llamar 1 millón de veces y el rendimiento será insoportable, por eso se utilizan una gran cantidad de métodos de compilación y ejecución en las bases de datos de memoria. Llame directamente al código de máquina compilado, ya no necesita interpretación en tiempo de ejecución y llamadas de puntero, el rendimiento se mejorará de manera efectiva.
- Construcción de índices escalables de alto rendimiento : aunque la base de datos en memoria no lee datos del disco, el registro aún debe escribirse en el disco y se debe considerar el problema de que la velocidad de escritura del registro no puede mantenerse. Puede reducir el contenido del registro. Por ejemplo, elimine la información de deshacer y escriba solo la información de rehacer; escriba solo los datos pero no la actualización del índice. Si el sistema de la base de datos falla, después de cargar los datos del disco, puede reconstruir el índice de manera simultánea. Siempre que la tabla subyacente esté presente, el índice se puede reconstruir y el índice se puede reconstruir en la memoria más rápido.
- Resumen de
este artículo: este artículo presenta principalmente las principales similitudes y diferencias entre el sistema de gestión de bases de datos en disco y el sistema de gestión de bases de datos en memoria en varios aspectos, así como el desarrollo técnico de la base de datos en memoria desde 1984 hasta el presente. Más adelante, continuaré compartiendo el desarrollo de la tecnología de bases de datos en memoria, desde la perspectiva de la organización de datos, la indexación, el control de concurrencia, la consulta compilada y la persistencia, introduciré y compararé las tecnologías de implementación de varios productos de bases de datos en memoria convencionales.
Nota: Parte del material de este artículo proviene de:
- Tutorial de sistemas de bases de datos de memoria principal moderna en la conferencia VLDB 2016
- Curso de sistemas avanzados de bases de datos (Advanced Database Systems) del profesor Andy Pavlo de CMU (Carnegie Mellon University)