BASE DE DATOS NO RELACIONES

- Auquilla José- Latacunga Freddy- Morales Danny- Salgado Daniel

6

SISTEMAS DE INFORMACIÓN II BASE DE DATOS NO RELACIONES

Bases de datos no relacionales (NoSql)

Introducción

A parte de las clásicas bases de datos SQL (RDBMS), aparecen y van tomando fuerza nuevos tipos de bases de datos.

Su mayor ventaja es que están preparados para ser muy rápidos. Mucho.

Según su tipo, cada una sigue una estrategia completamente diferente para persistir la información.

Cabe destacar que normalmente no sustituyen a la base de datos clásica SQL, sino que surgen por otra necesidad. Una necesidad de rendimiento extremo. Si se utilizan de una manera única, o se combinan con una base de datos SQL es una decisión de arquitectura del sistema.

Algunas de ellas pueden ser accedidas mediante SQL, pero normalmente no será así, puesto que cada una tendrá una API exclusiva.

Existen proyectos como Spring Data que pretenden abstraernos de dicha complejidad. Siendo posible cambiar de un tipo de base de datos a otra de una manera directa, según nos convenga.

Arquitectura

Típicamente las bases de datos relacionales modernas han mostrado poca eficiencia en determinadas aplicaciones que usan los datos de forma intensiva, incluyendo el indexado de un gran número de documentos, la presentación de páginas en sitios que tienen gran tráfico, y en sitios de streaming audiovisual. Las implementaciones típicas de RDBMS se han afinado o bien para una cantidad pequeña pero frecuente de lecturas y escrituras o para un gran conjunto de transacciones que tiene pocos accesos de escritura. Por otro lado NoSQL puede servir gran cantidad de carga de lecturas y escrituras.

Implementaciones de NoSQL usadas en el mundo real incluyen los 3TB de los marcadores verdes de Digg (indicados para señalar las historias votadas por otros en la red social; aunque duró menos de 3 meses y fue abandonado). Los 6 TB de la base de datos del “ENSEMBLE” de la Comisión Europea usado en los modelos de comparación y calidad del aire, y en los 50 TB de la búsqueda de la bandeja de entrada de Facebook.

Las arquitecturas NoSQL frecuentemente aportan escasas garantías de consistencia, tales como consistencia de eventos o transaccional restringida a ítems únicos de datos. Algunos sistemas, sin embargo, aportan todas las garantías de los sistemas ACID en algunas instancias añadiendo una capa intermedia (como por ejemplo, AppScale o CloudTPS). Hay dos sistemas que han sido desplegados y que aportan aislamiento snapshot para almacenamientos de columna: El sistema Percolator de Google (basado en el sistema BigTable) y el sistema transaccional de Hbase

6

SISTEMAS DE INFORMACIÓN II BASE DE DATOS NO RELACIONES

desarrollado por la universidad de Waterloo. Estos sistemas, desarrollados de forma independiente, usan conceptos similares para conseguir transacciones ACID distribuídas de múltiples filas con garantías de aislamiento snapshot para el sistema subyacente de almacenamiento en esa columna, sin sobrecarga extra en la gestión de los datos, despliegue en el sistema de middleware, ni mantenimiento introducido por la capa de middleware.

Bastantes sistemas NoSQL emplean una arquitectura distribuída, manteniendo los datos de forma redundante en varios servidores, usando frecuentemente una tabla hash distribuida. De esta forma, el sistema puede realmente escalar añadiendo más servidores, y el fallo en un servidor puede ser tolerado.

Algunos defensores de NoSQL promueven interfaces simples tales como los arrays asociativos o los pares clave-valor. Otros sistemas, tales como las bases de datos nativas en XML, promueven el soporte del estándar Xquery. Los sistemas mas novedosos tales como CloudTPS también soportan union de queries.

Las bases de datos relacionales no tienen nada de malo: Precisamente gracias al transcurso de los años, hemos logrado aprender técnicas bastante comunes para normalizarlas en la medida de lo posible, escalarlas según crece la demanda, y utilizarlas como sistema de persistencia para almacenar información desde nuestro lenguaje procedural u orientado a objetos favorito (entre otros). La cuota de uso de software como SQLite, MySQL, PostgreSQL u Oracle, por poner cuatro ejemplos conocidos, es muy alta, encontrándose en la mayor parte de los desarrollos modernos.

