La tercera generación de bases de datos distribuidas (3): diagrama de coherencia

Cuento corto: ¿Por qué esta imagen se llama "Imagen de coherencia de los ocho inmortales"?

Tabla consistente de ocho inmortales

Los llamados Ocho Inmortales cruzan el mar y cada uno muestra sus poderes mágicos. Esta es una de las características de esta imagen.

Durante mucho tiempo, la industria de las bases de datos ha estado esperando un conjunto de teorías o herramientas para probar y verificar la coherencia de la base de datos para comprender el grado de coherencia alcanzado por la base de datos de destino. Esta necesidad es muy urgente.

Cualquier sistema de base de datos carece de métodos y herramientas sistemáticos de verificación de coherencia, lo que resulta en que ningún sistema de base de datos pueda determinar cuál es su propio nivel de coherencia.

Aunque Oracle puede establecer el nivel de aislamiento serializable, no se ha probado en el largo proceso de tiempo y las generaciones posteriores descubrieron que su serialización solo es equivalente a la capacidad de aislamiento de SI, y se ha convertido en una situación de la que no todos se han reído ( impotente pero no puedo reírme de él), una broma que no se toma en serio (soportada y poco a poco ignorada y entumecida, no hay nada mejor que solo se puede soportar).

Cuando algo producido por uno mismo no puede ser explicado o implementado correctamente por uno mismo, ¿cuáles son los factores detrás de esto?

La llegada de la famosa herramienta Jespen parece haber salvado una gran cantidad de sistemas de bases de datos, muchos sistemas de bases de datos la utilizan para pruebas de coherencia, lo que ha mejorado la falta de métodos y herramientas de verificación de coherencia.

Sin embargo, como se menciona a continuación, Jespen también tiene muchas deficiencias (consulte la Tabla 1 de " Base de datos distribuida de tercera generación (1) - La era del fútbol ") y no puede evaluar bien la coherencia de la base de datos.

El "Cuadro de coherencia de los ocho inmortales" puede evaluar perfectamente varias bases de datos , de modo que la coherencia de varias bases de datos se pueda mostrar claramente frente al público. Los ocho inmortales de la base de datos están al frente, "demostrando plenamente" el poder mágico de la coherencia. (la comparación lo dejará más claro) Es útil).

La figura proporciona la siguiente información:

1. 1. Evaluar la capacidad de implementación de coherencia de cualquier sistema de base de datos (interfaz SQL o interfaz API).

La figura muestra los resultados de la evaluación de coherencia de 16 versiones de 11 bases de datos, incluidas bases de datos convencionales como Oracle, PostgreSQL, MySQL, etc. En la práctica, se han probado más sistemas de bases de datos, como la serie Pg nacional, la serie MySQL, etc. Los resultados de la evaluación son los mismos que los de sus versiones maestras, por lo que no figuran en la lista.

1. 2. Evaluar las capacidades de implementación correctas y los detalles de la coherencia de los datos en cada nivel de aislamiento. Los detalles de implementación y las diferencias para todos los niveles de aislamiento para cada base de datos probada se pueden ver de un vistazo.

2. 3. Sistema de evaluación, adecuado para sistemas de bases de datos transaccionales independientes y sistemas de bases de datos distribuidas. Siempre que proporcione capacidades de procesamiento de transacciones, se puede probar, incluidos Greenplum y MongoDB.

3. 4. Significado de la celda:

4. a) A con fondo amarillo: se produce inconsistencia en los datos.

5. b) Fondo verde P: No hay inconsistencia en los datos (se evita la inconsistencia)

6. c) Fondo azul R: sin inconsistencia de datos (las inconsistencias se revierten de acuerdo con ciertas reglas)

7. d) Fondo rojo D: No hay inconsistencia de datos (la inconsistencia se revierte mediante el método de detección de interbloqueo)

8. e) RU, lectura no confirmada; RC, lectura comprometida; RR, lectura repetible; SI, aislamiento de instantáneas; SER, serializable

