TEOREMA DE CAP EN BASES DE DATOS NOSQL

by CORNEJO PILLCO, Javier Jail 155193

Introducción:

El teorema de CAP de Brewer básicamente dice que un sistema distribuido solo puede
tener dos de las siguientes tres propiedades:

-Consistencia, es decir, cada nodo tiene los mismos datos

-Disponibilidad, es decir, un nodo siempre responderá consultas si es posible

- Tolerancia de partición, es decir, funciona a pesar de una falla en la red, por lo que los
nodos no pueden comunicarse entre sí

Entre las bases de datos NoSQL que se tomaran esta MongoDB, Redis, Riack, y Cassandra
las cuales tienen implementaciones en su configuración para el teorema CAP.

MongoDB (orientado a documentos) - CAP

Entonces, tomemos el teorema de la PAC para entender mejor a MongoDB. MongoDB

utiliza un esquema de replicación maestro / esclavo. Los datos se escriben en un nodo
maestro y luego se replican en los esclavos. Si se produce una falla en la red o si el maestro
está inactivo, un esclavo se hace cargo del nuevo maestro. Entonces, ¿cómo resuelve
MongoDB el problema relacionado con CAP? Hay ajustes que influyen en el
comportamiento mongos:

 Write Concern

Esta configuración te permite considerar cuando un intento de escritura tuvo éxito.

La configuración varía desde "error ignorado" hasta la configuración que define
cuántos nodos deben haber confirmado la operación de escritura.

Escribir concerns puede incluir los siguientes campos:

-La opción w para solicitar el reconocimiento de que la operación de escritura se ha

propagado a un número específico de instancias mongodb o a instancias mongodb
con etiquetas específicas.

-La opción j para solicitar el reconocimiento de que la operación de escritura se ha

completado en el registro en disco.
 -La opción wtimeout para especificar un límite de tiempo para evitar que las
operaciones de escritura se bloqueen indefinidamente.

 Read Preferences

Permite elegir si desea leer del maestro o también de los esclavos.

Entonces estas dos configuraciones te permiten tener la implementación de la teoría en la

forma siguiente:

- Al utilizar los problemas de escritura, puede imponer diferentes niveles de coherencia en

el clúster; puede elegir en cuántos nodos deben almacenarse los datos. Existe un
compromiso con la disponibilidad: la escritura fallará si el número de nodos en los que se
deben almacenar los datos es mayor que el número de nodos actualmente disponible.

-La preferencia de lectura se puede utilizar para elegir desde qué datos de nodo se deben
leer. Si decide leer los datos del maestro solo obtendrá los datos incluso si no se ha
propagado a todos los nodos.

-Al usar la configuración de escritura el comando “safe=> true” fuerza al disco a que emita
alerta de éxito si se procesó correctamente asegurando la configuración CP.

Redis (key-value) - CAP

Un esquema claro en bases de datos dentro de algún rango en el teorema son redes
distribuidas. En el caso de las tecnologías que se manejan en Redis son mas aplicables a
la consistencia. Pero existen configuraciones que minimizan los problemas de
consistencia y disponibilidad.

Redis Sentinel

Cuando descarga Redis, viene con un archivo de configuración para Sentinel, llamado
sentinel.conf. En la configuración inicial, solo se deben listar los nodos maestros. Todos los
esclavos se encuentran cuando Centinela comienza y pregunta a los maestros dónde están
sus esclavos. La configuración de Sentinel se volverá a escribir tan pronto como Sentinel
encuentre todos los esclavos disponibles o cuando se produzca una conmutación por error.

Redis Cluster

Riak (orientado a documentos) - CAP

Riak asegura la disponibilidad de los datos en caso de fallas en el sistema o en la red,

incluso cuando solo tiene la menor posibilidad de proporcionar una parte de los datos
disponibles, aunque partes del conjunto de datos completo podría faltar temporalmente.