Pero llegó la web, el software como servicio, los servicios en la nube y las startups de éxito con millones de usuarios. Y con todo ello llegaron los problemas de alta escalabilidad. Si bien los modelos relacionales se pueden adaptar para hacerlos escalar incluso en los entornos más difíciles, sí que es cierto que, a menudo, se hacen cada vez menos intuitivos a medida que aumenta la complejidad. Triples y cuádruples JOINs en consultas SQL que asustan al más pintado nada más verlas, a veces poco eficientes, y sistemas de almacenamiento de resultados en cachés para acelerar la resolución de las peticiones y evitar ejecutar cada vez estas pesadas operaciones, son el pan de cada día en muchos de estos proyectos de software.

Los sistemas NoSQL intentan atacar este problema proponiendo una estructura de almacenamientomás versátil, aunque sea a costa de perder ciertas funcionalidades como las transacciones que engloban operaciones en más de una colección de datos, o la incapacidad de ejecutar el producto cartesiano de dos tablas (también llamado JOIN) teniendo que recurrir a la desnormalización de datos.

6

SISTEMAS DE INFORMACIÓN II BASE DE DATOS NO RELACIONES

EJEMPLOS DE BASE DE DATOS NO RELACIONALES

CouchDB

Lo podemos definir como una base de datos documental sin schema, consultable al estilo MapReduce, accesible por REST y con una funcionalidad de replicación integrada. Casi nada… será mejor que veamos cada una de estas características en más detalle.

Base de datos documental sin schema

Para CouchDB solo hay documentos. Todo lo que almacenamos es un documento sin schema, lo cual nos permite guardar juntos documentos con distintos campos dentro de la misma BD.

CouchDB no nos ofrece un lenguaje tipo SQL para realizar consultas sino que nos ofrece un sistema basado en MapReduce para poder obtener los datos que queramos. ¿Y como funciona esto? Pues es mas sencillo de lo que parece, se compone de una parte Map una parte Reduce.

Consultable al estilo MapReduce

CouchDB no nos ofrece un lenguaje tipo SQL para realizar consultas sino que nos ofrece un sistema basado en MapReduce para poder obtener los datos que queramos. Se compone de una parte Map una parte Reduce.

Map: Es una función que se ejecuta para cada documento. Esta función recibe como parámetro el propio documento y puede devolver pares de clave-valor.

Reduce: A grandes rasgos esta agrupa los resultados del Map para obtener un númeroLa función Reduce recibe como entrada todas las claves y todos los valores.

Accesible por REST

6

SISTEMAS DE INFORMACIÓN II BASE DE DATOS NO RELACIONES

Nos permite acceder a nuestro datos de una forma muy sencilla a través de URLs. Por ejemplo para recuperar nuestro documento con id 6e1295ed6c29495e54cc05947f18c8af de nuestra BD albumsaccederíamos a esta URL que nos devuelve el documento JSON.

Replicación integrada

Una funcionalidad relativamente exótica que nos permite que nuestra BD de datos sincronice sus datos de una forma muy sencilla (una simple llama REST la activa) con otra BD remota o local. De este modo podemos tener de una forma sencillísima una o mas réplicas de nuestra BD para implementar arquitecturas de alta disponibilidad o de balanceo de carga.

MongoDB.

Es un sistema de base de datos multiplataforma orientado a documentos, de esquema libre. Está escrito en C++, lo que le confiere cierta cercanía al bare metal, o recursos de hardware de la máquina, de modo que es bastante rápido a la hora de ejecutar sus tareas.

Las características que más destacaría de MongoDB son su velocidad y su rico pero sencillo sistema de consulta de los contenidos de la base de datos. Se podría decir que alcanza un balance perfecto entre rendimiento y funcionalidad, incorporando muchos de los tipos de consulta que utilizaríamos en nuestro sistema relacional preferido, pero sin sacrificar en rendimiento.

En MongoDB, cada registro o conjunto de datos se denomina documento. Los documentos se pueden agrupar en colecciones, las cuales se podría decir que son el equivalente a las tablas en una base de datos relacional (sólo que las colecciones pueden almacenar documentos con muy diferentes formatos, en lugar de estar sometidos a un esquema fijo). Se pueden crear índices para algunos atributos de los documentos, de modo que MongoDB mantendrá una estructura interna eficiente para el acceso a la información por los contenidos de estos atributos.

