Dado un sistema que proporciona:
- Control de simultaneidad optimizado / control de versiones por objeto (usando CAS - Check-and-Set)
- Transacciones que nunca necesitan abarcar más que un solo objeto.
- Aislamiento de instantáneas
¿Este sistema se considera serializable ?
Del aislamiento de instantáneas
En una anomalía de sesgo de escritura, dos transacciones (T1 y T2) leen simultáneamente un conjunto de datos superpuestos (p. Ej., Valores V1 y V2), realizan actualizaciones disjuntas (p. Ej., T1 actualizan V1, T2 actualizan V2) y finalmente confirman simultáneamente, sin haber visto La actualización realizada por el otro. Si el sistema fuera serializable, tal anomalía sería imposible, ya que T1 o T2 tendrían que ocurrir "primero" y ser visibles para el otro. Por el contrario, el aislamiento de instantáneas permite escribir anomalías asimétricas.
Como ejemplo concreto, imagine que V1 y V2 son dos saldos en poder de una sola persona, Phil. El banco permitirá que V1 o V2 tengan un déficit, siempre que el total retenido en ambos nunca sea negativo (es decir, V1 + V2 ≥ 0). Ambos saldos son actualmente de $ 100. Phil inicia dos transacciones simultáneamente, T1 retira $ 200 de V1 y T2 retira $ 200 de V2.
Según esto, parece que tener el potencial de sesgo de escritura es la única razón para un sistema que garantice que el aislamiento de instantáneas no sea serializable.
Sin embargo, en un sistema que no permite que una transacción abarque varios objetos (en el ejemplo anterior V1 y V2) parece imposible que ocurra un sesgo de escritura .
Por lo tanto, el sistema descrito anteriormente es serializable. ¿Es esto correcto?
fuente
Respuestas:
No, no creo que sus estipulaciones den como resultado un sistema que debamos considerar serializable.
El aislamiento de instantáneas es una técnica que garantiza que una transacción vea el mismo conjunto de datos en toda la transacción. El aislamiento de instantáneas proporciona algunas garantías, pero no define todas las características necesarias para comprender cómo funcionan realmente las transacciones (a menos que elijamos combinar el aislamiento de instantáneas y MVCC).
El aislamiento de instantáneas se implementa más comúnmente usando MVCC, Control de consistencia de múltiples versiones. MVCC define más detalles de las transacciones en el contexto de sus instantáneas: se dice que requieren aislamiento solo cuando se escriben conflictos (solo ubicaciones o ubicaciones + valores, dependiendo de la implementación). MVCC proporciona un modelo de consistencia relajado y sufre de sesgo de escritura.
Los modelos de consistencia relajada son difíciles de entender porque son como un híbrido entre no aislamiento y aislamiento total.
Entonces, comencemos primero con un modelo de concurrencia estricto. Dos transacciones deben aislarse entre sí si una escribe en cualquier información que la otra lea o escriba (y viceversa ...).
Cuando no sabemos por qué una transacción lee datos, debemos suponer que una lectura de valor diferente puede alterar el comportamiento del cliente involucrado, razón por la cual la condición de transacciones superpuestas indica aislamiento. Sin aislamiento, una lectura de datos obsoletos en una instantánea puede exhibir fácilmente una consistencia relajada, otro término para el cual es inconsistencia, es decir, error.
Solo necesitamos considerar los datos exactos leídos o escritos por las transacciones, cualquier dato fuera de ese conjunto no necesita ser considerado. Sin embargo, es fundamental darse cuenta de que cuando hablamos de datos leídos por una transacción, necesariamente debemos incluir todos y cada uno de los "meta" datos (y datos y metadatos leídos por meta operaciones tales como la verificación de restricciones). Ejemplos de metadatos son / meta operaciones son: identificación de una nueva clave primaria única; otro es la suma de una columna completa; otro es buscar algo y no encontrarlo; rango de búsquedas o sumas. Esto va al comentario de @ Matthew sobre la prevención de duplicados, así como a la respuesta de @Tersosauros, en la que considera el estado.
Por ejemplo, esto significa que dos transacciones se superponen (requieren aislamiento) cuando ambas insertan una fila (suponiendo una restricción de clave primaria única) porque verificar la restricción de clave es sinónimo de leer toda la columna de clave primaria. Como otro ejemplo, buscar algo y encontrarlo es como leer ese valor, sin embargo, no encontrarlo es como mirar cada valor en la columna.
MVCC protege solo contra escrituras superpuestas o en conflicto, pero no protege contra lecturas (a menos que también estén escritas por esa transacción). Por lo tanto, para obtener un error de coherencia en MVCC, todo lo que necesitamos hacer es leer algo que se cambia por otra transacción (donde la otra transacción ocurre después de que se obtiene la instantánea del primero, pero se confirma primero), mientras que la otra transacción continúa utilizando datos obsoletos y toma cualquier decisión de manera diferente en función de los datos obsoletos en comparación con lo que hubiera hecho con los datos actualizados. Es más fácil de causar de lo que piensas.
La consistencia relajada es otra forma de decir potencialmente inconsistente o propenso a errores. (La consistencia relajada no debe confundirse con la consistencia eventual, que es otra forma popular diferente de error propenso de "NoSQL").
En su pregunta, cuando dice que las transacciones nunca necesitan abarcar más de un objeto, esto debe aplicarse tanto a las lecturas y escrituras como a los metadatos (y meta operaciones), incluida la verificación de consistencia, agregados de columnas completas, verificaciones de ausencia, búsquedas de rango, etc. .: si es así, entonces hasta ahora todo bien.
Sin embargo...
Supongo que su pregunta es que está utilizando el aislamiento de instantáneas (MVCC) en objetos individuales (por ejemplo, en lugar de bloqueo de objetos). (También mencionas CAS; he oído hablar de comparar y cambiar, y de probar y configurar, pero no de verificar y configurar, aunque supongo que es similar).
Su pregunta escrita me sugiere que los "objetos" tienen más de un campo, de lo contrario las estipulaciones de la pregunta serían innecesarias.
Por lo tanto, debido a que sus objetos con instantáneas / MVCC tienen más de un campo, es propenso a escribir sesgo dentro de objetos individuales. Si dos transacciones actualizan el mismo objeto al mismo tiempo, uno puede leer un campo del valor del objeto que una otra transacción concurrente está en el mismo objeto y continuar sin saber, por lo tanto, una posible inconsistencia (también conocido como error).
En su lugar, podría usar el bloqueo de objetos, lo que evitaría que dos transacciones (para la actualización) incluso miraran el mismo objeto si otra transacción ya estaba en proceso de hacerlo.
Creo que se puede hacer una forma alternativa de aislamiento de instantáneas sin usar el modelo de comparación de conjunto de escritura roto de MVCC. Por lo tanto, puede (algorítmicamente) promover el conjunto de comparación de solo escritura para incluir también el conjunto de lectura. Luego, dos transacciones que actualicen el mismo objeto no podrían causar un sesgo de escritura (porque la que intenta confirmar más adelante se anularía). Creo que esta puede ser la solución adecuada al problema que está describiendo, porque ya está obteniendo la mayor parte del beneficio que MVCC nos compraría, al impedir las transacciones de objetos múltiples.
(Solo necesitamos considerar los elementos / campos exactos y específicos leídos o escritos, pero debemos incluir los leídos como metadatos, posiblemente durante las operaciones meta para evitar sesgos de escritura (es decir, error). Si eliminamos el conjunto de lectura del conjunto de comparación , o no consideramos los metadatos (potencialmente utilizados por las meta operaciones), entonces tenemos un modelo que permitirá el error).
fuente
Creo que, como dijo @ pjc50 , (énfasis agregado :) " si las transacciones se limitan a leer / escribir un solo objeto", entonces "la respuesta es sí". Sin embargo, creo que donde se cae esto es en la idea de un solo objeto.
En el ejemplo tomado del aislamiento de instantáneas , T1 y T2 no comparten ningún valor. Sin embargo, aún son potenciales para un sesgo de escritura porque " ninguno [ha visto] la actualización realizada por la otra fuente " . Por lo tanto, es la capacidad de una transacción para ver todas las demás actualizaciones antes de confirmar lo que hace que una transacción sea realmente serializable.
De serializabilidad :
Desafortunadamente, debido a esto (y como señala @Matthew Mark Miller ), también debemos considerar tanto el estado como los valores. Con esta consideración, dos transacciones que usan OCC tendrían el potencial de sesgar la escritura cada vez que se escribe cualquier estado de la base de datos .
fuente