Primero, desde la perspectiva de los niveles de aislamiento:

1. 1. En primer lugar, bajo el nivel de aislamiento RU, MySQL y SQL Server tienen la mayor cantidad de "fondo amarillo A", lo que indica que bajo el nivel de aislamiento RC, hay muchos problemas con la exactitud de los datos de estas dos bases de datos, pero esto no tiene Impacto, porque el desarrollo de aplicaciones generalmente se establece en el nivel de aislamiento RC. Aunque algunas bases de datos como PostgreSQL proporcionan configuraciones de nivel RU, su efecto real es equivalente a RC. No hay muchas "A de fondo amarillo" y básicamente cumplen con la definición de ANSI-SQL (pero ANSI-SQL solo define cuatro excepciones de datos).

2. 2. En segundo lugar, entre los niveles de aislamiento RC, SQL Server tiene la mayor cantidad de "fondo amarillo A", lo que indica que bajo el nivel de aislamiento RC, hay muchos problemas con la exactitud de los datos de estas dos bases de datos, mientras que Oracle, PostgreSQL, MySQL, TiDB y OceanBase tienen más problemas en el nivel de aislamiento RC. Son similares, pero hay más anomalías de datos que no se pueden eliminar. Estas anomalías de datos que no se pueden eliminar son mucho más que las dos escritura sucia y lectura sucia que solo se pueden eliminar en el nivel RC correspondiente al estándar ANSI-SQL.

3. 3. En tercer lugar, en el nivel de aislamiento RR, PostgreSQL tiene menos "fondo amarillo A" que MySQL, TiDB, OceanBase, etc., lo que indica que PostgreSQL tiene la mejor consistencia en este nivel, seguido de MySQL. Sin embargo, RR y SER de SQL Server tienen los mismos resultados, eliminando todas las anomalías de los datos.

4. 4. Cuarto, en comparación con SQL Server y MongoDB (indicado por SI en la figura) que proporcionan un nivel de aislamiento SI, en comparación con TiDB (indicado por Opt en la figura que usa bloqueo optimista) que proporciona bloqueo optimista para lograr un nivel de aislamiento SI similar Tienen las mismas capacidades de coherencia.

5. 5. En quinto lugar, las capacidades de coherencia de datos de bases de datos como MongoDB, OceanBase (versión compatible con MySQL) y TiDB que no pueden garantizar completamente la coherencia de los datos, es decir, no proporcionan el nivel SER, se detienen aquí. Se puede ver que en el RR A nivel, la coherencia de los datos aún es limitada y hay más "A de fondo amarillo".

6. 6. En sexto lugar, para las empresas que nominalmente proporcionan SER, como Oracle, Greenplum y OceanBase (versiones compatibles con Oracle), existen varios problemas de inconsistencia de datos en SER.

7. 7. En séptimo lugar, bajo el nivel de aislamiento serializable SER (excepto aquellos que no admiten SER), SQL Server, CockroachDB, PostgreSQL, MySQL, TDSQL y MyRocks pueden garantizar completamente la coherencia de los datos, sin embargo, del diagrama de coherencia podemos observar que estos Las bases de datos utilizan diferentes métodos para garantizar SER. Algunas son "R de fondo azul", por ejemplo, el algoritmo SSI utilizado por PostgreSQL revierte ciertas excepciones de datos (Write Skew, etc.), y otras son "D de fondo rojo". SQL Server y MySQL utilizan la detección de interbloqueos para revertir la desviación de escritura, etc. ——Este es un fenómeno interesante, con una profunda "visión" detrás, y se escribirá por separado en el futuro.

8. 8. De hecho, el nivel de aislamiento definido por el estándar ANSI-SQL es inútil.

En segundo lugar, desde la perspectiva de la misma base de datos:

