Propiedades ACID de Couchbase: Parte 1

La escalabilidad, el rendimiento y la flexibilidad han sido el objetivo principal de la plataforma de datos Couchbase, y las transacciones distribuidas y multidocumento suelen estar reñidas con estas características.

La primera parte de esta entrada de blog de dos partes va a cubrir los componentes básicos de ACID que son disponibles en Couchbase. Puedes usar estas "primitivas" sin sacrificar el escalado general, el rendimiento y la flexibilidad de Couchbase. Dependiendo de tu caso de uso, estas primitivas pueden ser adecuadas por sí solas, o en conjunto con otras.

Actualmente, Couchbase soporta muchas propiedades ACID en documentos individuales, pero no proporciona soporte para transacciones multi-documento. En la parte 2 de esta serie, mostraré un enfoque que utiliza estos bloques de construcción para hacer algo como una transacción multi-documento con Couchbase. Pero primero, es importante tener una comprensión completa de los bloques de construcción.

Las aplicaciones han evolucionado desde aplicaciones monolíticas hasta aplicaciones distribuidas basadas en microservicios. Los microservicios aún esperan ciertos aspectos de la transaccionalidad, como un commit atómico o un rollback, pero no necesariamente un comportamiento ACID completo. El comportamiento ACID completo puede seguir siendo importante, pero en el software web y móvil moderno, a menudo es menos prioritario que el rendimiento y la escalabilidad. Sin embargo, no es una situación de "o lo uno o lo otro". Couchbase proporciona algunas herramientas y capacidades para ayudarte a equilibrar las propiedades ACID y el rendimiento.

"Atomicidad" significa que un grupo de operaciones o todas tienen éxito o todas fallan. Couchbase proporciona atomicidad para documentos individuales. Una operación para obtener o establecer un documento tiene éxito o falla. Comparado con una garantía RDBMS de varios operaciones que triunfan o fracasan juntas, esto puede no parecer gran cosa.

Pero considera que modelado de datos es muy diferente entre las bases de datos documentales y las tecnologías de bases de datos relacionales.

En una base de datos relacional, normalmente normalizar los datos. Por ejemplo, para almacenar un carrito de la compra con 3 artículos, necesitarías:

Si desea crear un carro de la compra con 3 artículos, necesitará cuatro INSERTAR sentencias. Por lo tanto, puede que necesite que su base de datos relacional trate esas 4 sentencias atómicamente.

Consideremos ahora una base de datos de documentos. Se crearía un único documento JSON del carrito de la compra, que contendría 3 artículos.

Obtener o establecer este documento es una única operación atómica en Couchbase. Un modelo completamente normalizado no es necesario a menudo. Si ampliara este modelo para incluir la dirección, y mi dirección cambia un mes después de enviar un pedido, ¿cambia realmente el pedido al que se envió la dirección? La normalización pretende en parte reducir la duplicación de datos. Esto es lo correcto y eficiente en algunas situaciones, pero no en todas.

Si puede modelar sus datos de este modo, reducirá inmediatamente la necesidad de una transacción multioperación (si le preocupa que el tamaño del documento se dispare, no se preocupe, puede utilizar un archivo subdocumento o N1QL para operar sobre una parte del documento).

"Coherencia" significa en general que una operación "no violará las restricciones de integridad del sistema declaradas". Cualquier restricción en la base de datos sobre los datos permanece consistente antes y después de una operación ACID. Por ejemplo, si falla un conjunto atómico de operaciones, los datos siguen siendo coherentes con lo que eran antes de la operación (porque se puede volver atrás). Hay otros tipos de restricciones de consistencia que una base de datos puede imponer: en una base de datos relacional, por ejemplo, no se pueden insertar 6 columnas de datos en una tabla de 5 columnas.

En lugar de un esquema, Couchbase utiliza JSON. Cada documento contiene implícitamente su propio esquema. Si realizas una operación de inserción con JSON, debes suministrar JSON válido (los SDKs de Couchbase normalmente se encargan de esto por ti). Couchbase sólo impone esto a nivel de documento. Couchbase no puede evitar que uses un esquema JSON diferente de documento a documento. Por ejemplo, considera estos dos documentos:

Un cubo Couchbase permite ambos documentos. Tenga en cuenta que los nombres de los campos no son coherentes entre sí. Esto significa que hay más responsabilidad a nivel de aplicación para asegurar que los documentos tienen nombres consistentes (pero normalmente, esto se derivará de su modelo de datos, y por lo tanto se maneja automáticamente).

