Desmitificación de la resolución de conflictos en Couchbase Mobile

Los conflictos pueden producirse en entornos de replicación en los que un documento puede ser actualizado simultáneamente por uno o más escritores. Esto es especialmente común en entornos móviles en los que las conexiones de red poco fiables pueden provocar que los cambios simultáneos de varios dispositivos no se sincronicen de manera oportuna, dando lugar a conflictos.

En este post, discutimos los fundamentos de cómo se manejan los conflictos en Couchbase Mobile y esbozamos el papel de las aplicaciones en la resolución de conflictos. En un próximo post, trataremos un tema relacionado con la gestión de árboles de revisión y tamaños de bases de datos en un sistema de gestión de documentos basado en revisiones.

El proceso de resolución de conflictos discutido en este blog se aplica a Couchbase Mobile 1.x. Por favor, echa un vistazo a este Correo electrónico: sobre los detalles del proceso automático de resolución de conflictos en Couchbase Mobile 2.x. Consulte nuestro documentación para una discusión sobre la resolución de conflictos personalizada en Couchbase Mobile 2.x.

La siguiente ilustración describe un escenario en el que pueden producirse conflictos en entornos móviles

Fondo

En Couchbase Móvil incluye la pila Couchbase Lite base de datos integrada que se ejecuta localmente en los dispositivos y Pasarela de sincronización en la nube que suele estar respaldada por Servidor Couchbase persistencia de los datos en la nube. La pasarela de sincronización se encarga de replicar los documentos entre los dispositivos. Es concebible que un documento pueda ser actualizado por varios dispositivos al mismo tiempo.

Control de concurrencia multiversión

Couchbase Mobile utiliza la técnica Multi Version Concurrency Control (MVCC) para manejar conflictos. En este método, a cada documento se le asigna un único ID de revisión generado por el sistema. Este ID es adicional al ID del documento, que permanece igual en todas las revisiones del documento. Cada cambio en un documento, ya sea una modificación o una eliminación, se trata como una nueva revisión del documento y, por lo tanto, se le asigna un nuevo ID de revisión.

Árbol de revisión

Cada vez que se va a realizar un cambio en un documento existente, el escritor debe incluir el ID de revisión de la revisión actual del documento que se está actualizando. Se crea una nueva revisión para el cambio y se añade como nodo hijo a la revisión actual que se estaba actualizando, dando lugar a un Árbol de Revisión para el documento.

Cada documento tiene asociado un árbol de revisión que crece a lo largo de la vida del documento. En una próxima entrada hablaremos de técnicas para gestionar el tamaño del árbol.

Estructura del documento

A un nivel muy alto, cada documento en Couchbase Mobile V1.4 se compone de un ID de documento, ID de revisión actual, cuerpo JSON y Metadatos. Los metadatos, entre otras cosas, contienen el historial de revisiones del documento. Los Metadatos son un concepto "entre bastidores", y las aplicaciones de usuario no deberían preocuparse por ellos. De hecho, en versión futura de Couchbase, los metadatos se moverán fuera del documento completamente y dentro de un XATTR.

Además, cada revisión de documento tiene asociado un valor TTL (que por defecto es de 5 minutos).

Revisiones de lápidas

En un sistema basado en MVCC, cada actualización, incluida una operación de borrado, crea una revisión del documento. Las revisiones borradas se denominan revisiones "Tombstone". Una revisión borrada es esencialmente una revisión especial que tiene la propiedad "_deleted" a true. Las revisiones de borrado se replican. Estas revisiones son especiales en el sentido de que si haces una consulta en Couchbase Lite, no serán devueltas.

Estructura del ID de revisión

Un ID de revisión tiene el formato "-"

•   ID de generación (nueva revisión) = ID de generación (padre de la revisión) + 1

La primera revisión que se crea cuando se crea un documento tiene un ID de generación de 1

• contenido hash ID =  hash calculado a partir del contenido de la revisión

Esto implica que dos revisiones de un documento con idéntico contenido tendrán el mismo ID hash de contenido.

Nota: Como optimización, si dos escritores hacen cambios idénticos a un documento simultáneamente, resultando en dos revisiones entrantes con el mismo ID de revisión, Couchbase Mobile sólo almacenará una única revisión.

 Conflictos

