Bases de Datos: RDBMS vs No-SQL, una R-Evolución


Schweppes

Es realmente fascinante e interesante los nuevos pensamientos y soluciones para cubrir los actuales paradigmas ante la aparición de las nuevas necesidades que las actuales RDBMS no las satisfacen, a este nuevo concepto se le denomina NoSQL Not Only SQL y fue acuñado en el año 1998 para hacer referencia a una base de datos relacional de código abierto que no usaba el lenguaje de consultas SQL (Structured Query Language).

Veamos primero lo que nos plantea el modelo de Bases de Datos Relacionales para luego ver el porqué de los nuevos planteamientos hacia el movimiento NoSQL que son de lo más interesantes bajo mi punto de vista, pero además lo que me fascina es que forma parte de una nueva forma de pensar en el desarrollo de aplicaciones web orientadas y centradas en el usuario. Se diseñan proyectos pensando en el “usuario” y en “momentos“, en piezas de información que pueden tomar forma de texto y/o vídeo. Comenzamos.

En las Bases de Datos Relacionales, los datos se representan mediante tablas relacionadas entre sí, normalmente Normalizadas en primera, segunda o tercera forma normal, que en la mayoría de los casos vamos a necesitar unir varias tablas para conseguir el resultado buscado mediante el típico JOIN de SQL entre varias sentencias SELECT, lo cual esto genera un consumo de recursos y rendimiento de proceso, pero también dependerá mucho de otros factores que pueden hacerlo aumentar, un ejemplo el número de registros. Ahora podemos pensar que como solución, llegar a tener desnormalizadas las tablas y así evitar los JOINs teniendo los datos repetidos en varias tablas, pensando que podríamos llegar a optimizarlo, pero esto no entra en el modelo relacional como tal y no es muy recomendado hacerlo, por cuestiones de mantenimiento y coherencia de los datos, no es una solución pero se puede hacer claro. Por otro lado ayuda mucho para obtener rendimientos en la obtención de resultados, en el uso de SELECT/WHERE la creación de índices, hay diferencia sustancial entre crear índices y no tenerlos, sobre todo en la velocidad de procesamiento de obtención del resultado. Si vamos optimizando nuestros recursos y utilizamos una cache en memoria para almacenar los resultados de las consultas más comunes, esto podría aumentar la optimización de los recursos disponibles, ya que las lecturas, representan uno de los problemas a considerar en cuanto al posible volumen que pueden llegar a alcanzar, ya que como digo, normalmente son mucho mayores las Lecturas que las Escrituras. Uno de los más conocidos y más utilizados por Flickr o Facebook por poner un ejemplo de proyectos web, es MemCached, pero ¿Qué es Memcached ? pues primero decir que está desarrollo por Danga Interactive y podríamos definirlo como un “sistema distribuido para el cacheo de objetos en memoria, pensado para aumentar la velocidad de los proyectos web con accesos dinámicos para descargar el número de lecturas directos a la Base de Datos”.

Un momento, aunque no necesarioamente esté estrechamente relacionado entre transacciones ACID y las bases de datos tradicionales, veamos que significa ACID. La A (Atomic) de Atomicidad para que las transacciones se ejecuten correctamente o no pero en el caso de que haya fallos, debe completarse. La C (Consistency) de Consistencia que nos garantiza que cada vez que se hace un cambio de información, el nuevo valor se expande a todos aquellos que lo soliciten, pero además asegura que sólo se empieza aquello que se puede terminar. La I (Isolation) Aislamiento, asegurando que varias transacciones ejecutándose en paralelo se va a ver de la misma manera a como lo vería si se ejecutaran de forma secuencial o individual, evitando que una operación afecte al resto. La D (Durability) Durabilidad, asegura que el resultado de las transacciones es persistente, pero es que además, si una máquina se cae o se apaga, al volver de nuevo, el cambio producido por la transacción aun está, es decir, persiste.

