Sistemas de Gestion de Base de Datos

Trmino usado en 1998 para una base de datos relacional sin SQL

>No Relacional<
No siguen el modelo de datos relacional Los datos no se estructuran en tablas Siguen diferentes estructuras de datos Simplicidad en los modelos: clavevalor, grafos, etc.

Qu es un Sistema NoSQL?
Es una amplia clase de sistemas de gestin de bases de datos que difieren del modelo clsico del sistema de gestin de bases de datos relacionales (RDBMS) (introduca una lnea no relacional significativamente diferentes de las clsicas) en aspectos importantes, el ms destacado que no usan SQL como el principal lenguaje de consultas. Muchas de las bases de datos NoSQL usan la llamada consistencia eventual para proporcionar disponibilidad y tolerancia al particionado, con un nivel mximo de consistencia de datos.

 La motivacin para NoSQL se deriva de la dicultad de las BD relacionales

para almacenar y gestionar:

Los datos de la web (especialmente la web 2.0) Datos semiestructurados y no estructurados.

Datos masivos: data streams, datos cientcos, procesos industriales, trco

de redes, etc.

. Los datos almacenados no requieren estructuras fijas como tablas,

normalmente no soportan operaciones JOIN, ni garantizan completamente ACID (atomicidad, coherencia, aislamiento y durabilidad), y habitualmente escalan bien horizontalmente.

 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 desarrollado por la universidad de Waterloo.

Bastantes sistemas NoSQL emplean una arquitectura distribuida. 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 unin de queries.

 Flexibilidad en los esquemas (Aadir nuevos atributos dinmicamente) Escalabilidad horizontal sobre equipos estndar Sistemas masivamente distribuidos Escalar el rendimiento de las operaciones

sobre equipos distribuidos Sharding (particionado horizontal por clave y distribucin)

Alto rendimiento: Actualizaciones intensivas de los datos en entornos distribuidos Uso eciente

de ndices distribuidos Almacenamiento orientado a memoria RAM

Eliminacin de algunas caractersticas ACID

Sencillez de los Call Level Interface (CLI)

 Clavevalor:

Regular stores: Redis, Tokyo, BerkeleyDB, ... In memory: JBoss cache, Velocity, ... Eventually Consistent stores: Dynomite, SubRecord,, Cassandra, de Apache The Apache Cassandra, BigTable, de Google, Dynamo, de Amazon, MongoDB, Project Voldemort, de LinkedIn, Riak.
Orientadas a columnas:

Google BigTable, HBase, Cassandra, HyperTable, LevelDB.

Orientadas a documentos:

CouchDB, MongoDB, Apache JackRabbit, ThruDB, de Apache, de 10gen, RavenDB, de Hibernating Rhinos,BaseX, djondb, eXist, SimpleDB, IBM Lotus Domino
De grafos: Neo4j, VertexDB, Infogrid, Sones, Filament, Allegrograph,

HyperGraphDB, DEX,, OrientDB, InfiniteGraph, Sones GraphDB.

 Consistencia: Todos los nodos tienen siempre la misma versin de

los datos.

Disponibilidad (availability): Todos los nodos tienen siempre

constancia de sus lecturas/escrituras.

Tolerancia a fallos (partition tolerance): El sistema sigue

funcionando aunque haya fallos en algunos nodos.

Teorema CAP
Un sistema distribuido solo puede garantizar simultneamente dos de las propiedades anteriores.

 ACID:

Atomicidad: o se ejecutan todas o se anulan todas.

Consistencia: las transacciones preservan la consistencia. Aislamiento: las transacciones se ejecutan como si estuvieran

aisladas.

Durabilidad: las transacciones conrmadas son persistentes en la

base de datos.

BASE: Disponibilidad bsica (basically available): garantiza disponibilidad,

en los trminos de CAP.

Estado suave (soft state): el estado del sistema puede cambiar con el

tiempo, incluso sin entradas de datos.

Consistencia eventual (eventual consistency): ser consistente en el

tiempo, mientras no reciba datos de entrada en ese tiempo

NoSQL frente a Relacional

Se pierde:
(a veces)

Transacciones y ACID Independencia de datos SQL estndar ndices secundarios

Se gana:
orientado a la memoria principal Simplicidad en el diseo, en los procesos, en la administracin, Posibilidad de afrontar datos en tiempo real. Estos sistemas responden a las necesidades de escalabilidad horizontal que tienen cada vez ms empresas. Pueden manejar enormes cantidades de datos. No generan cuellos de botella. Escalamiento sencillo. Diferentes DBs NoSQL para diferentes proyecto. Se ejecutan en clusters de mquinas baratas.

Tratamiento de grandes cantidades de datos distribuidos Almacenamiento

 Se acabaron los tiempos del planteamiento nico

El modelo relacional no resulta apropiado para todos los segmentos del mercado Los mercados verticales requieren cambios en los modelos de datos y en los lenguajes de consulta Las bases de datos relacionales requieren una revisin (New SQL) La situacin recuerda al periodo 19701985

Reflexiones
1. La web lo cambi todo 2. Las necesidades de mayor rendimiento siempre estarn presentes 3. El modelo relacional es apropiado para muchas aplicaciones pero no para todas 4. La base instalada de productos relacionales (Old SQL) es enorme 5. New SQL puede determinar la evolucin de los productos relacionales 6. NoSQL es una opcin real hoy por hoy en determinados entornos 7. NoSQL tender a crecer en los prximos aos

 http://coba.dc.fi.udc.es/~lgares/FIC_OnDev/NoSQL_BigData_LuisAres.pdf https://s3.amazonaws.com/0103.static.prezi.com/export/2013/08/23/1b2

0c06f712ad550/copy-of-bases-de-datos-nosql-4mviuggs-roe.zip

http://es.wikipedia.org/wiki/NoSQL

http://es.wikipedia.org/wiki/Sistema_de_gesti%C3%B3n_de_bases_de_datos

#Sistemas_NoSQL_de_2000

http://www.genbetadev.com/bases-de-datos/el-concepto-nosql-o-como-

almacenar-tus-datos-en-una-base-de-datos-no-relacional