Autor: Li Haixiang Tencent TEG expertos en tecnología de bases de datos
Una es la empresa de tecnología líder en el mundo, y la otra es la cuna de la investigación académica básica sobre bases de datos en China. Recientemente, el Laboratorio de Innovación Colaborativa de la Universidad Renmin de China-Tencent celebró oficialmente una ceremonia de inauguración. Se entiende que las dos partes se han centrado en el campo de la investigación básica de bases de datos durante muchos años de cooperación de vanguardia entre la industria, la universidad y la investigación, así como el plan de capacitación en cooperación de talentos de bases de datos, al tiempo que avanzan en la seguridad y el control de las bases de datos, mientras llevan a cabo reservas de investigación de innovación de vanguardia para la futura era digital de múltiples escenarios a gran escala. Los resultados del laboratorio, incluido el "sistema de base de datos a tiempo completo" y otros logros, se han incluido en VLDB y otras conferencias internacionales de primer nivel y, al mismo tiempo, se han solicitado varias patentes de tecnología nacionales.
Al mismo tiempo que se inauguró el laboratorio, el equipo de investigación de la Universidad Tencent y Renmin de China también abrió un nuevo sistema de verificación de tecnología de procesamiento de transacciones de 3TS Tencent de resultados de investigación colaborativa.
Tencent Transaction Processing Testbed System (3TS) es un sistema de verificación para el procesamiento de transacciones de bases de datos desarrollado conjuntamente por el equipo TDSQL de base de datos distribuida de grado financiero desarrollado por Tencent y el Laboratorio clave de ingeniería de datos e ingeniería del conocimiento del Ministerio de Educación de la Universidad Renmin de China. El sistema tiene como objetivo diseñar y construir un marco unificado para el procesamiento de transacciones (incluidas las transacciones distribuidas), y a través de la interfaz de acceso proporcionada por el marco, es conveniente para los usuarios construir rápidamente nuevos algoritmos de control de concurrencia; el banco de pruebas proporcionado por el sistema de verificación puede facilitar a los usuarios de acuerdo con De acuerdo con las necesidades de los escenarios de aplicación, realice una comparación de rendimiento justa de los algoritmos de control de concurrencia principales actuales en el mismo entorno de prueba y seleccione un algoritmo de control de concurrencia óptimo. En la actualidad, el sistema de verificación ha integrado 13 algoritmos de control de concurrencia convencionales y proporciona pruebas de referencia comunes como TPC-C, Sysbench y YCSB. 3TS proporciona además un punto de referencia de prueba de nivel de coherencia, en vista de la dificultad de la selección del sistema causada por el desarrollo explosivo de los sistemas de bases de datos distribuidas en esta etapa, y proporciona discriminación de nivel de coherencia y comparación de pruebas de rendimiento.
El sistema 3TS tiene como objetivo explorar en profundidad las teorías relevantes y las tecnologías de implementación del procesamiento de transacciones de bases de datos. Su concepto central es: apertura, profundidad y evolución. Apertura, adherirse al corazón del código abierto, compartir conocimiento y tecnología; profundidad, practicar el espíritu de la investigación sistemática, investigar los problemas esenciales de la tecnología de procesamiento de transacciones, no romper Loulan y nunca regresar; la evolución es un largo camino por recorrer, lo haré Busca arriba y abajo, sigue avanzando, sigue avanzando.
1. Arquitectura general de 3TS
Como marco relacionado con la tecnología de procesamiento de transacciones, los temas esenciales que 3TS se compromete a explorar incluyen principalmente:
¿Cuántas anomalías de datos hay en el mundo? ¿Cómo establecer un método de investigación sistemático para datos anormales?
¿Por qué existen muchos tipos de algoritmos de control de acceso concurrentes? ¿Existe alguna relación esencial entre varios algoritmos de control de acceso concurrentes?
Una vez distribuida la base de datos de transacciones de una sola máquina, ¿qué aspectos (disponibilidad, fiabilidad, seguridad, coherencia, escalabilidad, función, rendimiento, arquitectura ...) se verán afectados?
¿Qué nuevas tecnologías afectarán y cómo afectarán a los sistemas de bases de datos transaccionales distribuidas?
¿Cómo se debe establecer el sistema de evaluación y evaluación del sistema de bases de datos transaccionales distribuidas?
A nivel de código, cada una de las preguntas de investigación anteriores tiene un subsistema correspondiente. Por ejemplo, la primera fuente abierta incluye el subsistema 3TS-DA y el subsistema 3TS-Deneva.
2. 3TS-DA, subsistema de datos anormales
El subsistema anormal de datos 3TS-DA se encuentra debajo de la ruta src / 3ts / da, y su estructura de proyecto se muestra en la siguiente figura:
Creador de historial: responsable de generar el historial y enviarlo al algoritmo para su verificación.
Grupo CCA: CCA significa algoritmo de control de acceso concurrente, que puede realizar la detección de anomalías en el historial entrante y devolver resultados de detección de anomalías.
Outputter: responsable de enviar los resultados de detección de cada CCA en el historial actual al archivo.
Funciones de corriente del subsistema 3TS-DA:
Generación de datos de prueba: admite tres tipos de métodos de generación de historial, generación transversal, generación aleatoria y lectura de texto.
Adición de algoritmos: proporciona una interfaz de algoritmo unificada, que puede agregar nuevos algoritmos concurrentes de manera más conveniente. Al mismo tiempo, el marco en sí tiene una variedad de algoritmos, que incluyen: serializable, serializable por conflicto, SSI, WSI, BOCC, FOCC, etc.
Indicadores de prueba: el marco proporciona una variedad de indicadores de prueba, que incluyen: tasa de reversión del algoritmo, tasa de reversión verdadera, tasa de reversión falsa, tiempo de ejecución, etc.
Expansión de anomalías: el marco implementa el algoritmo de expansión de anomalías de datos, que se puede expandir para generar un número ilimitado de historial de anomalías de datos para pruebas de algoritmos.
3. 3TS-Deneva, marco de algoritmos concurrentes
Devena [1] es un marco de evaluación de un algoritmo de control de acceso concurrente de base de datos de memoria distribuida de código abierto del MIT. El código original se encuentra en https://github.com/mitdbg/deneva. Puede estudiar las características de rendimiento de los protocolos de control de concurrencia en un entorno controlado. El marco proporciona algoritmos convencionales como Maat, OCC, TO, Locking (No Wait, Wait Die) y Calvin . 3TS-Deneva es una mejora del sistema original de Tencent basado en Deneva, que incluye múltiples niveles. Entre ellos, a nivel de algoritmo, se han agregado más algoritmos de control de acceso concurrentes, que incluyen: serializable, conflict serializable, SSI, WSI, BOCC, FOCC, Sundial, Silo, etc.
3.1 Infraestructura
Devena usa un motor personalizado y algunas otras configuraciones, y puede implementar e implementar diferentes protocolos de control de concurrencia en esta plataforma para una evaluación justa como sea posible. La arquitectura del sistema, como se muestra en la Figura 1, incluye principalmente dos módulos:
La instancia del cliente, como iniciadora de la transacción. Cada hilo del cliente es responsable de iniciar solicitudes de transacción, colocar las solicitudes de transacción iniciadas en la cola de mensajes y enviarlas al servidor para su ejecución específica. Las instancias de cliente y servidor están en una topología completamente conectada y generalmente se implementan en diferentes máquinas;
Instancia del lado del servidor, que ejecuta específicamente varias operaciones en la transacción. Hay datos en diferentes instancias del servidor, y los datos se indexan mediante un hash consistente, formando así una tabla de asignación de particiones global entre la IP del servidor y los datos almacenados. Al controlar que la asignación de particiones no se modifique durante la prueba, se garantiza que la tabla de asignación será Todos los nodos se pueden obtener con precisión. La comunicación entre el cliente y la instancia del servidor, el servidor y la instancia del servidor utiliza el protocolo TCP / IP. Cada instancia de servidor se puede subdividir en cuatro módulos:
-
Ingrese a la cola de mensajes para almacenar temporalmente los mensajes enviados por el cliente / otro servidor;
El motor de ejecución asigna múltiples subprocesos de trabajo para analizar y ejecutar realmente los mensajes en la cola de mensajes, utilizando un método de programación de recursos que une un núcleo a un subproceso;
Módulo de control de concurrencia, el hilo de trabajo necesita mantener la información requerida por el protocolo de control de concurrencia específico durante la ejecución de la operación de transacción, y ejecutar el proceso especificado en el protocolo para asegurar que el protocolo de control de concurrencia especificado surta efecto;
El módulo de almacenamiento de datos es responsable de administrar los datos en esta instancia y almacenar los datos en la memoria.
Figura 1 Diagrama de la arquitectura del sistema Deneva
En 3TS, se mejoró Deneva. El código mejorado se encuentra debajo de la ruta contrib / deneva, y su estructura interna del proyecto se muestra en la Figura 2:
Figura 2 Diagrama del marco de implementación de Deneva
Deneva se divide en dos tipos de nodos: servidor y cliente.
El cliente se utiliza para generar y enviar la consulta de carga que se ejecutará al servidor. El servidor se utiliza para coordinar la ejecución de la consulta de carga enviada por el cliente.
Módulos compartidos de cliente y servidor:
-
MsgQueue: la cola de mensajes almacena el mensaje que se enviará.
MsgThread: El hilo de envío de mensajes, que cíclicamente saca msg de MsgQueue y lo envía.
InputThread: hilo de recepción de mensajes, recibiendo información del Servidor / Cliente.
Módulo propietario en el cliente:
-
ClientQueryQueue: la cola de consultas del cliente, que almacena la lista de consultas generada antes de que comience la prueba.
ClientThread: el hilo del cliente saca cíclicamente la consulta de ClientQueryQueue y la envía al servidor a través de MsgThread y MsgQueue.
Módulo propietario en el servidor
-
WorkQueue: La cola de mensajes pendientes del servidor. Después de que InputThread reciba el mensaje, se colocará en WorkQueue.
WorkThread: el hilo de ejecución del servidor, que obtiene msg de WorkQueue para realizar el procesamiento. Una vez completada la ejecución, generará y devolverá msg, que también se envía a través de MsgThread y MsgQueue.
3.2 Proceso de ejecución de la transacción
En Deneva, como se muestra en la Figura 3, el flujo de ejecución de una transacción es:
1) El cliente primero inicia una solicitud de transacción (compuesta de múltiples operaciones) y coloca la transacción en ClientQueryQueue. ClientThread eliminará la solicitud de transacción de la cola y la almacenará en la cola de mensajes MsgQueue. Después de eso, el hilo de envío de mensajes sacará el conjunto de operaciones de una determinada transacción de MsgQueue, lo encapsulará como una Solicitud y lo enviará a un determinado servidor (determinado por los datos a los que se accede por la primera operación) como el nodo coordinador de esta transacción;
2) Una vez que la solicitud llega al servidor, el servidor analiza la solicitud primero y coloca todas las operaciones de esta transacción como un elemento en la cola de trabajo (WorkQueue). En la cola de trabajo se colocan las nuevas transacciones del cliente y las operaciones remotas de las transacciones que ya han comenzado, estas últimas tienen mayor prioridad que las primeras en la cola. Los subprocesos en el grupo de subprocesos de trabajo sondean la cola de trabajo y procesan las operaciones en la transacción. Cuando un subproceso de trabajo procesa la operación de la transacción actual, primero inicializa la transacción, luego realiza operaciones de lectura y escritura en orden y finalmente confirma o revierte;
En el proceso de ejecución de la transacción, existen dos situaciones que harán que la transacción entre en espera, una es esperar a que se libere el bloqueo exclusivo de un determinado recurso; la otra es acceder a los datos en el servidor remoto. Cuando el acceso remoto a los datos en otros servidores requiere esperar, el servidor remoto devolverá la instrucción WAIT al nodo de coordinación actual. El nodo de coordinación almacenará temporalmente el estado de espera de la transacción actual y programará el hilo de trabajo actual para realizar otras operaciones de transacción, evitando así Bloqueo de hilos de trabajo. Cuando una transacción en espera puede continuar ejecutándose, según la estrategia de programación de prioridad de la cola de trabajo, continuará siendo ejecutada por el primer subproceso de trabajo disponible;
Las operaciones adicionales requeridas por el protocolo de control de concurrencia se integrarán en el proceso de ejecución de la transacción, incluidas las operaciones de lectura y escritura, las operaciones de verificación, las operaciones de confirmación / reversión, etc.
3) Cuando el nodo coordinador completa la operación de una determinada transacción, colocará el resultado de la ejecución de la transacción en la cola de mensajes, y luego el hilo de envío del mensaje notificará al cliente el resultado de la ejecución de la transacción actual.
Figura 3 Diagrama de flujo de ejecución de transacciones de Deneva
4. Descripción general de las transacciones distribuidas
La literatura [15] define la transacción distribuida como:
Una transacción distribuida es una transacción de base de datos en la que participan dos o más hosts de red. Por lo general, los hosts proporcionan recursos transaccionales, mientras que el administrador de transacciones es responsable de crear y administrar una transacción global que abarque todas las operaciones contra dichos recursos. Las transacciones distribuidas, como cualquier otra transacción, deben tener las cuatro propiedades ACID (atomicidad, consistencia, aislamiento, durabilidad), donde la atomicidad garantiza resultados de todo o nada para la unidad de trabajo (paquete de operaciones).
La transacción distribuida toma el sistema distribuido como base física y se da cuenta de los requisitos semánticos del procesamiento de la transacción, es decir, las características ACID también deben cumplirse en el sistema distribuido. Por lo tanto, el procesamiento de transacciones distribuidas de bases de datos distribuidas también debe seguir las teorías relacionadas con las transacciones en el sistema de base de datos independiente, garantizar que cada transacción cumpla con los requisitos de ACID y utilizar tecnología de control de acceso concurrente distribuido para tratar las anomalías de datos en el sistema distribuido. Realice las funciones ACID de transacciones distribuidas.
La tecnología básica del mecanismo de procesamiento de transacciones distribuidas se basa en la tecnología de procesamiento de transacciones en el sistema de base de datos independiente, pero existen algunas diferencias, como cómo lidiar con las excepciones de datos distribuidos, cómo lograr la serialización bajo una arquitectura distribuida y cómo hacerlo. Compromiso atómico entre nodos, cómo hacer un buen trabajo respondiendo a transacciones con particiones de red o alta latencia, etc.
El framework 3TS es un entorno distribuido, estos contenidos serán implementados y verificados en 3TS.
5. Algoritmo de control de acceso concurrente proporcionado por 3TS
Actualmente, hay trece algoritmos de control simultáneos integrados en 3TS, que incluyen principalmente:
(1) Acuerdo de bloqueo de dos etapas (2PL: No-Wait, Wait-Die)
(2) Protocolo de secuenciación de sello de tiempo (T / O)
(3) Protocolo de control de concurrencia de múltiples versiones (MVCC)
(4) Protocolo de control de concurrencia optimista (OCC, FOCC, BOCC)
(5) Protocolo de control de concurrencia optimista optimizado (MaaT, Sundial, Silo)
(6) Protocolo de control de concurrencia determinista (Calvin)
(7) Protocolo de control de simultaneidad basado en aislamiento de instantáneas (SSI, WSI)
La siguiente es una breve introducción a estos protocolos de control de simultaneidad a su vez:
5.1 Acuerdo de cierre de dos fases (2PL)
El bloqueo de dos fases (2PL) es actualmente el protocolo de control de concurrencia más utilizado. 2PL se basa en adquirir bloqueos compartidos o bloqueos exclusivos cuando se producen operaciones de lectura y escritura para sincronizar operaciones en conflicto entre transacciones. De acuerdo con la descripción de Bernstein y Goodman [2], 2PL tiene las siguientes dos reglas para la adquisición de bloqueos: 1) No puede haber dos bloqueos en conflicto en el mismo elemento de datos al mismo tiempo; 2) Después de que una transacción libera cualquier bloqueo, No se pueden adquirir más cerraduras. La segunda regla estipula que la operación de bloqueo en una transacción se divide en dos fases: la fase de crecimiento y la fase de reducción. En la fase de crecimiento, la transacción adquirirá bloqueos para todos los registros a los que necesita acceder. Las operaciones de lectura adquieren bloqueos compartidos y las operaciones de escritura adquieren bloqueos de exclusión mutua. Los bloqueos compartidos no son conflictivos y los bloqueos mutex entran en conflicto con los bloqueos compartidos u otros bloqueos mutex. Una vez que una transacción libera cualquiera de los bloqueos, la transacción entra en la segunda fase de 2PL, que se denomina fase de decaimiento. Después de ingresar a esta etapa, la transacción no puede adquirir un nuevo bloqueo.
3TS implementa el protocolo Strict 2PL (Strict 2PL) que no libera el bloqueo hasta que la transacción se confirma o finaliza. Según los diferentes métodos para evitar el interbloqueo, el 2PL implementado en 3TS incluye dos tipos: 2PL (No-Wait) y 2PL (Wait-Die), y su implementación sigue la descripción de estos dos protocolos en [2,3]:
5.1.1 2PL （Sin espera）
El acuerdo estipula que cuando se encuentra un conflicto de bloqueo cuando una transacción intenta bloquearse, se revierte la transacción que actualmente solicita el bloqueo. Los bloqueos retenidos por la transacción revertida se liberarán, lo que permitirá que otras transacciones adquieran el bloqueo. El mecanismo No_Wait puede evitar un punto muerto, porque la espera entre transacciones no formará un bucle. Sin embargo, no todos los conflictos de bloqueo causarán un interbloqueo, por lo que la tasa de reversión puede ser mayor.
5.1.2 2PL （Esperar-morir）
Rosenkrantz [3] propuso 2PL (Wait-Die), utilizando la marca de tiempo de inicio de la transacción como prioridad para garantizar que la relación de espera de bloqueo sea coherente con la secuencia de marca de tiempo. Siempre que la marca de tiempo de la transacción sea más pequeña (más antigua) que cualquier transacción que actualmente tenga el bloqueo, la transacción actual debe esperar; de lo contrario, la transacción actual debe revertirse. Para dos transacciones en conflicto, Ti y Tj, el protocolo usa la prioridad de marca de tiempo para decidir si dejar que Ti espere a Tj. Si Ti tiene una prioridad más baja (la marca de tiempo es más pequeña), entonces Ti debe esperar; de lo contrario, Ti retrocede. Por lo tanto, el gráfico de espera de bloqueo no formará un bucle y este método puede evitar que se produzca un punto muerto. Este algoritmo es una fusión de la tecnología TO y Locking.
Sin embargo, el mecanismo de procesamiento de transacciones distribuidas implementado por el principio de 2PL evita el interbloqueo (alta tasa de retroceso) o necesita resolver el problema del interbloqueo (interbloqueo de recursos y de comunicación). El costo de resolver los puntos muertos en un sistema distribuido será muy alto (el costo de resolver los puntos muertos en un sistema de una sola máquina ya es muy alto, y los sistemas de bases de datos modernos basados en arquitecturas multiproceso o multiproceso pueden hacer que el sistema casi detenga el servicio. En MySQL 5.6 y 5.7, el mismo elemento de datos se actualiza al mismo tiempo y la operación de detección de interbloqueo hará que el sistema casi detenga el servicio).
No solo la detección de interbloqueo consume enormes recursos, sino que también se han criticado las desventajas del mecanismo de bloqueo en sí. Literature [5] cree que las desventajas del mecanismo de bloqueo son las siguientes (una comprensión clara de estas desventajas llevó al autor de Literature [5] a diseñar OCC, Optimistic Concurrency Control y Optimistic concurrente control de acceso):
1. El mecanismo de bloqueo es costoso: para garantizar la serialización, el protocolo de bloqueo requiere transacciones de solo lectura que no cambian las restricciones de integridad de la base de datos y requiere operaciones de escritura simultáneas con bloqueos de lectura y exclusión mutua para evitar que otros los modifiquen; para aquellos que pueden causar interbloqueos El protocolo de bloqueo también debe soportar la sobrecarga causada por mecanismos como la prevención / detección de interbloqueo.
2. Mecanismo de bloqueo complejo: para evitar interbloqueos, es necesario personalizar varios protocolos de bloqueo complejos (como cuándo bloquear, cuándo se puede liberar el bloqueo, cómo garantizar el rigor, etc.).
3. Reducir el rendimiento simultáneo del sistema:
a) Mantener un bloqueo en una transacción esperando una operación de E / S reducirá en gran medida el rendimiento concurrente general del sistema.
b) Antes de que se complete la reversión de la transacción, el bloqueo debe mantenerse cuando la transacción bloqueada se revierte hasta que finalice la reversión de la transacción, lo que también reducirá el rendimiento concurrente general del sistema.
Además, el uso del mecanismo de bloqueo para operaciones de exclusión mutua, para el sistema operativo, provocará operaciones en modo kernel que consumen mucho tiempo y hará que el mecanismo de bloqueo sea ineficaz. Esto significa que la tecnología 2PL con semántica de transacciones basada en el mecanismo de bloqueo del sistema operativo es aún más inutilizable (pero también hay algunas tecnologías que mejoran constantemente el algoritmo de control de acceso concurrente basado en el protocolo de bloqueo).
5.2 Protocolo de clasificación de marcas de tiempo (T / O)
El Protocolo de ordenación de marcas de tiempo (TimestampOrdering, T / O) asigna marcas de tiempo a las transacciones al comienzo de la transacción y ordena las transacciones en el orden de la marca de tiempo [2]. Cuando la ejecución de una operación viola el orden que se ha especificado entre transacciones, la transacción en la que se encuentra la operación actual se revertirá o entrará en un estado de espera.
La implementación del algoritmo T / O en 3TS sigue la descripción en la sección 4.1 en [2]. Puede consultar este documento para obtener más detalles. La siguiente figura muestra la implementación de un algoritmo básico de T / O.
Figura 4 Algoritmo T / O
5.3 Protocolo de control de concurrencia de múltiples versiones (MVCC)
El control de concurrencia de múltiples versiones (MVCC) es una tecnología de control de acceso concurrente comúnmente utilizada en los sistemas de administración de bases de datos actuales. Fue propuesta por primera vez en 1978 por David Patrick Reed [4]. La idea principal es combinar un elemento de datos lógicos Expansión a múltiples versiones físicas, la operación de transacción en elementos de datos se convierte en operación de versión, lo que mejora la concurrencia del procesamiento de transacciones y puede proporcionar la capacidad de leer y escribir sin bloquearse entre sí.
Control de acceso concurrente de múltiples versiones, tecnología de control de acceso concurrente de múltiples versiones, conocida como tecnología MVCC.
En 1970, se propuso la tecnología MVCC. En 1978, se describió con más detalle "Nomenclatura y sincronización en un sistema informático descentralizado". Más tarde, en 1981, el documento [16] describió la tecnología MVCC en detalle, pero la tecnología MVCC descrita se basó en la marca de tiempo. .
T / O de múltiples versiones
： Para la hronización de sincronización rw, el programador T / Os básico puede mejorarse utilizando elementos de datos de múltiples versiones [REED78]. Para cada elemento de datos x hay un conjunto de pares de R-ts y un conjunto de (W-ts, valor), llamados versiones. Los Rts de x registran las marcas de tiempo de todas las operaciones dm-read (x) ejecutadas, y las versiones registran las marcas de tiempo y los valores de todas las operaciones dm-write (x) ejecutadas. (En la práctica, no se pueden almacenar R-ts y versiones para siempre; las técnicas para eliminar versiones antiguas y marcas de tiempo se describen en las Secciones 4.5 y 5.2.2.)Después de eso, la tecnología MVCC se utilizó ampliamente y se derivaron muchas versiones.
En 2008, se publicó literatura [13] y se propuso la tecnología "Aislamiento de instantánea serializable" para lograr un nivel de aislamiento serializable basado en MVCC. Esto hace que PostgreSQL V9.1 use esta tecnología para lograr un nivel de aislamiento serializable.
En 2012, se publicó literatura [14] y se propuso la tecnología "Write-snapshotIsolation" para realizar el nivel de aislamiento serializable basado en MVCC mediante la verificación de conflictos de lectura-escritura. En comparación con el método de detección de conflictos de escritura-escritura, mejora la concurrencia (algún tipo de conflicto de escritura-escritura). Los conflictos son serializables). El autor de este artículo realizó una implementación de sistema basada en HBase.
En 2012, la literatura [17] implementó la tecnología SSI en PostgreSQL. Este documento no solo describe la base teórica de las instantáneas serializadas, la implementación de PostgreSQL de la tecnología SSI, sino que también propone "Instantáneas seguras" y "Transacciones defendibles" para admitir transacciones de solo lectura, porque evita conflictos de lectura y escritura que causan devoluciones de transacciones. El impacto de la reversión es adoptar una estrategia de "reintento seguro" para la transacción que se retrotrae, y el impacto de la confirmación en dos fases sobre el impacto de seleccionar una transacción de conflicto de lectura-escritura de reversión.
La literatura [19] discutió sistemáticamente los cuatro aspectos de la tecnología MVCC, a saber: protocolo de control de acceso concurrente, almacenamiento de múltiples versiones, recolección de basura de versiones antiguas, administración de índices y discutió los principios de múltiples variantes de MVCC. Se probarán y evaluarán una variedad de variantes (MV2PL, MVOCC, MVTO, etc.) en la carga de trabajo OLTP. [18] discutió en detalle la versión antigua de recolección de basura MVCC.
En 3TS, MVCC se realiza basándose en la descripción de la Sección 4.3 en [2], combinado con el algoritmo T / O. Por lo tanto, la transacción aún usa la marca de tiempo de inicio para la clasificación.A diferencia del algoritmo tradicional de T / O, MVCC usa la característica de múltiples versiones para reducir la operación de espera en T / O. El mecanismo de ejecución de la operación en MVCC es el siguiente (use ts para representar la marca de tiempo de la transacción actual):
1. Leer operación
a) Si ts es mayor que la marca de tiempo de todas las transacciones en prereq, y hay una versión en writehis (la cadena de versiones del elemento de datos actual), y su wts es mayor que ts y menor que pts, se puede devolver la versión actual y la marca de tiempo de la transacción actual Deposita para readhis. Si no hay una marca de tiempo correspondiente para writehis, la marca de tiempo de la transacción actual se almacena en readreq. Las principales razones son:
Si hay una escritura comprometida entre la transacción de preescritura y la operación de lectura, significa que los datos leídos por la operación de lectura actual han sido escritos por la transacción de escritura, y se cumple el orden de marca de tiempo y la versión se puede leer;
La marca de tiempo de la operación de lectura es mayor que la marca de tiempo de la transacción de escritura sin terminar actual. Se deben leer los datos nuevos, así que espere;
b) De lo contrario, la operación de lectura actual lee la última versión visible a través de la marca de tiempo y almacena la marca de tiempo de la transacción actual en readreq;
2. Operación de escritura
a) Si ts es menor que la marca de tiempo de todas las transacciones en readhis, y hay una marca de tiempo en writehis entre rts y ts, los datos se pueden preescribir normalmente. Si no hay una versión elegible en writehis, se revierte la transacción actual;
b) Almacene temporalmente la operación de escritura actual en prereq_mvcc;
3. Enviar operación
a) Inserte la marca de tiempo de la transacción actual y la nueva versión escrita en writehis;
b) Eliminar la operación de escritura de la transacción actual de prereq;
c) Continuar ejecutando transacciones de lectura que cumplan con la secuencia de marca de tiempo en readreq;
Más algoritmos de control de acceso concurrente, continuarán ... ¡Estén atentos!
Gracias
Un agradecimiento especial al equipo de Tencent TDSQL y al Laboratorio Clave de Ingeniería de Datos e Ingeniería del Conocimiento del Ministerio de Educación de la Universidad Renmin de China por su apoyo y ayuda en este trabajo, y gracias a Zhao Zhanhao, Liu Chang, Zhao Hongyao y otros estudiantes por sus contribuciones a este artículo.
Referencia
[1] Rachael Harding, Dana Van Aken, Andrew Pavlo, Michael Stonebraker: Una evaluación del control de concurrencia distribuido. Proc. VLDB Endow. 10 (5): 553-564 (2017)
[2] Philip A. Bernstein, NathanGoodman: Control de concurrencia en sistemas de bases de datos distribuidas. Computación ACM. Surv.13 (2): 185-221 (1981)
[3] Daniel J. Rosenkrantz, Richard Edwin Stearns, Philip M. Lewis II: Control de concurrencia a nivel de sistema para sistemas de bases de datos distribuidas. ACM Trans.Database Syst. 3 (2): 178-198 (1978)
[4] DP Reed. Naming y sincronización en un sistema informático descentralizado. Tesis doctoral, Instituto Tecnológico de Massachusetts, Cambridge, MA, EE. UU., 1978.
[5] HT Kung, John T. Robinson: Sobre métodos optimistas para el control de concurrencia. ACM Trans. Sistema de base de datos 6 (2): 213-226 (1981)
[6] Theo Härder: Observaciones sobre esquemas optimistas de control de concurrencia. Inf. Syst. 9 (2): 111-120 (1984)
[7] Hatem A. Mahmoud, Vaibhav Arora, Faisal Nawab, Divyakant Agrawal, AmrEl Abbadi: MaaT: Coordinación eficaz y escalable de transacciones distribuidas en la nube. Proc. VLDB Endow. 7 (5): 329-340 (2014)
[8] Xiangyao Yu, Yu Xia, Andrew Pavlo, Daniel Sánchez, Larry Rudolph, Srinivas Devadas:
Reloj de sol: armonización del control de concurrencia y el almacenamiento en caché en un sistema de gestión de base de datos OLTP distribuido. Proc. VLDB Endow. 11 (10): 1289-1302 (2018)
[9] Stephen Tu, Wenting Zheng, Eddie Kohler, Barbara Liskov, Samuel Madden: Transacciones rápidas en bases de datos multinúcleo en memoria. SOSP 2013: 18-32
[10] Alexander Thomson, Thaddeus Diamond, Shu-Chun Weng, Kun Ren, PhilipShao, Daniel J. Abadi: Calvin: transacciones distribuidas rápidas para sistemas de base de datos particionados. Conferencia SIGMOD 2012: 1-12
[11] Hal Berenson, Philip A. Bernstein, Jim Gray, Jim Melton, Elizabeth J. O'Neil, Patrick E. O'Neil: una crítica de los niveles de aislamiento ANSI SQL. Conferencia SIGMOD 1995: 1-10
[12] Alan D. Fekete, Dimitrios Liarokapis, Elizabeth J. O'Neil, Patrick E.O'Neil, Dennis E. Shasha: Haciendo serializable el aislamiento de instantáneas. ACM Trans.Database Syst. 30 (2): 492-528 (2005)
[13] Michael J. Cahill, Uwe Röhm, Alan D. Fekete: Aislamiento serializable para bases de datos instantáneas. Conferencia SIGMOD 2008: 729-738
[14] Maysam Yabandeh, Daniel Gómez Ferro: Una crítica del aislamiento instantáneo. EuroSys 2012: 155-168
[15] https://en.wikipedia.org/wiki/Distributed_transaction
[16] P. Bernstein, V. Hadzilacos y N. Goodman. Control y recuperación de concurrencia en sistemas de bases de datos. Addison – Wesley, 1987.
[17] DR Ports y K. Grittner, “Aislamiento de instantáneas serializables en postgresql”, PVLDB, vol. 5, no. 12, págs. 1850–1861, 2012.
[18] J.Böttcher, et al., ScalableGarbage Collection for In-Memory MVCC Systems, en VLDB, 2019
[19] Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, Andrew Pavlo: una evaluación empírica del control de concurrencia de múltiples versiones en memoria. Proc. VLDBEndow. 10 (7): 781-792 (2017)
[20] D. Lomet y M. F. Mokbel, “Bloqueo de rangos de claves con servicios de transacciones desagregados”, VLDB, págs. 265–276, 2009.
[21] Jinwei Guo, PengCai, Jiahao Wang, Weining Qian, Aoying Zhou: Control de simultaneidad optimista adaptativo para cargas de trabajo heterogéneas. PVLDB 12 (5): 584-596 (2019)
[22] X. Yu, A. avlo, D. Sánchez y S. Devadas, “Tictoc: Control optimista de concurrencia en el tiempo”, en Proceedingsof SIGMOD, vol. 8, 2016, págs. 209–220.
[23] Rudolf Bayer, Klaus Elhardt, Johannes Heigert, Angelika Reiser: Asignación dinámica de marcas de tiempo para transacciones en sistemas de bases de datos. DDB 1982: 9-20
Se ha abierto el intercambio oficial de tecnología Tencent WeChat Group
Únase al grupo y agregue WeChat: journeylife1900
(Observaciones: Tencent Technology)