También llegado a este punto aprovecho para comentar el concepto CAP, que viene a decir que dentro del mundo de la persistencia que tenemos que saber decidir muy bien para estar preparados para el impacto que tendrá nuestras decisiones y por supuesto en función a los requerimientos de nuestro proyecto. La toma de decisiones está relacionada en cuanto a la Consistencia (Consistency), a la Disponibilidad (Availability) y a la Tolerancia a Fallos (Partition Tolerance), hagamos algunas reflexiones para la toma de decisiones. Para una buena toma de decisiones en este sentido debemos considerar que sobre los 3 factores CAP, podemos valorar el sacrificar un % de consistencia en vez de toda la consistencia, esto quiere decir que el algún momento podemos no tener la consistencia, pero en un intervalo de tiempo determinado  la tendremos, también podemos valorar el sacrificar un % de disponibilidad, que en la práctica esto quiere decir el permitir que se degrade el tiempo de respuesta e incluso que algunos clientes puedan llegar a perder disponibilidad por un tiempo limitado pero hay que valorar el impacto de esta decisión, pero también entramos en que se puede valorar la toma de decisión de poder perder un % de tolerancia a fallos,  pero nunca por encima de un límite que hay de determinar y lo más importante es que nunca, cuidado con los pensamientos que a veces nos traicionan, podremos llegar a tener los 3 factores a la vez, únicamente 2 de ellos, veamos.

Supongamos que nuestro proyecto web queremos que tenga Tolerancia a Fallos, alta Consistencia y baja disponibilidad. ¿Cómo podemos conseguir la tolerancia a fallos en nuestro proyecto? pues en principio incorporando en nuestra arquitectura un determinado número de nodos o servidores de forma que si cae uno de ellos haya otro capaz de tomar el control del nodo caído. Esta escalabilidad puede ser escalabilidad vertical, escalar en elementos tales como CPU, RAM, disco, y esta escalabilidad como es lógico tiene un coste y aumenta exponencialmente pero finalmente es finita. Pero la escalabilidad horizontal se basa como decía en dispensar más servidores de forma paralela y tener la información distribuida.

Pues bien, llegados a este punto por si mismo no representa aún gran cosa como tal, con lo que por ahora vamos incorporando nodos y cuantos más nodos tengamos menos opciones de fallos generales tendremos, creo que no necesita mucha aclaración más en este aspecto. Sólo hemos incorporado un único elemento de los tres posibles, pero vamos a añadir a nuestro sistema la Consistencia, la información es muy crítica para nuestros usuarios, entonces debemos pensar que esto significa que como hemos añadido un número de nodos determinado a nuestro sistema para una buena tolerancia a fallos, ahora tenemos la obligación replicar en un principio los datos entre todos los nodos de nuestro sistema cada vez que hagamos una escritura, lógico no? pero como decía esto nos lleva que al escribir, todos los nodos deben tener la misma información para que un cuando un usuario lea la información sea la misma en cualquiera de los nodos de nuestro sistema, entonces esto nos implica que debemos esperar hasta que se termine la operación para poder darla por terminada y válida, de lo contrario tendríamos una inconsistencia en la información.

Por tanto el haber incorporado esta decisión al sistema de la Consistencia y Tolerancia a Fallos, nos encontramos con que tendremos que al tener que replicar en todos los nodos, el tiempo de respuesta y la disponibilidad de la información, no será demasiado optimo y ¿por qué digo esto? veamos, la cantidad de nodos en nuestra arquitectura hará que tengamos más o menos un tiempo de retraso sin cuantificarlo en este momento, también el hecho de que podamos tener fallos en el sistema, hay que tomarlo en cuenta, ya que esto hace que aumenten los tiempos un poco más debido a que tenemos que escribir en todos los nodos y tenemos que considerar la posibilidad de que alguno puede estar caído y sin determinar la cantidad de ellos, entonces para que la operación podamos darla por válida hemos dicho que se debe escribir en todos los nodos, pues bien esto implica que nos influye la cantidad de nodos de replicación ya que aumenta la probabilidad de fallar en la operación y por tanto nos afecta también a la disponibilidad. Resumiendo este apartado, lo que hemos hecho es que si nuestro proyecto necesita disponer de Tolerancia a Fallos y Consistencia en los datos, entonces perdemos en Disponibilidad.

