Gestión de tamaños de bases de datos en Couchbase Mobile y resolución de conflictos

Couchbase Mobile usa una técnica de Control de Concurrencia de Versiones Múltiples (MVCC) para manejar conflictos. Uno de los retos de un sistema basado en MVCC es que, con el tiempo, un documento puede llegar a tener múltiples revisiones. Se puede concluir que si todas las revisiones de los documentos se conservan indefinidamente, la base de datos puede llegar a ser muy grande. Esto no sería deseable.

Esta es la segunda parte de nuestra serie sobre Resolución de Conflictos en Couchbase Mobile. En nuestro primer post sobre Desmitificar la resolución de conflictosEn este post, echamos un vistazo entre bastidores a cómo se gestionan las revisiones y conflictos de documentos en Couchbase Mobile usando MVCC. En este post, vamos a discutir las técnicas utilizadas en Couchbase Mobile para gestionar el tamaño de los árboles de revisión de documentos y el papel de las aplicaciones en el mismo.

Fondo

La pila de Couchbase Mobile incluye 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.
Un documento en Couchbase Mobile está compuesto por un ID de documento, un ID de revisión actual, un cuerpo JSON y Metadatos. Los Metadatos, entre otras cosas, contienen el historial de revisiones del documento. En la versión de producción actual de Couchbase Mobile, los Metadatos se almacenan en una propiedad especial _sync incrustada en el documento. En V1.5 de Sync Gatewaylos metadatos se han trasladado del documento a los XATTR.
Este post asume que estás familiarizado con la estructura de árbol de revisión de documentos de Couchbase Mobile y los conceptos de revisiones actuales. Si quieres aprender más, por favor consulta el post sobre Desmitificar la resolución de conflictos.

Técnicas para gestionar el tamaño de la base de datos

Para evitar que los documentos sean demasiado grandes, Couchbase Mobile utiliza tres técnicas, a saber,
- Compactación
- Poda
- Caducidad del documento

Sync Gateway y Couchbase Lite manejan el proceso de limpieza de forma ligeramente diferente. Cuando proceda, las diferencias se indicarán en el post.

Compactación

La compactación se define como el proceso de purgar los cuerpos JSON de no foliar revisiones. Las revisiones de hojas no se purgan durante la compactación.

En Sync Gateway

En Sync Gateway, el sistema ejecuta la compactación periódicamente en segundo plano. Además, las aplicaciones pueden invocar manualmente el proceso de compactación mediante la función API compacta en la interfaz de administración

Sobre Couchbase Lite

En Couchbase Lite, la compactación sólo puede invocarse manualmente a través de la función API compacta En el objeto CBLDatabase

Impacto de la resolución de conflictos en la compactación

El proceso de compactación no elimina los cuerpos JSON de los nodos hoja. Así que si tienes un gran número de ramas conflictivas sin resolver, entonces tendrás un gran número de nodos hoja con cuerpos JSON por ahí.

• Caso 1: Cuando los conflictos no se resuelven, la compactación conserva los cuerpos JSON de todos los nodos hoja.

• Caso 2: Cuando se resuelven los conflictos (es decir, las ramas no ganadoras se tumban), la compactación elimina los cuerpos JSON de los nodos no hoja.

Por lo tanto, la resolución de conflictos es importante para garantizar que se eliminan todas las revisiones de hojas antiguas y no utilizadas.

Poda

La poda es el proceso que elimina los metadatos y/o los cuerpos JSON asociados a los archivos antiguos. no foliar revisiones. Las revisiones de las hojas no se ven afectadas. El proceso se ejecuta automáticamente cada vez que se añade una revisión. Aunque fundamentalmente es el mismo, el algoritmo de poda funciona de forma ligeramente diferente entre Sync Gateway y Couchbase Lite.

En Sync Gateway

