El teorema CAP en base de datos

Éste post me parece muy importante para poder entender como funcionan y hacer grandes sistemas pensados para escalar, sea por tráfico, por multi-sitio, multi-país, y más… todos estos sistemas distribuidos presentan la misma particularidad, y en el año 2000 un señor llamado Eric Brewer, pudo definir tres importantes propiedades y desarrollo un teorema. El se dio cuenta que mientras más aplicaciones basadas en la WEB existan, menos debemos preocuparnos por la consistencia de los datos, si queremos alta disponibilidad de nuestras aplicaciones entonces no podemos garantizar la consistencia de los datos.

El teorema CAP, también llamado formalmente Teorema de Brewer, dice que un sistema de datos distribuido pude asegurar dos de estas tres propiedades: Consistencia, Disponibilidad y Tolerancia al particionado. Bien, que significa cada una:

  • La consistencia (Consistency), Todos los nodos deben ver los mismos datos al mismo tiempo, esto quiere decir que; cualquier cambios en los datos se debe aplicar en todos los nodos, y cuando se recupere el dato tiene que ser el mismo en todos los nodos. Esto se le llama consistencia atómica, y se consigue replicando la información en todos los nodos.
  • La disponibilidad (Availability), Cada petición en un nodo debe recibir y garantizar una confirmación si ha sido resuelta satisfactoriamente. En pocas palabras, se debe leer y escribir en todos los nodos.
  • La tolerancia al particionado (Partition Tolerance), El sistema debe funcionar a pesar de que haya sido dividido por un fallo de comunicación, garantizando la disponibilidad a pesar que un nodo se separe del grupo sin importar la causa.

CAPTheorem

El teorema solo nos puede garantizar las siguientes combinaciones:

  • CP (Consistency & Partition): El sistema aplicara los cambios de forma forma consistente y aunque se pierda la comunicación entre nodos ocacionando el particionado, no se asegura que haya disponibilidad.
  • AP (Availability & Partition): El sistema siempre estará disponible a las peticiones aunque se pierda la comunicación entre los nodos ocacionando el particionado, y en consecuencia por la perdida de comunicación existirá inconsistencia porque no todos los nodos serán iguales.
  • CA (Consistency & Availability): El sistema siempre estará disponible respondiendo las peticiones y los datos procesados serán consistentes. En este caso no se puede permitir el particionado.

La correcta decisión de que combinación necesitamos depende de nuestras necesidades de negocio. Nunca olvide que lo más importante en una base de datos relacional es la Consistencia. Conociendo el teorema CAP, nos puede ayudar aún más para saber que Sistemas de Base de Datos debemos escoger, si un SQL o un NoSQL. Si queremos profundizar más en el tema, recomiendo este post.

Arquitectura MVC

A continuación se realizara un pequeño resumen de las bondades en la implementación de la arquitectura MVC según mi experiencia, para explicar y ejemplificar ciertos aspectos en que consiste, será basado en un desarrollo de aplicaciones WEB con el lenguaje de programación PHP.

A medida que los desarrollos de software van creciendo, se hacen complejos por varios motivos; sean por la gran diversidad de tecnologías implementadas, larga vida del proyecto, los diversos aspectos que involucran el mantenimiento, y principalmente por su crecimiento en los cambios de los requerimientos, con todo esto surgió la necesidad de agilizar inteligentemente esta actividad con un mecanismo practico y robusto que pueda perdurar en el tiempo, sin generar un trauma al personal encargado.

El éxito de todo sistema se debe a uno de los aspectos mas importantes, que es la correcta implementación de una arquitectura de desarrollo, que permita una fácil y flexible expansión de sus requerimientos. Por ello surgió la arquitectura Modelo Vista Controlador (MVC), está trata de separar los componentes más esenciales de un software en tres capas.