Otra restricción que impone Couchbase es la clave. Cada documento debe tener una clave única. Si intentas insertar otro documento con una clave de "user::mgroves", por ejemplo, se producirá un error. Por tanto, si necesita imponer una restricción única, una forma de conseguirlo es utilizar la clave del documento. (También es ventajoso utilizar una clave natural cuando sea posible para que un cluster de Couchbase pueda realizar una búsqueda directa).

"Aislamiento" es la capacidad de que una operación se produzca sólo después de que se haya completado otra operación sobre los mismos datos. De este modo, cada operación independiente de otras operaciones. Esto es muy importante cuando una base de datos gestiona el acceso concurrente a los datos. Debe aparece que la base de datos sólo gestione una operación a la vez. Para ello, los datos que se actualizan deben ser bloqueado de ser modificado (y/o visualizado) hasta que la operación haya finalizado.

Couchbase proporciona aislamiento de lectura comprometida por defecto en (de nuevo) el nivel de documento único.

Para conseguir un aislamiento más estricto, hay dos tipos de bloqueos que puedes hacer en Couchbase: bloqueo pesimista y bloqueo optimista.

"Durabilidad" significa tradicionalmente que cuando una operación se completa con éxito, que el disco almacena los cambios realizados por la operación. En una base de datos distribuida, la durabilidad puede significar que la disco y/o la memoria en otros nodos almacenar los cambios. La replicación a otros nodos es el mecanismo preferido para la durabilidad en Couchbase, ya que la red es mucho más rápida que el disco. En última instancia, para un desarrollador, significa que aunque se produzca un fallo en el sistema, el cambio sigue teniendo lugar.

Couchbase tiene una arquitectura "memory-first". Esto significa que los resultados de las operaciones de escritura se reconocen cuando se reciben en memoria, y luego se ponen en una cola para ser asíncronamente escritos en disco o replicados a otro nodo poco después. Por lo tanto, si una operación se escribe en memoria y el sistema se apaga inmediatamente, esa operación no es duradera. Este es el compromiso por defecto que hace Couchbase: velocidad sobre durabilidad.

Sin embargo, Couchbase permite anular esa configuración predeterminada y especificar un nivel de durabilidad más estricto con Requisitos de durabilidad. Esto alejará el péndulo del rendimiento y lo acercará a las propiedades ACID. La ventaja de este diseño es que el desarrollador de la aplicación sabe y decide cuándo es importante pagar el coste adicional.

El comportamiento por defecto es que escribir el documento en memoria se considera un éxito. Couchbase aún persistirá y replicará de acuerdo a la configuración de tu cluster de Couchbase, pero la llamada al método procederá después de que la operación sea reconocida.

Puedo especificar el número de nodos a los que replicar que considero una operación duradera con éxito utilizando ReplicateTo:

Y también puedo especificar una combinación de persistencia a otros nodos y replicación a otros nodos que considere "suficientemente" duradera utilizando PersistTo también:

Cada una de estas llamadas a métodos se bloqueará hasta que el Requisitos de durabilidad y permitirá que su aplicación realice una gestión de errores adicional.

Tenga en cuenta que si los requisitos de durabilidad fallaEntonces Couchbase todavía puede guardar el documento y eventualmente distribuirlo a través del cluster. Todo lo que sabemos es que no tuvo éxito hasta donde el SDK sabe. Puedes elegir actuar sobre esta información para introducir más propiedades ACID en tu aplicación.

Esta entrada del blog hablaba de las varias primitivas disponibles en Couchbase para construir garantías tipo ACID en tu aplicación. Aunque estas primitivas no satisfacen la definición completa de ACID, son suficientes para lo que la gran mayoría de aplicaciones modernas basadas en microservicios necesitan. Para el pequeño porcentaje de casos de uso que necesitan garantías transaccionales adicionales, Couchbase continuará innovando aún más.

En el próximo post, veremos técnicas y código de ejemplo que podrías aprovechar para construir una transacción multi-documento en Couchbase.

Si tiene alguna pregunta, no deje de consultar el Foros de Couchbase. Puede encontrar el mismo código utilizado en esta entrada del blog en Github.

Un agradecimiento especial a todos los coautores de esta entrada de blog: Shivani Gupta, Ravid Mayuram, John Liang, Chin Hong, Matt Ingenthron, Michael Nitschinger (y seguro que me faltan algunos más).