1. 1. MongoDB y CockroachDB proporcionan un único nivel de aislamiento, especialmente CockroachDB, como base de datos distribuida, solo proporciona un nivel de aislamiento serializable (sus primeras versiones también proporcionaban un nivel de aislamiento SI, pero se eliminó en versiones posteriores). Esta es una elección muy correcta. La persona que determina su ruta técnica debe tener un conocimiento profundo de la esencia de las bases de datos distribuidas y las transacciones distribuidas. Vale la pena aprender esto de cualquier otra base de datos. No es necesario que las bases de datos distribuidas proporcionen niveles de aislamiento débiles . . Si una base de datos distribuida quiere afianzarse en el campo del procesamiento de transacciones, aprender el método de diseño de CockroachDB es la mejor opción. ——Este también es un fenómeno interesante, y la "visión" detrás de él también es muy profunda, y se discutirá en un artículo separado más adelante.

2. 2. PostgreSQL implementa el nivel de aislamiento serializable basado en el algoritmo SSI, eliminando los tres tipos de anomalías de datos: Write Skew, Write Skew Committed y Step IAT en el diagrama de consistencia (tenga en cuenta que SSI elimina más que solo Write Skew). Sin embargo, el algoritmo SSI es redundante para PostgreSQL; PostgreSQL ha invertido mucho esfuerzo en lograr la serialización pero ha realizado un trabajo redundante e inútil. Es una lástima que esto se deba a errores cognitivos de los desarrolladores del motor de base de datos. Demuestra efectivamente las limitaciones de Cognición del conocimiento empresarial tradicional. ——Este también es un fenómeno interesante, y la "visión" detrás de él también es muy profunda, y se discutirá en un artículo separado más adelante.

3. 3. El SER nominal de Greenplum es equivalente a la capacidad de nivel RR de PostgreSQL, sin embargo, como base de datos distribuida, el método de Greenplum para manejar la coherencia distribuida es diferente del de PostgreSQL independiente. El método utilizado por Greenplum para manejar la coherencia distribuida es bastante torpe e ineficiente, y hay un gran margen de mejora. ——Este también es un tema interesante: los "principios" detrás de él no son visibles en los libros de texto clásicos y se discutirán en un documento separado más adelante.

4. 4. OceanBase (versión compatible con Oracle) solo proporciona SER en nombre. Al igual que Greenplum, su SER es equivalente a sus capacidades de nivel RR. La primera versión de OB resolvió el problema del punto muerto distribuido mediante el mecanismo de tiempo de espera. En 2023, se publicó en ICDE un algoritmo de resolución de punto muerto distribuido, pero este algoritmo también se limita al algoritmo de resolución de punto muerto tradicional, por lo que existen algoritmos de resolución de punto muerto tradicionales. Existen ineficiencias. En realidad, esto es muy similar a Greenplum. ——Cómo resolver el problema del punto muerto de las bases de datos distribuidas es un tema central interesante e importante. El "principio" detrás de él no es visible en los libros de texto clásicos y se discutirá en un documento separado más adelante.

5. 5. En comparación con los productos de bases de datos anteriores, la capacidad de coherencia de TiDB es generalmente más débil. La capacidad de coherencia de su modo Opt es mejor que su nivel RR. Sin embargo, este producto de base de datos también tiene el problema de soluciones de punto muerto distribuidas ineficientes.

6. 6. Tanto SQL Server como MySQL tienen sólidas capacidades de coherencia y sus métodos para resolver anomalías de datos también son similares. Al comparar sus resultados para SER y RR, encontraremos que para la misma excepción de datos, como "Lectura sesgada", "Actualización perdida" y "Escritura-lectura sesgada", los dos niveles de aislamiento manejan la misma excepción, pero es diferente. En realidad, esto viola el principio de "implementación progresiva de niveles de aislamiento capa por capa", lo que indica que la implementación de su tecnología de procesamiento de transacciones se encuentra en un estado de caos y no se puede implementar en un plan unificado. Además, su capacidad detallada para garantizar la coherencia es más débil que la de PostgreSQL. ——La razón por la cual MySQL es débil en la implementación de coherencia implica muchos detalles, y esperamos una discusión por separado en el futuro. La teoría detrás del diagrama de coherencia puede proporcionar información sobre los detalles de la implementación de concurrencia de la base de datos y medir con precisión los pros y los contras de la capa de código concurrente.

