Bases de Datos NoSQL

BDM - 2019

Contexto

• La heterogeneidad de los datos que circulan a través de la web han llevado al límite a los RDBMS.

​

• Las soluciones generalmente vienen a partir de escalar las aplicaciones.

​

Escalabilidad Horizontal

Los sistemas no escalables alcanzan una meseta de rendimiento, donde agregar nuevos procesadores no incrementa el rendimiento.

Las arquitecturas escalables lineales proporcionan una tasa constante de rendimiento adicional a medida que aumenta el número de procesadores

¿Qué es NoSQL?

¿Qué es y qué no es NoSQL?

​

​

Presiones en una arquitectura RDBMS

Las empresas han encontrado valor en capturar y analizar rápidamente grandes cantidades de datos variables, y realizar cambios inmediatos en sus negocios en función de la información que reciben.

Control de Transacciones

Control de transacciones es importante en entornos informáticos distribuidos con respecto al rendimiento y la consistencia

Modelos de control de transacciones:

​

• ACID: Utilizado en RDBMS
• BASE: Utilizado en muchos NoSQL

Principales diferencias radican en:

• Esfuerzo de desarrollo
• La ubicación de los controles de transacción

Para que la transacción se considere confiable, ambos pasos deben funcionar o ambos deben deshacerse.

RDBMS

BEGIN TRANSACTION ... END TRANSACTION

La transacción es responsabilidad del motor de bd.

Control de Transacciones: ACID

RDBMS controla las transacciones a través del uso de la atomicidad, consistencia, independencia y la persistencia.

Esto se sintetiza las propiedades de ACID.

​

​

​

ACID hace foco en la consistencia y en la integridad por sobre otros desafío.

​

Utiliza estrategias de bloqueo de recursos

Situación: ACID

BEGIN TRANSACTION ... END TRANSACTION

​

Sin Control de Transacciones: BASE

• Los websites de e-commerce con carritos de compras y pago+envío consideran de manera diferente el problema de las transacciones.
• Mantenerse inconsistentes por unos minutos es menos importante que no poder tomar un pedido. Bloquear un pedido es perder un cliente.

• La alternativa a ACID es BASE
• Basic availability: permite que los sistemas sean temporalmente inconsistentes para que las transacciones sean manejables.
• Soft-state: permite algunas inconsistencias temporalmente y los datos pueden cambiar mientras se usan para reducir la cantidad de recursos consumidos
• Eventual consistency: significa que cuando toda la lógica de servicio es ejecutada, el sistema alcanza un estado consistente.

​

BASE

• A diferencia de un RDBMS que se enfoca en la consistencia, BASE se enfoca en la disponibilidad.

​

• El Objetivo es permitir que se almacenen los nuevos datos, incluso a riesgo de no estar sincronizados durante un corto período de tiempo.

ACID vs BASE

Teorema CAP

• Eric Brewer introdujo por primera vez el Teorema de CAP en 2000.
• El teorema de CAP establece que cualquier sistema de base de datos distribuida puede tener como máximo dos de las siguientes tres propiedades deseables:
• Consistency: Tener una versión única, actualizada y legible de sus datos disponible para todos los clientes
• High availability: La base de datos distribuida siempre permitirá a los clientes actualizar los elementos sin demora.
• Partition tolerance: La capacidad del sistema para seguir respondiendo a las solicitudes de los clientes, incluso si hay una falla de comunicación entre las particiones de la base de datos.

Teorema CAP

Tipos de almacenamiento

Type

NoSQL

Typical usage

Examples

Almacenamiento Key-Value

• Las claves son utilizadas para recuperar los valores
• Los valores pueden ser de cualquier tipo de dato. Por ejemplo: Imagen, video, etc.

PROS: escalable, simple API (put, get, delete)

​

CONT: no hay forma de consultar el contenido de los valores.

Ejemplos:

Berkley DB,

Memcache,

DynamoDB, S3,

Redis, Riak

Column-Family

• Las claves incluyen una fila, familia de columnas y nombres de columnas.
• Puede almacenar blobs versionados en una gran tabla.
• Las consultas pueden ser realizadas en filas y familias de columnas y nombres de columnas

• Pros: Alta escalabilidad y disponibilidad
• Cons: No es posible consultar un blob de datos, el diseño del esquema de filas y columnas es crítico.

Column store key-value

La clave está compuesta de:

​

• row id (string)
• Column family (grouping of columns)
• Column name (string)
• Timestamp (64-bit value)

​

Value

• un blob (byte stream)

Graph Store

• Los datos son almacenados en series de nodos relaciones y propiedades
• Las consultas son totalmente transversales a la red
• Son ideales cuando la relación entre los datos es una clave:
• Por ejemplo: Social networks.

• Pros: Permite realizar búsquedas rápidas en la red.
• Cont: Pobre escalabilidad cuando el grafo sobrepasa el tamaño de la red.

Ejemplos:

Neo4j, AllegroGraph,

Bigdata triple store,

InfiniteGraph,

StarDog

Almacenamiento de documentos

Pros: No existe una capa de mapeo de objetos

Cons: Incompatible con SQL, complejo de implementar

​

• Los datos son almacenados en jerarquías anidadas.
• La lógica de los datos queda almacenada como una unidad.
• Cualquier ítem en el documento puede ser consultado.

Ejemplos:

MarkLogic, MongoDB,

Couchbase, CouchDB,

RavenDB, eXist-db

​

Modelos de NoSQL orientado a Documentos

Ejemplo: Base de documentos de bibliografía

Documentos

JSON

Consultar los documentos

No hay un lenguaje de consultas estándar como SQL

Recupero TODOS los documentos

Consultar los documentos

Recupero solo documentos que contengan la secuencia 2012

Casos de Estudio

LiveJournal’s Memcache

• Necesidad de aumentar el rendimiento de las consultas de la base de datos.
• Mediante el uso de hash y almacenamiento en caché, los datos en la RAM se pueden compartir. Esto reduce el número de solicitudes de lectura enviadas a la base de datos, lo que aumenta el rendimiento.

Google’s Bigtable

• Necesidad de almacenar de forma flexible datos tabulares en un sistema distribuido.
• Al utilizar un enfoque de matriz dispersa, los usuarios pueden pensar que todos los datos se almacenan en una sola tabla con miles de millones de filas y millones de columnas sin la necesidad de un modelado de datos inicial.

​

Bibliografía

• McCreary, D., & Kelly, A. (2013). Making Sense of NoSQL: A guide for managers and the rest of us.
• McCreary, D., & Kelly, A. (2014). Making sense of NoSQL. Shelter Island: Manning, 19-20. [ Slides ]