Formato de los documentos

Los distintos documentos se almacenan en formato BSON, o Binary JSON, que es una versión modificada de JSON que permite búsquedas rápidas de datos. Para hacernos una idea, BSON guarda de forma explícita las longitudes de los campos, los índices de los arrays, y demás información útil para el escaneo de datos.

6

SISTEMAS DE INFORMACIÓN II BASE DE DATOS NO RELACIONES

Cómo consultar los datos

En primer lugar, MongoDB nos permite utilizar funciones Map y Reduce.En MongoDB se pueden utilizar consultas al valor de un atributo específico. Por ejemplo, podemos capturar el post que tiene un determinado título:

db.posts.find({‘title’ : ‘Una introducción a MongoDB’})

Ventajas de la bases de datos no relacionales

A parte de las clásicas bases de datos SQL (RDBMS), aparecen y van tomando fuerza nuevos tipos de bases de datos.

Algunas de ellas pueden ser accedidas mediante SQL

Pueden manejar enormes cantidades de datos: esto es debido a su propia estructura distribuida. Por ejemplo, HyperTable, una implementación de código abierto basada en BigTable (de Google), puede escribir 1000 millones de celdas de datos por día. Al igual que BigTable, con MapReduce, es capaz de manejar 20 petabytes diarios.

Se ejecutan en clusters de máquinas baratas: estos sistemas no requieren de apenas computación, en comparación con los sistemas gestores de base de datos tradicionales y basados en SQL, por lo que se pueden montar en máquinas de un coste más reducido y en mayor número, gracias a su nivel de escalabilidad.

No generan cuellos de botella: el problema de fondo de los sistemas SQL, es que deben de transcribir cada sentencia para poder ser ejecutada y, cada sentencia compleja requiere, además de un nivel de ejecución más concreto para poderse llevar a cabo, por lo que constituye un punto de entrada común, único y conflictivo en base a rendimiento.

Solo lo estrictamente necesario: son sistemas simples que no tienen un sistema de consulta complejo ni con capacidad declarativa para en una sola línea realizar una cantidad interna de operaciones desorbitada.

.

Las desventajas

Bueno, y después de poner estos sistemas por las nubes… ahora toca pegar un poco los pies al suelo y darse de cara con la realidad. Quiero decir que, sí, hay desventajas, esto no es una panacea que sirva para paliar la necesidad del almacenaje de datos para todos los casos. En entornos de sistemas de información, en gestión de cuentas, y entornos en los que es preferible que los datos puedan tener algo más de inteligencia, en lugar de algo más de rapidez, estos sistemas no son aconsejables, ya que la única, pero mayor desventaja de estos es que no respetan ACID.

6

SISTEMAS DE INFORMACIÓN II BASE DE DATOS NO RELACIONES

PROYECTO KASANDRA

Apache Cassandra es la base de datos NoSQL que, en sus inicios, fue desarrollada por Facebook. Hoy la utilizan otros grandes usuarios como Twitter y Digg, aunque también se quiere ir hacia los ambientes empresarios. Ahora que Oracle adquirió a la base de datos open source líder, MySQL, los esfuerzos para impulsar a Cassandra se han redoblado.

Cassandra fue creada para manejar grandes volúmenes de datos distribuidos en numerosos servidores estándar, ofreciendo alta disponibilidad sin ningún punto único de falla. Tiene un almacén de valores de claves manejado con consistencia eventual (modelo de consistencia usado en programación paralela). Las claves mapean hacia múltiples valores que se agrupan en familias de columnas. Esas familias se definen cuando se crea una base Cassandra, pero luego se les puede agregar columnas a las diferentes familias. Las columnas se pueden agregar a claves específicas y así diferentes claves tendrán diferentes cantidades de columnas dentro de una misma familia. Los valores de una familia de columnas para cada clave se almacenan juntos, haciendo de Cassandra un híbrido entre una DBMS orientada a columnas y un almacén de datos orientado a filas. Cassandra fue desarrollada por Facebook para impulsar su dispositivo Inbox Search. Trabajaron Avinash Lakshman (uno de los autores de Dynamo de Amazon) y Prashant Malik, ingeniero de Facebook. Fue liberada como proyecto open source en julio 2008 en código Google y en marzo de 2009 se convirtió en un proyecto de Apache Incubator.