7. 7. Entre las bases de datos nacionales, TDSQL tiene la capacidad de coherencia más sólida y, como producto distribuido, su capacidad de coherencia es relativamente rara. TDSQL tiene el alcance de aplicación más amplio en la industria financiera (TDSQL representa el 60% de los 10 principales bancos nacionales) y sus tecnologías centrales, como la coherencia, desempeñan un importante papel de apoyo en los negocios. Desafortunadamente, su algoritmo de implementación también adolece de poca eficiencia.

8. 8. Las capacidades de coherencia de algunos productos de otras marcas basadas en PostgreSQL son básicamente las mismas que las de PostgreSQL, y las capacidades de coherencia de algunos productos de otras marcas basadas en MySQL son básicamente las mismas que las de MySQL.

En tercer lugar, desde la perspectiva del usuario:

1. 1. Industrias como las finanzas, las telecomunicaciones y los valores tienen los requisitos más altos de coherencia de los datos y esperan que la base de datos no tenga anomalías en los datos. Este requisito es uno de los criterios básicos para seleccionar un sistema de base de datos transaccional. Por lo tanto, la capacidad de coherencia de una base de datos determina la precisión de sus datos y también afecta si puede ingresar al negocio principal de las finanzas y otras industrias. Los usuarios esperan un estándar de evaluación de coherencia objetivo que pueda verificar con precisión las capacidades de coherencia de la base de datos de destino. Esta expectativa ha cumplido sesenta años desde el nacimiento de la tecnología de procesamiento de transacciones. Una vida corta en el largo río de la historia, un grano de polvo, ¿cuántos sesenta años podemos esperar?

2. 2. Cada fabricante de bases de datos también espera probar y verificar la coherencia de la versión de la base de datos antes de su lanzamiento, pero desafortunadamente no ha existido un buen método. Por lo tanto, los fabricantes de bases de datos sólo pueden confiar en varios casos de prueba y conjuntos de errores acumulados a lo largo de los años como conjuntos de casos de prueba de regresión para verificar que "la nueva versión ya no tiene los errores de coherencia que se han descubierto" y si se descubrirán otros nuevos en el futuro Error de coherencia, me siento inseguro.

3. 3. Los investigadores de bases de datos siempre han esperado tener una metodología que pueda explicar de manera integral los métodos de verificación de consistencia a un nivel teórico. Pero desde que surgió la "teoría de la serialización" y desde que la "teoría de la serialización" se consideró la regla de oro, algunos de los primeros investigadores creyeron que la realización de la coherencia tiene una garantía teórica y no hay necesidad de preocuparse. es y otras cosas, entonces... Sin embargo, los investigadores no han pensado profundamente en: ¿cómo verificar la coherencia? ¿Por qué la teoría de la serialización no puede verificar la coherencia de la base de datos? ¿Existe alguna relación entre "métodos para garantizar la coherencia" y "métodos para verificar la coherencia"? ——Este es un tema muy importante e interesante, digno de una reflexión en profundidad y una discusión posterior en un artículo separado. Si una teoría está completa, ¿debería no sólo garantizar su corrección sino también verificarla?

4. 4. Con el Cuadro de los Ocho Inmortales de la Consistencia, de ahora en adelante, las capacidades de consistencia de la base de datos tendrán métodos y herramientas de evaluación verificados, y las capacidades de consistencia de cada base de datos mejorarán y superarán enormemente.

En la industria, existe una opinión generalmente reconocida: ¿ un nuevo producto de base de datos tardará al menos más de 10 años en madurar y estar disponible?

