2012

BASE DE DATOS NO RELACIONES

SISTEMAS DE INFORMACIN II
Auquilla Jos Latacunga Freddy Morales Danny Salgado Daniel

15/03/2012

SISTEMAS DE INFORMACIN II

BASE DE DATOS NO RELACIONES

Bases de datos no relacionales (NoSql)

Introduccin A parte de las clsicas bases de datos SQL (RDBMS), aparecen y van tomando fuerza nuevos tipos de bases de datos. Su mayor ventaja es que estn preparados para ser muy rpidos. Mucho. Segn su tipo, cada una sigue una estrategia completamente diferente para persistir la informacin. Cabe destacar que normalmente no sustituyen a la base de datos clsica 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 decisin 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, segn nos convenga.

Arquitectura
Tpicamente 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 nmero de documentos, la presentacin de pginas en sitios que tienen gran trfico, y en sitios de streaming audiovisual. Las implementaciones tpicas de RDBMS se han afinado o bien para una cantidad pequea 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 sealar 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 Comisin Europea usado en los modelos de comparacin y calidad del aire, y en los 50 TB de la bsqueda de la bandeja de entrada de Facebook. Las arquitecturas NoSQL frecuentemente aportan escasas garantas de consistencia, tales como consistencia de eventos o transaccional restringida a tems nicos de datos. Algunos sistemas, sin embargo, aportan todas las garantas de los sistemas ACID en algunas instancias aadiendo 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

SISTEMAS DE INFORMACIN 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 distribudas de mltiples filas con garantas de aislamiento snapshot para el sistema subyacente de almacenamiento en esa columna, sin sobrecarga extra en la gestin de los datos, despliegue en el sistema de middleware, ni mantenimiento introducido por la capa de middleware. Bastantes sistemas NoSQL emplean una arquitectura distribuda, manteniendo los datos de forma redundante en varios servidores, usando frecuentemente una tabla hash distribuida. De esta forma, el sistema puede realmente escalar aadiendo ms 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 estndar Xquery. Los sistemas mas novedosos tales como CloudTPS tambin soportan union de queries. Las bases de datos relacionales no tienen nada de malo: Precisamente gracias al transcurso de los aos, hemos logrado aprender tcnicas bastante comunes para normalizarlas en la medida de lo posible, escalarlas segn crece la demanda, y utilizarlas como sistema de persistencia para almacenar informacin 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, encontrndose 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 ms difciles, s que es cierto que, a menudo, se hacen cada vez menos intuitivos a medida que aumenta la complejidad. Triples y cudruples JOINs en consultas SQL que asustan al ms pintado nada ms verlas, a veces poco eficientes, y sistemas de almacenamiento de resultados en cachs para acelerar la resolucin de las peticiones y evitar ejecutar cada vez estas pesadas operaciones, son el pan de cada da en muchos de estos proyectos de software. Los sistemas NoSQL intentan atacar este problema proponiendo una estructura de almacenamientoms verstil, aunque sea a costa de perder ciertas funcionalidades como las transacciones que engloban operaciones en ms de una coleccin de datos, o la incapacidad de ejecutar el producto cartesiano de dos tablas (tambin llamado JOIN) teniendo que recurrir a la desnormalizacin de datos.

SISTEMAS DE INFORMACIN 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 replicacin integrada. Casi nada ser mejor que veamos cada una de estas caractersticas en ms 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 funcin que se ejecuta para cada documento. Esta funcin recibe como parmetro el propio documento y puede devolver pares de clave-valor. Reduce: A grandes rasgos esta agrupa los resultados del Map para obtener un nmero La funcin Reduce recibe como entrada todas las claves y todos los valores.
Accesible por REST

SISTEMAS DE INFORMACIN II

BASE DE DATOS NO RELACIONES

Nos permite acceder a nuestro datos de una forma muy sencilla a travs de URLs. Por ejemplo para recuperar nuestro documento con id 6e1295ed6c29495e54cc05947f18c8af de nuestra BD albumsaccederamos a esta URL que nos devuelve el documento JSON.

Replicacin integrada

Una funcionalidad relativamente extica 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 sencillsima una o mas rplicas 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 cercana al bare metal, o recursos de hardware de la mquina, de modo que es bastante rpido a la hora de ejecutar sus tareas. Las caractersticas que ms destacara de MongoDB son su velocidad y su rico pero sencillo sistema de consulta de los contenidos de la base de datos. Se podra decir que alcanza un balance perfecto entre rendimiento y funcionalidad, incorporando muchos de los tipos de consulta que utilizaramos 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 podra decir que son el equivalente a las tablas en una base de datos relacional (slo 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 informacin por los contenidos de estos atributos.
Formato de los documentos

Los distintos documentos se almacenan en formato BSON, o Binary JSON, que es una versin modificada de JSON que permite bsquedas rpidas de datos. Para hacernos una idea, BSON guarda de forma explcita las longitudes de los campos, los ndices de los arrays, y dems informacin til para el escaneo de datos.

SISTEMAS DE INFORMACIN II

BASE DE DATOS NO RELACIONES

Cmo 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 especfico. Por ejemplo, podemos capturar el post que tiene un determinado ttulo:
db.posts.find({title : Una introduccin a MongoDB})

Ventajas de la bases de datos no relacionales A parte de las clsicas 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 implementacin de cdigo abierto basada en BigTable (de Google), puede escribir 1000 millones de celdas de datos por da. Al igual que BigTable, con MapReduce, es capaz de manejar 20 petabytes diarios. Se ejecutan en clusters de mquinas baratas: estos sistemas no requieren de apenas computacin, en comparacin con los sistemas gestores de base de datos tradicionales y basados en SQL, por lo que se pueden montar en mquinas de un coste ms reducido y en mayor nmero, 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, adems de un nivel de ejecucin ms concreto para poderse llevar a cabo, por lo que constituye un punto de entrada comn, 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 lnea realizar una cantidad interna de operaciones desorbitada.

Las desventajas
Bueno, y despus 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 informacin, en gestin de cuentas, y entornos en los que es preferible que los datos puedan tener algo ms de inteligencia, en lugar de algo ms de rapidez, estos sistemas no son aconsejables, ya que la nica, pero mayor desventaja de estos es que no respetan ACID.

SISTEMAS DE INFORMACIN 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 tambin se quiere ir hacia los ambientes empresarios. Ahora que Oracle adquiri a la base de datos open source lder, MySQL, los esfuerzos para impulsar a Cassandra se han redoblado.

Cassandra fue creada para manejar grandes volmenes de datos distribuidos en numerosos servidores estndar, ofreciendo alta disponibilidad sin ningn punto nico de falla. Tiene un almacn de valores de claves manejado con consistencia eventual (modelo de consistencia usado en programacin paralela). Las claves mapean hacia mltiples 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 especficas y as diferentes claves tendrn 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 hbrido entre una DBMS orientada a columnas y un almacn 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 cdigo Google y en marzo de 2009 se convirti en un proyecto de Apache Incubator.