Ahora bien, si queremos que nuestro proyecto disponga de una mayor Disponibilidad , esto nos lleva a que la operación de réplica de la información en los nodos de nuestro sistema debe terminar mucho más rápida que antes, y ¿cómo conseguimos esto?, pues la decisión implica que debemos sacrificar el número de réplicas a establecer en los nodos del sistema en un mismo instante, es decir, que básicamente no podemos esperar a que se replique la información en todos los nodos de nuestra arquitectura. Pues el hecho de que la operación termine antes de que todos los nodos se repliquen, esto sólo nos ha aumentado la disponibilidad, vale bien, pero es que esta decisión de aumentar la Disponibilidad nos degrada la Consistencia al no tener todos los nodos la misma información, por tanto, si un usuario que llega a nuestro servicio web y se le encamina a leer de un nodo con la información que ha sido replicada o actualizada, entonces no tendremos problemas, pero si por el contrario se le encamina a leer de un nodo con la información que aún no ha sido replicada o actualizada, se producirá una lectura inconsistente, esto el usuario en cuestión no lo aprecia, a él se le muestra la información, no sabe en que estado está dicha información, a no ser que en una segunda petición de información se le presente la información actualizada, pero dependiendo del servicio que estemos dando en algunos proyectos web puede no ser crítico este problema, pero en otros proyectos web puede ser muy crítico, estos factores hay que valorarlos muy bien. Por tanto, este tipo de arquitecturas que toman la decisión de sacrificar la Consistencia por la obtención de una mayor Disponibilidad, Tiempo de Respuesta y Tolerancia a Fallos, se denomina Consistencia Eventual ( eventually consistency ), esto quiere decir que si bien al terminar una operación el sistema puede estar inconsistente ya que como hemos dicho no se replica en todos, se garantiza que en un tiempo determinado el sistema quedará en un estado consistente, el factor clave está en el tiempo que pase desde que hay una escritura hasta que se produce la lectura, pero no podemos determinar dicho tiempo mínimo para que se produzca esta consistencia ya que el sistema también puede sufrir algún contratiempo inesperado.

Otro tipo de arquitectura que suele darse con mayor frecuencia en proyectos web, es la toma de decisiones de sacrificar la tolerancia a fallos, es decir, que esto nos implica el tener un único nodo o servidor. El tomar esta decisión sólo nos implica que únicamente se necesita escribir y leer del único nodo del sistema, con lo que conseguiremos por un lado Consistencia y por otro Disponibilidad, pero a ver una cosa, un segundo, esto tiene un alto riesgo que debemos tenerlo presente, pero también aclarar que si tenemos un servidor por ejemplo en RAID 1 la vida útil de media trabajando el servidor 24×7 en un CPD con condiciones de temperatura y demás, es de 4 o 5 años aproximadamente y no suelen dar problemas, pero pueden darse otros casos ajenos a nosotros, que en cuanto tengamos el servidor indispuesto por las razones que sea, nos quedamos sin servicio, por tanto aquí en este escenario la tolerancia a fallos es cero con alto riesgo, pero por otro lado piensa que tampoco está totalmente libre de poder tener degradación del tiempo de respuesta o de la disponibilidad, ojo, aunque no se haya producido ningún fallo, por ejemplo, veamos que ocurre si varios clientes quieren ejecutar varias transacciones concurrentes que afectan al mismo dato, ya tenemos en este momento un conflicto por lo que implementamos un mecanismo de bloqueo a nivel de fila. Este tipo de concurrencia nos puede llevar a una degradación del tiempo de respuesta por los bloqueos en las filas afectadas pero es que además puede afectar a la no disponibilidad del sistema, pero eso dependerá de carga en el número de transacciones concurrentes que tengamos. Algunas Bases de Datos permiten manejar el tipo de Consistencia mediante la disminución del grado de aislamiento de las transacciones, a esto le llamamos Control de Concurrencia Optimista (Optimistic Concurrency Control), que consiste en no bloquear filas. Si nuestro proyecto web necesita Disponibilidad y Consistencia, entonces necesitamos gestionar bien los conflictos e inconsistencias, cuidado con esto!!.

