Bases de datos NoSQLMongoDB

Lic. Juan Azcurra/jazcurra

NoSQL

Introducción

Eras de las Bases de Datos

▣RDBMS para sistemas transaccionales.

▣Data Warehouse para aplicaciones analíticas.

▣NoSQL para cualquier contenido.

Evolución de las Bases de Datos

Previo a NoSQL Posterior a NoSQL

Evolución de las Bases de Datos: RDBMS

▣Los datos usualmente son almancenados en filas.

▣Lenguaje estandarizado de consultas (SQL).

▣El modelo de datos se define antes de poder agregar los datos.

▣Las relaciones unen datos desde distintas tablas (joins).

▣Los resultados son tablas.Oracle, MySql, PostgresSQL, MSSql, IBM DB/2

▣Pros: transacciones con alto nivel de control de seguridad (ACID).

▣Cons: diseño previo, no son muy escalables.

Evolución de las Bases de Datos: Analytical

▣Basadas en un esquema estrella con una tabla central para cada evento.

▣Optimizadas para análisis de datos históricos.

▣Uso de lenguaje MDX para consultar las medidas para cada categoría de datos.

Cognos, Hyperion, Microstrategy, Pentaho, SAP BO, Microsoft, Oracle.

▣Pros: consultas rápidas para grandes volúmenes.

▣Cons: no optimizado para transacciones y actualizaciones.

Evolución de las Bases de Datos: Key Value

▣Utilizan valores claves para acceder a BLOBs (Binary Large Objects) de datos.

▣Los valores pueden contener cualquier tipo de datos (imágenes, audio, video).

Berkley DB, Memcache, DynamoDB, S3, Redis, Riak

▣Pros: escalable, API simple (insertar, leer, eliminar).

▣Cons: no es posible consultar basado en el contenido del valor.

Evolución de las Bases de Datos: Column-Family

▣La clave incluye una fila, familia de columna y nombre de columna.

▣Almacenar blob versionado en una tabla.

▣Las consultas se pueden realizar a nivel de fila, familia o nombre de columna.

Cassandra, HBase, Hypertable, Apache Accumulo, Bigtable

▣Pros: escalable, permite versionado.

▣Cons: no es posible consultar basado en el contenido del valor.

Evolución de las Bases de Datos: Graph

▣Los datos son almacenados en una serie de nodos, relaciones y propiedades.

▣Las consultas son a través de los grafos.

▣Ideal para cuando las relaciones entre los datos es clave: ej. Redes sociales.

Neo4J, AllegroGraph, Bigdata triple store, InfiniteGraph, StarDog

▣Pros: consultas rápidas en la red.

▣Cons: Mala escalabilidad cuando el grafo no cabe en memoria, lenguaje de consulta especializado.

Evolución de las Bases de Datos: Document

▣Los datos son almacenados en jerarquías anidadas.

▣Los datos se guardan como una unidad.

▣Cualquier ítem en el documento puede ser consultado.

MarkLogic, MongoDB, CouchBase, CouchDB, eXist-db

▣Pros: capa de mapeo, ideal para búsqueda.

▣Cons: Complejo para implementar, incompatible con SQL.

SQL vs NoSQL

Document Database

MongoDB

MongoDB: Casos de estudio

MongoDB: Conceptos

▣Base de Datos multiplataforma, que provee alta performance, alta disponibilidad y escalamiento automático.

▣Un registro en MongoDB es un documento, el cual es una estructura compuesta de pares campo: valor. Los documentos son similares a los objetos JSON.

JSON: Conceptos

▣JavaScript Object Notation, es un formato liviano para intercambio de datos.

▣Es un formato de texto completamente independiente del lenguaje.▣Está constituido por dos estructuras:

□Colección de pares de nombre / valor.□Una lista ordenada de valores.

{ : }valuestring

object

,

object

JSON: Values

▣Un valor puede ser una cadena de caracteres, un número, un boolean, un objeto o un array.

number

string

value

object

false

null

array

true

value

JSON: Array

▣Un arreglo es una colección de valores,

[ ]value

array

,

JSON: Ejemplo

{ "nombre": "Juan Perez", "alumno": true, "carrera": "Licenciatura en Informatica", "materias": [

{ "materia": "Laboratorio 2","nota": 7,"fecha": "2106-09-20"

}, { "materia": "Base de Datos",

"nota": 9,"fecha": "2015-12-20" }

]}

MongoDB: Definiciones

MongoDB: Documents

▣MongoDB almacena los registros de datos como documentos BSON (Binary JSON).

▣El valor de un campo puede ser cualquier tipo de dato BSON, incluyendo otro documento, array o un array de documentos.

▣Cada documento incluye un ID para identificarlo univocamente.

MongoDB: Modelado

▣Al momento de modelar un documento, se deben considerar la decisión de embeber los datos o utilizar referencias.

MongoDB: Modelado

▣Es posible embeber datos relacionados en una estructura simple o documento, estos esquemas son desnormalizados.

▣Los modelos de datos embebidos se utilizan cuando:□Existe una relación “contiene” entre las entidades.□Existe una relación uno-a-muchos entre las entidades.

MongoDB: Modelado

▣Relaciones uno-a-uno entre entidades, es posible embeber directamente los datos en el documento.

□En el ejemplo, el domicilio del cliente está embebido en la entidad.

MongoDB: Modelado

▣Es posible resolver relaciones uno-a-muchos embebiendo la información en el documento.

MongoDB: Modelado

▣Es posible (para evitar la redundancia), resolver las relaciones uno-a-muchos utilizando referencias.

MongoDB: CRUD

▣Create Operation: □db.collection.insert()□db.collection.insertOne()□db.collection.insertMany()

▣Read Operation:□db.collection.find()

▣Update Operation:□db.collection.update()□db.collection.updateOne()□db.collection.updateMany()□db.collection.replaceOne()

▣Delete Operation:□db.collection.remove()□db.collection.deleteOne()□db.collection.deleteMany()

MongoDB: Correspondencia con SQL

MongoDB: Correspondencia con SQL

MongoDB: Correspondencia con SQL