Skip to content

Consistencia en CouchDB

by Cristian Requena on junio 1st, 2010

En el anterior artículo relacionado con CouchDB (http://www.nosql.es/blog/nosql/couchdb.html) se habló acerca de su control de múltiples versiones concurrentes, haciendo hincapié especialmente en el no-bloqueo de la lectura de los documentos pese a que estén en plena actualización.
En esta ocasión profundizaremos un poco más en la consistencia eventual que ofrece CouchDB y en cómo se resuelven los distintos conflictos que pueden aparecer. Aunque antes sería interesante echar un vistazo a la siguiente figura:

Fuente de la imagen
El Teorema del CAP (Consistencia, Disponibilidad “Availability” y Tolerancia a particiones “Partition Tolerance”) se refiere a que no es posible disponer en un mismo sistema distribuído de gestión de datos de estas tres características. Las RDBMS como Oracle, AS400 o SQLServer optaron en su día y siguen explotando a día de hoy el fragmento de máxima consistencia y resistencia a particiones, el algoritmo de Paxos busca la máxima consistencia y disponibilidad y, finalmente, las bases de datos NoSQL como CouchDB sacrifican la consistencia estricta en favor de la máxima disponibilidad y resistencia a particiones. Y es de esta característica de CouchDB, de la consistencia eventual, de lo que se hablará más adelante.

CouchDB identifica la versión de un documento mediante un contador incremental, por lo que sabe, en todo momento, si una actualización se está realizando sobre la última versión de un documento o no. De una forma análoga a la de sistemas de control de versiones del estilo de Subversion, CouchDB exige que una modificación (commit) se realice sobre la versión más reciente del documento; en caso contrario, hace falta hacer lo mismo que con Subversion: obtener la última versión del documento y fusionar los cambios localmente. De esta forma, CouchDB asegura la integridad de las actualizaciones de forma local, al contrario de lo que ocurre con las bases de datos relacionales, donde se pueden realizar updates en cualquier momento, sin conocer previamente el estado/versión del registro.

La consistencia eventual que se ha mencionado anteriormente se consigue mediante replicados incrementales, que son los procesos ejecutados periódicamente para comunicar cambios entre servidores. En este punto viene algo muy interesante de CouchDB y de su sistema de versionado: si se ha modificado un documento en dos nodos distintos de un cluster y se realiza el proceso de sincronización, ¿qué ocurre?

  1. Se marca el documento como “En conflicto”, de forma (otra vez) análoga a Subversion y otros sistemas de control de versiones.
  2. La versión más reciente (o la que tiene el contador de revisión más alto) se almacena como última revisión.
  3. La otra versión no se deshecha: se persiste como “penúltima” versión, para que permanezca en el histórico del documento y sea consultable en cualquier caso.

Este mecanismo de sincronismo que, a simple vista, es tan sencillo hace que CouchDB trabaje de forma transparente y consistentemente con distintos nodos, y, en definitiva, la hace escalable, que es de lo que se trata.

From → NoSQL

Leave a Reply

Note: XHTML is allowed. Your email address will never be published.

Subscribe to this comment feed via RSS