Entonces:

P1 : ¿Por qué el ciclo de desarrollo, pulido y promoción de un nuevo producto de base de datos lleva más de 10 años?

P2 : ¿Cómo se puede acelerar este proceso?

R : Estas dos preguntas pueden considerarse desde múltiples ángulos. Lo analizamos únicamente desde la perspectiva de la exactitud de los datos, porque este es el problema central más básico de la base de datos:

1. 1. Hay dos objetivos principales de una base de datos transaccional: en operaciones concurrentes, uno es garantizar la exactitud de los datos y el otro es lograr el mayor rendimiento posible.

2. 2. Para garantizar el objetivo central, se necesita un conjunto de teorías para demostrar la viabilidad del objetivo. Esta es la teoría de la serialización tradicional, pero esta teoría tiene dos deficiencias:

3. 2.1 Según la serialización y la serialización de conflictos, el nivel teórico no puede garantizar que los datos sean 100% correctos. Esto significa que falta algo a nivel teórico. --Las cuestiones importantes se discutirán en documentos separados. Quizás mucha gente diga: ¡Estás loco, te atreves a ser tan atrevido y decir tonterías sobre la regla de oro! cha~cha~cha

4. 2.2 Una teoría completa debe tener al menos dos puntos: corrección y métodos de verificación. Una teoría completa no sólo debe proporcionar explicaciones y predicciones correctas, sino también proporcionar métodos para verificar su exactitud. Estos dos aspectos a considerar son criterios importantes para evaluar si una teoría está completa. La teoría de la serialización carece de un método de verificación de coherencia para los productos de bases de datos desarrollados en base a ella, lo que constituye un defecto de la teoría y una de sus imperfecciones (aún existen algunas imperfecciones).

5. 2.3 Por lo tanto, en ausencia de teoría, no se puede verificar bien la exactitud del producto de base de datos. ¿Por qué hay alguna razón para lanzar este producto al mercado?

6. 3. Sin embargo, proveedores como Oracle han introducido productos inmaduros en el mercado de tres maneras:

7. 3.1 Definir el nivel de aislamiento: el estándar ANSI-SQL de 1992 "estandarizó" este problema. ¡Parece que este problema se ha convertido en algo "natural" en el contexto del nivel de aislamiento! Si las normas son así, ¿quién puede cuestionarlas? ¡La boca de Yunyun, bloquéala! ¡Bloquea los cerebros de todos los seres sintientes! --El nivel de aislamiento se puede definir de manera flexible y no debe limitarse al estándar ANSI-SQL (Referencia [1]), sino que puede ser diferente del estándar ANSI-SQL

8. 3.2 Para patear la pelota al usuario, se inventó el método "SELECCIONAR...PARA ACTUALIZAR" para responsabilizar al usuario de la coherencia de los datos. (Se adjunta una breve historia al final del artículo, que puede ilustrar la "contribución" de Oracle a este respecto desde la perspectiva del tiempo)

9. 3.3 Dado que la pelota ha sido pateada al usuario, significa que hay una gran cantidad de escenarios de prueba para verificar la exactitud de los datos. Una vez que se descubre un problema, se puede solucionar como un error. Este también es un método opcional en la práctica cuando no hay una solución a nivel teórico. Se dice que Write Skew y Read Skew propuestos por Jim Gray se propusieron después de que los usuarios encontraran inconsistencias en los datos en la práctica y después de mucho análisis y argumentación. Por lo tanto, al utilizar a los usuarios como conejillos de indias, cada producto de base de datos acumula errores en un ciclo a largo plazo de 10+ (lo que hace que los casos de prueba de regresión de los fabricantes mejoren gradualmente), el problema de coherencia se estabiliza gradualmente y el número de anomalías de datos reportadas en la práctica se vuelve cada vez menos, lo que hace que el producto de base de datos sea más utilizable. Sin embargo, también hace que el ciclo de madurez de un producto de base de datos sea extremadamente largo, más de 10 años, más de 20 años... Ni la teoría ni la práctica funcionan, los usuarios tienen que aguantar y el producto tiene que pulirse con el tiempo.