Cada capa tiene un comportamiento único, donde se trata de aislar un segmento de código semejante, con el fin de puntualizar las actividades y hacer todo mas sencillo para los programadores, entre cada una de ellas existe un orden lógico de comunicación. La arquitectura de una aplicación se define en tres grandes capas:

  • Modelo: Contiene todas las consultas relacionadas a la Base de datos, solo suministra o recibe información directamente del Controlador o del Manejador de Base de Datos, representa toda la estructura de datos, no tiene noción de la existencia de la Vista.
  • Vista: Maneja todos los aspectos desde el punto de vista de interfaz de usuario, en poca palabras la salida y captura de información, interactua directamente con el Controlador. En esta capa se utiliza una diversidad de lenguajes como el XML, HTML, CSS, JavaScript y un minimo de PHP, lo esencial para imprimir contenido.
  • Controlador: Contiene toda la lógica de negocio, se convierte en un intermediario entre el Modelo y la Vista. Se involucra todo proceso que analiza la información para un determinado fin, por ejemplo: Validaciones, Condiciones, Generación de reportes, Prepara el contenido a mostrar en la Vista, etc…

Cuando se implementa la Programación Orientada a Objetos y esta arquitectura, se representar cada capa como una clase.

Las bondades que ofrece son varias:

  • Evita la inclusión de diversos tipos de códigos en un solo sitio, los separa según su lógica para facilitar el mantenimiento, por lo que se denomina aislamiento, de esta forma los cambios no son tan agresivos.
  • Incrementa la reutilización del código.
  • Promueve el desarrollo en equipo centrado en capas.
  • Incrementa la seguridad de la aplicación, siempre y cuando se validan los datos en cada capa.

En lo personal, este modelo simplifica mucho el trabajo diario, al principio puede costar un poco en entender exactamente toda la visión, pero es tan simple que uno se complica solo, en la practica se ira entendiendo cada vez mas sus bondades, la mejor forma de implementarlo es con el uso de un Framework.

Un framework de desarrollo que contemple esta arquitectura de forma nativa es Zend Framework, pero este es mi caso y lo recomiendo mucho. En el mercado existe muchos otros que lo implementan, situación que no está de mas investigar.

El uso de esta arquitectura y el apoyo del framework no es el todo para lograr con éxito el desarrollo de un sistema, pero abarca un gran porcentaje, no hay que desanimarse, la experiencia y la persistencia es la mejor herramienta.

Documentación, una diciplina

Mientras trabajamos durante un ciclo de desarrollo o la implementación de un proyecto determinado, situación que se nos presenta muchas veces, estamos en constante aprendizaje, buscando ayuda, nuevas técnicas, herramientas, comandos, etc., que mejora la calidad de nuestra labor.

Ya hoy en día es un hecho que el uso del Internet para buscar documentación de un problema determinado, se ha vuelto algo totalmente habitual, e inconscientemente se convierte en un habito, buscamos en Blogs, Documentación Oficial, Foros, Listas de Correos e inclusive chateamos para obtener una respuesta. Cuando finalmente la encontramos, aplicamos la solución, o en el peor de los casos, intentamos una y otra ves hasta dar con la solución, muchas veces todo este proceso a generado un gran consumo de tiempo, paciencia, dinero, molestias con los usuarios finales o con uno mismo, y cualquier otra variedad de situaciones, y ¿qué hacemos con toda esa información recolectada y comprobada?.

Para evitar desechar todo el trabajo, existe una solución bastante sencilla y practica que formaliza todo este proceso, es la implementación de una aplicación llamada MediaWiki, podemos ir incorporando información y completarla cada ves que sea necesario, ofreciendo un gran número de beneficios, se mencionan los más resaltantes:

  • Pueden participar de forma pública o privada los usuarios que aporten información.
  • El contenido se puede estructurar de forma jerárquica.