Las "revisiones antiguas" son las que son más antiguas que el valor especificado por la opción límite_rev propiedad de configuración de la base de datos. La propiedad revs_limit está predeterminada en 1000, lo que significa que los metadatos correspondientes a las últimas 1000 revisiones se almacenan en Sync Gateway. Aunque el proceso de poda no elimina inmediatamente los cuerpos JSON de las revisiones antiguas, los cuerpos JSON de todas las revisiones de documentos que no sean hojas y que sean más antiguas que el valor TTL predeterminado de 5 minutos se limpian automáticamente mediante un proceso en segundo plano que se ejecuta periódicamente.

Algoritmo

1. Encontrar el número de generación mínimo gmin(el primer componente es un ID de revisión), de todas las revisiones hoja.
2. Elimina todas las revisiones no hoja cuyo número de generación g ≤ gmin - límite_rev

Poda de pasarelas de sincronización con conflictos : Un ejemplo

En este ejemplo:

• Supongamos que el límite_rev se establece en 2 (sólo con fines ilustrativos)
• el documento tiene revisiones conflictivas sin resolver en la generación 3

Sobre Couchbase Lite

"Revisiones antiguas" son las que son más antiguas que el valor especificado por maxRevTreeDepth de la base de datos. El valor maxRevTreeDepth por defecto es 20, lo que significa que los metadatos y los cuerpos JSON correspondientes a las últimas 20 revisiones se conservan en Couchbase Lite.

Básicamente, a diferencia del Sync Gateway, que toma una copia de seguridad temporal (TTL de 5 min) de los cuerpos JSON de las revisiones antiguas, el proceso de Pruning en Couchbase Lite elimina los metadatos así como los cuerpos JSON de las revisiones antiguas que no son hojas.
Cabe señalar que puede haber ligeras diferencias en la forma en que el algoritmo de poda se maneja a través de las distintas plataformas Couchbase Lite. Desde la perspectiva del usuario, debería ser suficiente notar que la técnica de Pruning en Couchbase Lite se deshará de metadatos y cuerpos JSON de revisiones antiguas basadas en el maxRevTreeDepth valor.

Algoritmo

1. Para cada rama no tombstoned en el árbol , podar revisiones cuya generación Id, g < (Profundidad De Rama - maxRevTreeDepth)

Tras la poda, su documento puede quedar con Sucursales desconectadas. El árbol de revisiones no está en un estado corrupto y la lógica que elige la revisión ganadora sigue aplicándose. Sin embargo, puede hacer que sea imposible hacer ciertas fusiones para resolver conflictos, y debe evitarse si eso es un problema para usted.

Poda de Couchbase Lite con conflictos : Un ejemplo

En este ejemplo:

• Supongamos que el maxRevTreeDepth se establece en 2 (de nuevo, nunca querrás hacerlo en la práctica)
• el documento tiene revisiones conflictivas sin resolver en la generación 3

Impacto de la resolución de conflictos en la poda

• El proceso de poda no elimina las revisiones de las hojas. Así que si tienes un gran número de ramas conflictivas sin resolver, entonces tendrás un gran número de nodos hoja por ahí.
• En la pasarela de sincronización, el algoritmo de poda se aplica a la rama más corta del árbol de revisiones. Esto significa que en el caso de que haya muchas ramas conflictivas sin resolver, es posible que la Poda no elimine algunas de las revisiones más antiguas.Considere el siguiente ejemplo,
  • Escenario 1 : Cuando los conflictos no están resueltos, la poda puede no eliminar todas las revisiones antiguas, ya que la rama más corta puede ser una rama conflictiva.

• 

• Escenario 2 : Sin embargo, en el caso de que se resuelvan los conflictos, gmin corresponde al nodo hoja de la rama de revisión ganadora.
  

  

• En la pasarela de sincronización, en caso de conflictos no resueltos, también es posible que los nodos padre de las revisiones en conflicto sean podados prematuramente. Esto daría lugar a un estado de rama desconectada, como se ha comentado anteriormente.

