El movimiento NoSQL (II)

22 octubre, 2012
Materiales promocionales de la base de datos MongoDB MerchandisingNoSQL

Seguimos tratando las bases de datos NoSQL, de las que ya empezamos a hablar en la entrada anterior.

Materiales promocionales de la base de datos MongoDB
Materiales promocionales de la base de datos MongoDB

NoSQL se orienta principalmente a entornos altamente distribuidos –donde existen miles de ordenadores (o nodos) trabajando de manera colaborativa– que necesitan gestionar grandes volúmenes de datos con alta disponibilidad. La mayoría de estos sistemas usan la replicación y fragmentación de los datos, y explotan el paralelismo para potenciar la escalabilidad y la disponibilidad. Además, a diferencia de los gestores de bases de datos relacionales, en este tipo de soluciones es posible añadir nuevos nodos (normalmente “en caliente”) para conseguir mayor capacidad. Esto se conoce como escalabilidad horizontal.

En este contexto, es necesario considerar la conjetura de Brewer, también conocida como teorema CAP (Consistency, Availability and tolerance to network Partition). Dicho teorema establece que en un sistema distribuido es imposible conseguir simultáneamente las tres características, y que en consecuencia es necesario elegir dos de las tres.

La consistencia (consistency) se refiere a la capacidad de que se puedan recuperar siempre los mismos datos en un mismo instante de tiempo. Por su parte la disponibilidad (availability) se refiere a que si alguno de los nodos del sistema distribuido no se encuentra disponible, el resto pueda seguir trabajando. Finalmente, la tolerancia a la partición de red (tolerance to network partition) significa que el sistema distribuido pueda seguir operando, incluso ante posibles fallos en parte de la red de comunicaciones.

La tolerancia a la partición de red, más que una decisión, constituye una necesidad en la mayoría de sistemas altamente distribuidos. Por lo tanto, la decisión consiste en elegir entre consistencia o disponibilidad, y en general en las soluciones tecnológicas bajo el paraguas NoSQL, se opta por la disponibilidad. Esto ha causado que se trabaje con definiciones que relajan la noción de consistencia anteriormente presentada. NoSQL contrapone a la gestión ACID de las transacciones el paradigma BASE el cual, principalmente, garantiza que la base de datos convergerá hacia la consistencia con el paso del tiempo (eventual consistency). Es decir, dado un período de tiempo suficiente sin cambios en unos mismos datos, se espera que todas las réplicas disponibles de esos datos converjan hacia unos mismos valores. En el caso de conflictos que no puedan resolverse, se acepta que se puedan perder algunos datos. Por ejemplo, MongoDB deja elegir entre diferentes niveles de consistencia, siendo el más bajo aquel en el que el gestor ni siquiera realiza acuse de recibo de las inserciones llevadas a cabo. En estos casos, un pequeño retraso producido en el momento de la copia de los datos (por ejemplo, para replicarlos) puede llegar a causar un embotellamiento que haga que algunas escrituras, cada cierto tiempo, se pierdan ya que el gestor no es capaz de mantener el ritmo de las inserciones.

Otra cuestión relevante es el modelo de datos que subyace en NoSQL. En este sentido ¿cómo se estructuran los datos en NoSQL? ¿Qué características tienen los lenguajes (y las aplicaciones) que permiten definir y manipular dichas estructuras de datos? ¿Es posible que las bases de datos SQL y NoSQL sean las dos caras de una misma moneda? en el artículo A Co-Relational Model of Data for Large Shared Data Banks se tratan éstas y otras cuestiones. Como norma general, NoSQL redibuja el concepto de esquema (se habla de esquemas flexibles que permiten la evolución en el tiempo y, en general, el gestor no guarda metadatos sobre los datos), elimina la independencia de los datos que promulgan las bases de datos relacionales y el esquema queda implícito en el código de acceso de la aplicación (que, a diferencia de los gestores relacionales, puede manipular las estructuras físicas del gestor). Este hecho dificulta algunas tareas clásicas de los administradores de bases de datos, que deben gestionar la seguridad y la concurrencia desde la propia aplicación, difuminando así el rol del programador y del administrador de la base de datos.

Para finalizar, la mayoría de soluciones NoSQL se encuentran en versiones 1.0 o 2.0, lo que hace que su nivel de madurez sea bajo. También el cambio de paradigma complica su aprendizaje. Ambos factores actúan de barrera para muchos negocios/proyectos que todavía no confían en la nueva ola de sistemas gestores englobados bajo la denominación NoSQL.

Oscar Romero es licenciado en Informática por la UPC y doctor en Computación por la misma universidad. Es profesor del departamento de ESSI de la UPC. Su actividad docente se centra en las asignaturas de bases de datos.

M. Elena Rodríguez es licenciada en Informática por la UPC y doctora en Ciencias de la Computación por la Universidad de Alcalá. Es profesora de los EIMT de la UOC y también colabora como profesora asociada en el departamento de ESSI de la UPC. Su actividad docente se centra sobre todo en asignaturas de bases de datos.

Toni Tassani es Ingeniero en Informática por la UPC. Trabajó en Oracle durante ocho años. Colabora con la UOC como consultor de asignaturas de bases de datos desde 2003. Actualmente trabaja como desarrollador en Thomson Reuters y sus intereses se centran en las metodologías ágiles. @atassani

(Visited 74 times, 1 visits today)
Autor / Autora
Comentarios
Juanjo23 octubre, 2012 a las 4:24 pm

Muy interesante estos dos artículos para conocer un poco más el movimiento noSQL. Antes de leerlos me pasaba un poco como al de este chiste:

http://geek-and-poke.com/2012/10/yes.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+GeekAndPoke+%28Geek+And+Poke%29

Responder
Deja un comentario