10. 3.4 Sin embargo, en los más de 30 años transcurridos desde la década de 1990 hasta la actualidad, se han reportado continuamente nuevas anomalías en los datos, lo que significa que todavía existen muchos riesgos para la exactitud de los datos (el creciente número de aplicaciones ha expuesto los riesgos de la exactitud de los datos (mayores posibilidades), lo que significa que la exactitud de la base de datos debe mejorarse por completo, tanto en la teoría como en la práctica del producto. Para obtener más información, consulte la literatura [1].

P3 : Entonces, ¿se puede acelerar la garantía de coherencia de la base de datos, como comprimir el ciclo de madurez de un producto a 2 años o incluso 1 año? Si es así, ¿cómo acelerarlo?

R: Todos podemos sentir una tendencia. En los últimos años, ha habido cada vez más productos de bases de datos nuevos, ¿verdad?

  El aumento sustancial de nuevas aplicaciones ha planteado nuevas y ricas demandas sobre las bases de datos. La evolución de los productos de bases de datos antiguos es demasiado onerosa y difícil de evolucionar. Estas nuevas circunstancias han provocado que surjan cada vez más bases de datos nuevas.

Sin embargo, a pesar del aumento de nuevos productos, todavía enfrentan el dilema de la dificultad para ingresar a las aplicaciones principales. Desde una perspectiva técnica, ¿a qué se debe esto?

Mientras se proporcione tecnología de procesamiento de transacciones "difícil y complicada", los nuevos productos de bases de datos enfrentarán el problema de cómo madurar y estabilizarse rápidamente, y cómo acelerar su introducción en el mercado. --¡Esta es la necesidad de los tiempos!

Un producto de base de datos, ya sea antiguo o nuevo, si no puede resolver completamente los problemas de coherencia más básicos para los usuarios desde los aspectos teóricos y prácticos, incluso si el producto se utiliza en varios entornos, en última instancia será difícil brindarles a los usuarios 100% de tranquilidad. mente.

   En respuesta a las necesidades de la época, surgió el Cuadro Consistente de los Ocho Inmortales y la tecnología detrás de él: esta tecnología comienza tanto en el nivel teórico como en el práctico.

Primero, las anomalías de los datos se pueden modelar de manera uniforme , incluidas todas las anomalías de los datos conocidas y desconocidas, y el problema de la exactitud de los datos se puede resolver desde un nivel teórico.

En segundo lugar, el cuadro de coherencia puede verificar completamente la exactitud de los datos de la base de datos . Esto permite que el nivel teórico posea las dos características más básicas (una teoría completa debe ser capaz de proporcionar explicaciones y predicciones correctas, y también proporcionar métodos para verificar su exactitud).

En tercer lugar, la tecnología de evaluación de coherencia detrás del gráfico de coherencia puede acelerar la verificación de la exactitud de los datos de la base de datos (en el nivel de minutos) , lo que acelera la madurez y estabilidad de los productos de bases de datos y acorta en gran medida el ciclo de lanzamiento del producto.

En el futuro, los productos de bases de datos que hayan sido evaluados y certificados por los Ocho Inmortales de la Consistencia establecerán una buena imagen de exactitud de los datos entre el público y ganarán su confianza. En la práctica, estará a la vuelta de la esquina acelerar los productos hacia aplicaciones centrales.

En la industria de las bases de datos, durante muchos años, ya sean los gigantes de la tecnología de bases de datos tradicionales, las bases de datos de código abierto o las bases de datos NewSQL recientemente desarrolladas, no han podido establecer sistemáticamente un sistema de verificación de regresión de coherencia. (Esto suena como algo muy increíble. En realidad, los proveedores de bases de datos no pueden hacer ese trabajo. Solo pueden construir casos de prueba individuales esporádicamente y ponerlos en casos de uso de regresión para verificar la coherencia; mientras se completan las pruebas, no hay una buena manera de evaluar la coherencia. de cada versión del sistema de base de datos]

Después de eso, nació un sistema muy conocido en la industria, que es el famoso Jepsen/Elle[2]. Este sistema es, con diferencia, la mejor herramienta de verificación de la coherencia de la base de datos. Aquí, no presentaremos las características de Jepsen/Elle, pero discutiremos las deficiencias de Jepsen/Elle.

Jepsen/Elle es valioso porque su principio se basa en gráficos de conflicto, que adopta el artículo de Adya (referencia "Definiciones de niveles de aislamiento generalizados"). Cuando Jepsen/Elle crea casos de prueba de coherencia, se basa en gráficos de conflictos. En la referencia anterior, Adya trata las excepciones de lectura sucia y de lectura intermedia como casos especiales y no las incluye en el sistema serializable de conflicto definido por él. Por lo tanto, la prueba de Jepsen/Elle para lecturas sucias y excepciones de lectura intermedia también se construye como un caso especial. .

En un gráfico de conflicto, el número de vértices y aristas en un gráfico de anillo dirigido puede ser mayor o menor, es decir, hay infinitos anillos, lo que lleva a Jepsen/Elle a construir teóricamente infinitos anillos. Sólo entonces podemos esperar Pruebe la mayoría de los anillos. Una vez probado con Jepsen/Elle, si desea probar todos los bucles, sólo puede dedicar una cantidad infinita de tiempo a ejecutar la herramienta. Obviamente, con recursos y tiempo limitados, no tendríamos la oportunidad de ejecutar la herramienta sin cesar para realizar pruebas. Por lo tanto, al probar una base de datos de destino, cada prueba está "incompleta", que es el problema más fatal de Jepsen/Elle. Las pruebas incompletas significan que las pruebas sólo pueden depender de la "suerte" y no se puede garantizar completamente la corrección .

Además, ¿bajo qué circunstancias se puede formar un "diagrama de anillos de conflicto"? Con unas pocas, docenas o incluso cientos de miles de transacciones simultáneas, ¿se puede construir un bucle con precisión? Si no conoce las reglas de composición de los anillos, ¿cómo puede construir suficientes anillos para cada prueba para verificar la exactitud y mejorar la eficiencia de la verificación y las pruebas? La teoría del grafo de conflicto no puede proporcionar apoyo teórico a Jepsen/Elle en este nivel, por lo que Jepsen/Elle construye casos de prueba con una característica: aleatoriedad . La construcción aleatoria de casos de prueba reduce en gran medida el propósito y la eficiencia de verificar la coherencia y, al mismo tiempo, cada prueba no puede "reproducir" fácilmente problemas descubiertos previamente (la incapacidad de reproducir problemas es uno de los tabúes en la construcción de casos de prueba) .

Por lo tanto, utilizar esta herramienta para la verificación en realidad no es confiable ni utilizable (cuando no hay una herramienta mejor, solo puede conformarse con la mejor opción).

Es posible que algunos estudiantes que tienen experiencia práctica con Jepsen/Elle no estén de acuerdo con esta conclusión, porque en el uso real, a veces se pueden encontrar algunos problemas (es decir, errores inconsistentes) con esta herramienta. Sin embargo, al analizar sus principios, sabemos que las capacidades de Jepsen/Elle, que representa el nivel más alto en la industria, se limitan a esto (lo incompleto y la aleatoriedad son dos inconvenientes importantes). Si utiliza Jepsen/Elle para descubrir que hay muchos problemas en un sistema, en realidad debería observar la calidad del diseño y la implementación del sistema (esto también ilustra la importancia de que el sistema de base de datos mencionado anteriormente requiera un sistema completo de verificación de regresión de coherencia, y También ilustra las limitaciones actuales de la teoría de la consistencia; además, lo que se discute aquí es la capacidad de prueba de la consistencia de las transacciones de Jepsen/Elle, no la capacidad de prueba de la inyección de fallas como una prueba de caos), en lugar de adorar a Jepsen/Elle como un Dios.

El siguiente contenido es proporcionado por ChatGPT, ¡léelo y ríete!

P (Pregunte a ChatGPT): Entre varios productos de bases de datos, ¿en qué producto apareció primero la sintaxis "SELECCIONAR...PARA ACTUALIZAR"? Proporcione el nombre de cada base de datos, el número de versión de la base de datos correspondiente y la hora en que apareció la sintaxis SQL.

R (respuesta de ChatGPT):

La sintaxis "SELECCIONAR...PARA ACTUALIZAR" se utiliza para bloquear filas seleccionadas en la base de datos para evitar que otras transacciones las modifiquen. Esta sintaxis apareció por primera vez en la base de datos Oracle.

La siguiente es la apariencia de la sintaxis "SELECCIONAR...PARA ACTUALIZAR" en algunos productos de bases de datos comunes:

1. Base de datos Oracle:

- Versión: Oráculo 6

- Fecha de aparición: 1988

2. Base de datos IBM DB2:

- Versión: DB2 2.3

- Fecha de aparición: 1989

3. Base de datos PostgreSQL:

- Versión: PostgreSQL 6.3

- Fecha de aparición: 1998

4. Base de datos MySQL:

- Versión: MySQL 3.23

- Fecha de aparición: 2001

5. Base de datos de Microsoft SQL Server:

- Versión: SQL Server 2005

- Fecha de aparición: 2005

Cabe señalar que diferentes productos de bases de datos pueden tener diferentes soportes y detalles de sintaxis para la sintaxis "SELECCIONAR...PARA ACTUALIZAR". Por lo tanto, consulte la documentación y las notas de la versión del producto de base de datos correspondiente cuando lo utilice.

Comentarios de Nahailanlan:

1. 1. El concepto básico de serialización apareció en la década de 1960 .

2. 2. Serializabilidad del conflicto, que surgió en los años 1970 .

3. 3. En las décadas siguientes, la teoría de la serializabilidad continuó desarrollándose sin llegar a concretarse. Entre ellos, el concepto de coherencia de datos ha estado en un estado de confusión y confusión, y la teoría está ausente.

4. 4. Oracle, el líder de las bases de datos, tomó la iniciativa en implementar la estrategia de "patear la pelota al usuario" en 1988 , y luego , a regañadientes, siguió con DB2 en 1989 y PostgreSQL en 1998 .

5. 5. El artículo de Adya "Definiciones de niveles de aislamiento generalizados" se publicó en 2000 y proporcionó una base teórica para Jespen. Desafortunadamente, como se menciona en 3, la falta de teoría genera fallas en las herramientas de prueba.

6. 6. Después de eso, MySQL en 2001 y SQL Server en 2005 siguieron su ejemplo a regañadientes.

Anteriormente hablamos de "garantía del 100% de corrección de los datos", entonces, ¿qué es la corrección de los datos? En el próximo artículo hablaremos de esto. Este contenido es algo teórico, pero comprender los conceptos básicos de esta serie de artículos también es una buena oportunidad para perfeccionar sus habilidades con las bases de datos.

[1] Li Haixiang, Li Xiaoyan, Liu Chang, Du Xiaoyong, Lu Wei, Pan Anqun. Definición sistemática y clasificación de anomalías de datos en sistemas de gestión de bases de datos. Journal of Software, 2022, 33(3): 0

[2] "Elle: Inferir anomalías de aislamiento a partir de observaciones experimentales",

1.  La tercera generación de bases de datos distribuidas (1): la era del fútbol

2.  La tercera generación de bases de datos distribuidas (2): la fuente de innovación