Posee una sintaxis peculiar para redactar el contenido, manteniendo uniformidad en el estilo, con una amplia variedad de elementos que son necesarios, como los son las tablas, listas, hipervínculos, imágenes, tabulaciones, etc. a pesar que todo esto pueda parecer complicado, presenta ventajas que son mas eficiente durante la escritura una ves que se domine.

  • Herramienta de búsqueda para todos los artículos.
  • Existe una gran variedad de complementos que se pueden incorporar para aumentar sus funcionalidad.

Una de las situaciones que se presentan cuando interactuamos por primera vez, es la de estar estar desconcertado por su sencilles, creemos que faltan cosas, y por ende es incompleto, dudando por completo de su poder, solamente tenemos que leer los tutoriales que ofrecen, y rápidamente nos vamos acostumbrando, convirtiendose en un visio para ir documentando todo.

Esta aplicación es totalmente factible para todo tipo de usuarios, podemos abarcar desde manuales de procedimientos complejos hasta simple tutoriales, eliminando el papel y aquellas copias cada vez que hay nuevas actualizaciones, como el proceso tedioso de distribución dentro de una organización, siempre esta a la mano y sus beneficios hablan por si solos.

¿Por qué usar un Framework?

Cuando desarrollamos un sistema orientado a la WEB para una empresa, tenemos que tener en cuenta varios aspectos importantes en todo momento, debe ser flexible, rápido, ordenado, y usar un estándar, esto ultimo es algo muy amplio, pero se tratará de resumir en varios puntos.

Debemos pensar en la utilización de un Framework, ya que engloba un gran numero de cosas buenas, crear uno nosotros tiene muchas desventajas que son importantes resaltar:

  • No tendremos el tiempo necesarios que amerita todas las tareas de su desarrollo.
  • No tenemos la experiencia a pesar que creemos tenerla.
  • No usaremos por completo las mejores practicas.
  • No será seguro porqué no ha sido lo suficientemente probado.
  • Estará en constante evolución y arriesga el producto final.
  • Nadie nos paga por el tiempo que no es apreciado por el usuario final.

Hay que tener en cuenta que un Framework no ofrece una solución a todo, mas bien, trata de solventar los problemas mas comunes y rutinarios, lo que no se contempla lo podemos crear nosotros en librerías o apoyarnos por productos de terceros.

Como estamos hablando de un producto orientado a la WEB, sabemos que todo sistema se compone principalmente de lo siguiente:

  • Arquitectura de Desarrollo MVC (Modelo, Vista, Controlador).
  • Autenticación de usuarios, niveles control de acceso, sesiones, cookies.
  • Estructura de Directorios y Archivos modulares.
  • Manejo de Peticiones y Respuestas, (POST, GET, WebServices).
  • Manejo de formularios y validación de datos.
  • Manejo de localidades y multi-idioma.
  • Funciones mas comunes para manejar Arreglos, Texto, Fechas, Correo, SOAP, etc…
  • Etc…

Todo lo planteado anteriormente justifica por si solo su uso, pero se presenta la siguiente interrogante ¿cuál necesitamos de tantos que existen en el mercado?, mi opinión recomienda mucho el uso de Zend, por varios motivos; Flexible, Facil, Ordenado, Desarrollado por la empresa oficial de PHP, su curva de aprendizaje es Baja, existen mucha documentación y comunidades activas que apoyan el movimiento, como dicen coloquialmente “tocar la puerta no es entrar”

Para finalizar, se a mencionado en varias oportunidades sobre el estándar, esto es algo que se aprecia mucho en la practica y se vuelve una necesidad para uno mismo cuando se trata de ser ordenado, y mas aún cuando se está trabajando en un equipo, si un entorno de trabajo se implementan soluciones exitosas, como por ejemplo; el uso de la arquitectura MVC, bajo una estructura modular de directorios y archivos, control de ejecución, uso de los patrones de la Programación Orientada a Objetos, con todo esto se obliga a que el proyecto se mantenga uniforme, bajo un mismo criterio, rechazando la libre lógica que es dañina a lo largo de la vida del proyecto, y solamente se concentra en lo medular.

Como dicen, no es necesario reinventar la rueda.