En un sistema basado en MVCC, se produce un conflicto si el sistema encuentra una bifurcación en el árbol. De la discusión sobre los árboles de revisión, se puede deducir que éste sería el caso cuando hay dos o más nodos hoja en el árbol.

Revisión actual

Cuando ocurre un conflicto, Couchbase Mobile aún necesita seleccionar un "ganador" o "Revisión Actual" entre los nodos hoja en conflicto. Elegir un ganador no implica que el conflicto esté resuelto.

Couchbase Mobile elige un ganador de forma determinista. Debido a la naturaleza determinista del proceso, no es necesario que los nodos de Couchbase Mobile se comuniquen entre sí para elegir a los ganadores: todos eligen al mismo utilizando los siguientes criterios

Caso 1 : Todas las revisiones de hojas no se borran

• La ganadora es la revisión no eliminada de la rama de revisión más larga.

Caso 2: Se suprimen todas las revisiones de las hojas

La ganadora es la revisión hoja eliminada en la rama de revisión más larga

Caso 3: Algunas revisiones de hojas se borran y otras no.

La ganadora es la revisión no eliminada de la rama de revisión más larga.

Caso 4: Hay empate

El ganador es aquel cuyo ID de revisión se ordena más alto en una simple comparación ASCII

Resolución de conflictos

¿Quién debe gestionar los conflictos?

Aunque Couchbase Mobile escoge una Revisión Actual entre las revisiones en conflicto, en última instancia es responsabilidad de la aplicación resolver los conflictos por las siguientes razones -

• La elección del ganador entre revisiones conflictivas puede basarse en criterios distintos a los que el Sistema utiliza para elegir un ganador de forma determinista. La revisión actual seleccionada por Couchbase puede no ser la elección correcta para la aplicación.
• No hay un claro ganador entre las resoluciones en conflicto. Así que, en este caso, puede ser necesario fusionar los cambios de las revisiones en conflicto. Los detalles de una fusión dependen de la semántica de la aplicación.
• Incluso si la aplicación decide ir con la revisión que Couchbase eligió como ganadora, recuerda que las revisiones en conflicto aún permanecen en la base de datos. Por lo tanto, la aplicación debe borrar las revisiones no ganadoras del árbol de revisiones para prevenir que el árbol de revisiones crezca mucho con revisiones conflictivas sin usar. Esto se discutirá en profundidad en un próximo post.

Opciones para resolver conflictos

Hay dos opciones para tratar los conflictos

Opción 1: Elegir una revisión entre revisiones contradictorias

En esta opción, una de las revisiones en conflicto como el ganador y "lápida" el resto.

La aplicación puede retener la "Revisión Actual" elegida por Couchbase como ganadora o puede elegir una revisión diferente entre las revisiones en conflicto. En cualquier caso, es importante borrar las revisiones no ganadoras para que puedan ser purgadas durante la compactación de la base de datos como se discute en la siguiente sección.

Opción 2: N-way-merge

En esta opción, los cambios de las revisiones en conflicto se fusionan según la semántica de la aplicación. Las fusiones van a una nueva revisión que se convierte en la revisión actual/ganadora. La rama no ganadora se elimina.

¿Y si no se resuelven los conflictos?

Si una aplicación decide ir con el ganador elegido por Couchbase Mobile y no resuelve explícitamente los conflictos, puede acabar con un árbol de revisión con un gran número de ramas y nodos hoja. Esto tendrá consecuencias indeseables en el tamaño del documento y, en consecuencia, en el tamaño de la base de datos. Couchbase Mobile tiene procesos automáticos para aliviar algo de esto, pero la aplicación es en última instancia responsable de asegurar que las revisiones de hoja no deseadas sean tombstoned.

Discutiremos los detalles de la gestión de la base de datos y del árbol de revisiones en un próximo post, así que permanezca atento.

¿Y ahora qué?

Este post fue una introducción al sistema de control de concurrencia en Couchbase Mobile. Una consideración importante en un sistema basado en MVCC es gestionar el tamaño de los árboles de revisión y evitar que se hinchen. Este aspecto será discutido en un próximo post.

Si tiene alguna pregunta o sugerencia, deje un comentario a continuación o póngase en contacto conmigo en Twitter @rajagp o envíeme un correo electrónico priya.rajagopal@couchbase.com. En Foros de Couchbase son otro buen lugar para plantear preguntas.

Por último, un rápido agradecimiento a Traun Leyden y Sachin Smotra por sus aportaciones a este post.