Una vez visto esta primera parte lo actualmente fascinante es que están apareciendo nuevas necesidades y nuevas formas de enfrentarse a la resolución y encontrar soluciones que con las herramientas actuales no es posible alcanzar la orientación hacia el usuario y grandes volúmenes de datos a leer, esto hace pensar y plantearse las cosas de otra forma afrontando nuevos retos. Con la aparición de los proyectos web de gran escala, un Google por ejemplo o un Amazon no pueden permitirse estar caídos, en cambio un Twitter o un Facebook pueden tolerar ciertos grados de inconsistencia, pero no una caída o una degradación del rendimiento. Por tanto es muy interesante llegado a este punto el encontrarse con nuevas vías alternativas al modelo relacional de Bases de Datos y que varios investigadores hayan comenzado a pensar de una forma muy distinta de almacenar esos datos en este tipo de servicios web, que engloba una serie de proyectos que están ganando terreno e interés a la hora de servir como alternativas a las soluciones tradicionales de Microsoft SQL-Server, Sybase, Oracle o MySQL. Aquí Dave Kellog en este artículo The NoSQL Movement analiza muy bien bajo mi punto de vista el estado de las bases de datos, pero lo más importante es saber adaptar la mejor solución a nuestras necesidades y pregúntate: ¿Es válida para mi proyecto y cómo me afecta?.

Esta pregunta se la han hecho ya en los Departamentos de Desarrollo de las grandes redes sociales como Twitter y ya están haciendo el cambio de MySQL a NoSQL, en este artículo explica el cambio Twitter growth prompts switch from MySQL to NoSQL database y el ingeniero de Twitter Ryan King lo comenta en su blog las razones por las que han comenzado la migración a Cassandra, una base de datos NoSQL cuyas características principales son resistencia, escalabilidad y la gran comunidad de desarrolladores por la que es apoyada. En Cassandra por ejemplo es posible especificar al leer o escribir dependiendo del nivel de consistencia que quieres tener en la operación, desde el más bajo, que indica que al leer o escribir basta con completar la operación en uno de los nodos, un estado intermedio donde en la mitad más uno para dar por terminada la operación y hasta realizar operaciones con máxima consistencia, donde todos los nodos deben replicarse al escribir o bien responder en la lectura.  Werner Vogels, CTO de Amazon, habla de Dynamo de “un almacenamiento de Clave-Valor de alta disponibilidad” y Google con BigTable, habla de un sistema de datos estructurados y distribuidos. Entonces si nuestro proyecto va en esta dirección, debemos cambiar nuestra forma de ver y entender las nuevas formas de construir proyectos web.

Según tengo entendido fue Johan Oskarsson quien organizó un evento para tratar las bases de datos distribuidas de código abierto no relacionales, llamándolas NoSQL (Not-Only SQL), tratando de impulsar alternativas muy distintas a las que hasta ahora hemos conocido con en el lenguaje SQL, pero claro esto significa que hay una evolución paralela de un mercado que durante años las bases de datos relacionales que son verticales y escalables, cubren unas necesidades muy distintas a las que necesitan de grandes almacenes de datos  y servicios gigantescos como con es el caso de las Redes Sociales.

Algunas peculiaridades del NoSQL es que pueden manejar enormes cantidades de datos como el caso de Hypertable, una implementación de código abierto basada en BigTable que procesa hasta 20 petabytes de datos por día y puede escribir 1000 millones de datos/día, según cuenta el ingeniero Doug Judd en su presentación. También es posible que se ejecuten en clusters de servidores lowcost, por ejemplo Google cuenta que uno de sus clusters de BigTable más grande gestionando 6 petabytes de datos sobre miles de servidores. Por otro lado al no tener que realizar la traducción de datos hacia un formato SQL, las arquitecturas NoSQL son mucho más rápidas. Otro proyecto, MongoDB, una base de datos orientada a documentos/formularios, por su almacenamiento nativo de datos de tipo objeto.

Finalmente en este artículo “MySQL and Memcached: end of an era?” refleja la evolución de lo que hasta ahora estamos hablando sobre las grandes plataformas, pero yo personalmente no creo que sea el fin de las Bases de Datos ni mucho menos, son dos conceptos totalmente distintos para soluciones muy distintas, pero no es el fin de una era, yo diría una nueva R-Evolución a soluciones actuales , pero al final debemos ser nosotros mismos como responsables de nuestros proyectos la toma de decisiones correctas.

4 comentarios en “Bases de Datos: RDBMS vs No-SQL, una R-Evolución

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s