Muchos de nosotros estamos interesados por el Big Data, pero es necesario conocer un poco más a fondo aspectos teóricos para poder elegir la base de datos NoSql que mejor se adapta a nuestro proyecto, eso lo proporciona en gran medida el Teorema CAP.
Como lo vimos en el anterior post, existen muchas bases de datos NoSQl, que a su vez nos proveen distintas ventajas necesarias para implementar soluciones altamente distribuidas y escalables, las cuales dentro de sus características principales se encuentra el cumplimiento del Teorema CAP, el cual representa dentro del diseño de nuestra implementación un reto para definir que es lo más importante, si la Consistencia o la Disponibilidad.
Teorema CAP
El Teorema CAP aplica en ambientes altamente distribuidos, el primero en referenciarlo fue el profesor Eric A. Brewer, quien en el año 2000 en un simposio del ACM sobre los principios de la computación distribuida (PODC)…explicó que cuando se trata de diseño y despliegue de aplicaciones en entornos distribuidos solo podremos garantizar 2 de los siguientes 3 requerimientos:
The three requirements are: Consistency, Availability and Partition Tolerance, giving Brewer’s Theorem its other name – CAP.
2 años más tarde, fue comprobado y convertido en teorema, por lo cual, veamos a fondo cada uno de los requerimientos anteriormente mencionados:
Consistency (Consistencia)
Todos los nodos deben garantizar la misma información al mismo tiempo, si insertamos datos (todos los nodos deben insertar los mismos datos), si actualizamos datos (todos los nodos deben aplicar la misma actualización a todos los datos) y si consultamos datos (todos los nodos deben devolver los mismos datos).
Para tal efecto la comunicación entre los nodos debe ser de suma importancia, podríamos por ejemplo, emitir confirmación de inserción de un dato, una vez dicho dato se grabo en todos los nodos de nuestra réplica.
Availability (Disponibilidad)
Independientemente si uno de los nodos se ha caído o a dejado de emitir respuestas, el sistema debe seguir en funcionamiento y aceptar peticiones tanto de escritura como de lectura.
Una vez se pierde comunicación con un nodo, el sistema automáticamente debe tener la capacidad de seguir operando mientras éste se restablece y una vez lo hace, se debe sincronizar con los demás.
Partition Tolerance (Tolerancia al Particionado de Red)
El sistema debe estar disponible así existan problemas de comunicación entre los nodos, cortes de red que dificulten su comunicación o cualquier otro aspecto que genere su particionamiento.
Por lo general los ambientes distribuidos están divididos geográficamente, donde es normal que existan cortes de comunicación entre algunos nodos, por lo cual, el sistema debe permitir seguir funcionado aunque existan fallas que dividan el sistema.
A partir de lo anterior y dependiendo de lo definido en el proyecto, solo podemos garantizar 2 de los 3 aspectos mencionados anteriores. Siendo la disponibilidad desde mi punto de vista uno de los principales aspectos a tener en cuenta…pues debemos ser conscientes que en estos momentos son cada vez más impacientes nuestros clientes y menos susceptibles a esperar el restablecimiento del servicio (Aunque muchas veces se resuelvan los problemas en cuestión de segundos).
Veamos ahora los posibles escenarios o combinaciones permitidas para cumplir lo anterior.
Cuál escenario elegir?
Para tal efecto veamos un ejemplo: Supongamos que nuestra organización se dedica a la distribución de productos de aseo, somos una organización líder en el mercado y constantemente recibimos pedidos de todo tipo de sectores y todo tipo de cliente en nuestro país. Demandamos tantos pedidos que decidimos dividir y sectorizar nuestro país en 4 grandes Clúster principales y cada uno cuenta con 4 nodos en réplica, quienes se encargaran de tomar los pedidos y dar respuestas internas y externas.
Uno de nuestros clientes desea realizar un pedido por una cuantiosa suma de dinero, aportando un gran ingreso en el Sector A, pero uno de los nodos de la réplica del Sector A ha perdido comunicación con los demás…
Ahora veamos cómo aplicar nuestro ejemplo a cada posible escenario entregado por el Teorema:
1. CP (Consistency – Partition Tolerance)
El sistema siempre garantizará Consistencia aunque existan problemas de conexión entre los nodos (Particiones de red) y no se asegura Disponibilidad.
Como toleramos particiones de red, nuestro sistema recibe la petición, pero como además priorizamos consistencia, es necesario que el pedido se aplique y confirme en todos los nodos, como uno de ellos no está disponible…el pedido no se puede realizar.
2. AP (Availability – Partition Tolerance)
El sistema siempre estará Disponible aunque existan problemas de conexión entre los nodos (Particiones de red). Aunque pueda mostrar datos temporalmente Inconsistentes.
Siguiendo con el ejemplo, aquí toleramos particiones de red igualmente por lo cual el sistema recibe y aplica la petición, como no garantizamos consistencia, no es necesario que se confirme el pedido en todos los nodos.
3. CA (Consistency – Availability)
El sistema siempre estará Disponible con información Consistente. Por lo cual el sistema no soporta perdida de comunicación entre los nodos (Particiones de red).
En este caso como no soportamos particionamiento, el sistema debería fallar y presentar un mensaje a nuestro cliente de “Inténtalo más tarde por favor”, puesto que prácticamente no estaríamos garantizando ningún tipo de consistencia.
Si por el contrario no existiera particionamiento, aplicaríamos todas las peticiones y garantizábamos consistencia confirmando cada petición en todas las réplicas, debido a que estamos en un ambiente distribuido es poco probable que se dé el escenario ideal donde nunca se creen particiones de red.
Igualmente vemos con lo anterior que es necesario priorizar en la disponibilidad, personalmente no utilizaría el escenario CA pues prácticamente quedaríamos fuera de servicio total, lo que causaría miles de llamadas para reportar errores, quejas o incluso perdidas de clientes.
Como acabamos de ver, es sumamente importante definir desde el principio como desea disponer de la información el cliente, en algunos casos podríamos combinar distintas bases NoSQL que nos permita cubrir ciertas necesidades presentadas anteriormente, todo es un juego de análisis y dimensionalidad de nuestro proyecto, para tal efecto y mayor guía, veamos una clasificación de las distintas Bases de datos, donde claramente veras como una buena elección y combinación de bases te puede ser de gran ayuda.
Que te pareció el Teorema CAP? Que piensas respecto a la teoría y a la práctica del teorema? Alguna experimentaste la necesidad de elegir alguna opción del Teorema CAP?