Caducidad del documento

Cuando los documentos caducan, se elimina del sistema todo rastro del documento, incluidas todas sus revisiones. Los usuarios tienen la opción de controlar cuándo caducan los documentos. Tenga en cuenta que los usuarios deben tener cuidado al cambiar el valor de caducidad de un documento, ya que éste puede caducar antes de tiempo. Esta función es útil para crear documentos efímeros que pueden ser necesarios sólo durante un breve periodo de tiempo.

En Sync Gateway

Al escribir un documento en Sync Gateway a través de PUT doc o documentos_a granel API, los usuarios pueden establecer el __exp en el cuerpo del documento para especificar cuándo debe caducar el documento.

Los formatos admitidos para el valor _exp incluyen:
- Número JSON. TTL en segundos cuando es menor de 30 días, tiempo unix cuando es mayor
- Cadena JSON (formato numérico) - igual que número JSON
- Cadena JSON (como fecha ISO-8601)
- JSON null. Establece la caducidad a cero (sin caducidad)

Sobre Couchbase Lite

En fecha de expiración de CBLDocument puede usarse para especificar cuándo debe expirar el documento. Ten en cuenta que al especificar un expirationDate manualmente, corres el riesgo de que caduquen documentos añadidos a Couchbase Lite en modo offline antes de que tengan la oportunidad de sincronizarse con el Sync Gateway.

Configuración de la profundidad máxima del Árbol de Revisión

Como se ha comentado en la sección sobre Poda, el maxRevTreeDepth en la base de datos Couchbase Lite es por defecto 20 y la propiedad límites_rev de Sync Gateway es, por defecto, 1000.
Este valor influye en el número de revisiones cuyos metadatos sobreviven al proceso de Poda. Por lo tanto, un valor muy alto implica que el historial de metadatos del documento puede llegar a ser muy grande, lo que aumentaría las necesidades de almacenamiento de la base de datos.
Se puede tener la tentación de reducir estos valores para ahorrar espacio. Pero hacerlos muy pequeños puede tener consecuencias indeseables como las que se exponen a continuación

- El nodo padre de las ramas en conflicto puede ser podado antes de que el conflicto pueda ser resuelto, lo que lleva a nodos hoja huérfanos. Esto puede ser indeseable si la aplicación desea fusionar n-way los cambios concurrentes. Si se llega a este estado, la única opción para resolver el conflicto es elegir una rama ganadora y tumbar todas las ramas conflictivas no ganadoras.
- Puede acabar con ramas desconectadas como se muestra en el ejemplo siguiente. Las ramas desconectadas son ramas que no tienen un antepasado común. Aunque puede no ser un gran problema en sí mismo, la aplicación es responsable de tombstoning ramas no ganadoras.
En el ejemplo siguiente , después de la sincronización, el dispositivo termina con dos ramas desconectadas [16..19] y [35..38] sin un ancestro común.

Tenga en cuenta que los escenarios anteriores también pueden ocurrir con los valores predeterminados de la propiedad de profundidad del árbol. Sin embargo, la probabilidad de llegar a este estado aumenta significativamente si los valores se establecen demasiado bajos.

¿Qué sigue?

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 post discute las técnicas disponibles en Couchbase Mobile para controlar el tamaño de los documentos y el impacto de la resolución de conflictos en el tamaño de la base de datos.
Si tiene alguna pregunta o sugerencia, deje un comentario a continuación o póngase en contacto conmigo a través de Twitter @rajagp o por correo electrónico. priya.rajagopal@couchbase.com. En Foros de Couchbase son otro buen lugar para plantear preguntas.

Por último, un agradecimiento a Traun Leyden Traun@couchbase.com del equipo de la pasarela Sync por su revisión en profundidad y a Jens Alfke jens@couchbase.com y Jim Borden jim.borden@couchbase.com del equipo de Couchbase Lite por su aportación.