Angel “Java” Lopez http://www.ajlopez.com http://www.msmvps.com/lopez Introducción a NoSQL Angel “Java” Lopez http://www.ajlopez.com http://www.msmvps.com/lopez.

Presentación del tema: "Angel “Java” Lopez http://www.ajlopez.com http://www.msmvps.com/lopez Introducción a NoSQL Angel “Java” Lopez http://www.ajlopez.com http://www.msmvps.com/lopez."— Transcripción de la presentación:

1 Angel “Java” Lopez http://www.ajlopez.com http://www.msmvps.com/lopez
Introducción a NoSQL Angel “Java” Lopez

2 Agenda Qué es NoSQL Bases de Datos ACID, CAP, BASE Oferta NoSQL
Varias implementaciones Caso Twitter/Cassandra Usando MongoDB

3 ¿Qué es NoSQL? Not Only SQL
Alternativa a persistir en bases de datos relacionales Libre de esquema Libre estructura En general Distribuidas Alta disponibilidad Escalables

4 Bases de Datos Jerárquicas y en Red Hoy, relacionales en todos lados
Anteriores a las relacionales Hoy, relacionales en todos lados Brillan: Manejo de conjuntos Transacciones Seguridad ACID

5 ACID A I D C Atomic Consistent Isolated Durable Todo o nada
Rel DB A I D C Atomic Todo o nada Consistent Estado lógico consistente Isolated Concurrencia sin interferencia Durable Garantiza lo grabado

6 Más allá de una base Necesitamos escalabilidad
Necesitamos disponibilidad Replicación La misma base en varias bases en distintos servidores Partición Una tabla repartida en varias bases en distintos servidores

7 ACID Distribuido Implementado mediante 2PC Two Phase Commit
Hay un Coordinador de la transacción Avisa a cada base de datos: precommit Si todas las instancias están de acuerdo, avisa commit Si alguna base que rehúsa, avisa rollback ACID da Consistencia a las bases distribuidas

8 Consistencia Cuando hay una actualización, todos los observadores ven esa actualización (en caso de ir a leer) No acepción de C de ACID Con la llegada de Internet, surgió la importancia de la disponibilidad (availability) Con la llegada de Internet, llegaron miles o millones de usuarios, surgió la importancia de la escalabilidad Eric Brewer presenta el teorema CAP en 2000

9 Teorema CAP Tome DOS Consistency Todo o Nada
Si hay réplicas, en el mismo estado Availability Siempre disponible Si cae una réplica, sigue otra Partition-Tolerance Si hay partes de la red que no se comunican, seguir procesando C P A Tome DOS

10 Dos nodos, el valor v0 N1 A V0 N2 Dos nodos, tiene el valor V0 B V0

11 Un nodo actualiza el valor
Dos nodos, tiene el valor V0 B V0

12 El valor se traslada al otro nodo
Dos nodos, tiene el valor V0 B V1

13 Nodo 2 lee el valor N1 A V1 N2 Dos nodos, tiene el valor V0 B V1

14 El problema de tener Partition Tolerance
V1 N2 Dos nodos, tiene el valor V0 B V0

15 La transacción A Una solo nodo: Sync mediante lockeos en la base, ….
A1: Write Sync A2: Read A Una solo nodo: Sync mediante lockeos en la base, …. Varios nodos: el problema es la latencia de Sync

16 Manejando el problema CAP
Abandonamos P (Partition Tolerance) Ponemos todo en una caja Problemas de escalabilidad Abandonamos A (Availability) Ej: Al grabar/leer esperamos que todo se estabilice. Si hay falla de red, el dato no está disponible hasta reparar el fallo Abandonamos C (Consistency) Eventual Consistency: N1 tiene V1, y por un tiempo, N2 tiene V2

17 Tipos de Consistencia Proceso A graba y lee, Procesos B,C leen y graban independientemente de A Strong (Fuerte): Cuando alguien graba, todos (A,B,C) leen el mismo dato Weak (Débil): Cuando alguien graba, no se asegura que todos lean lo mismo. Dependiendo de unas condiciones, hay una ventana de inconsistencia Eventual: Si no hay más actualizaciones, al tiempo todos leen lo mismo. Ej. DNS (Domain Name System)

18 En el negocio Amazon Google
Una décima de segundo más, cuesta 1% de las ventas Google Medio segundo de latencia, baja el tráfico en un quinto

19 BASE B S E A Basic Available Soft state Eventually consistent
RelDB NoSQL B S E A Basic Available Soft state Eventually consistent

20 BASE Es diametralmente opuesto a ACID
ACID es pesimista, fuerza la consistencia al final de cada operación BASE es optimista, acepta que el estado de la base esté en cambio Provee availability soportando fallas parciales: Ej. Tener la base de usuarios particionada en 5 servidores Si falla uno, sólo afecta al 20% de los usuarios

21 Aparece NoSQL Ya que ACID no es posible siempre
Hay otras fuerzas: disponibilidad, escalabilidad, que hay nacido en gran parte por Internet CAP muestra que no podemos tenerlo todo BASE es aceptable en algunos sistemas (notablemente, grandes aplicaciones en Internet) Entonces: Se puede encarar la persistencia en algo que no es base de datos relacional Pasan de Consistency a Eventual Consistency, en general Harán hincapié en A o P de CAP.

22 Un poco de historia: Pick Systems
Proceso Registros Datos Datos Archivo Todo en paginas Pagina en memoria o en disco, es lo mismo Sector 1 Sector 2 Sector 3

23 Implementaciones Distribuidas No Distribuidas
Toman la responsabilidad de: Partition, para escalabilidad Replication, para disponibilidad Amazon Dynamo, Voldemort, CouchDB (via Lounge), Riak, MongoDB (en desarrollo), BigTable, Cassandra, HyperTable, Hbase No Distribuidas Responsabilidad en el cliente

24 Modelos de Datos Key-Value store Column store Document store
Ej: Amazon Dynamic, Voldemort, Tokyo Cabinet Column store Ej: Google BigTable, Cassandra, HBase Document store Ej: Apache CouchDB, MongoDB Graph databases Ej: Neo4j

25 Disco o Memoria En Memoria En Disco Configurable
Redis (async write to disk), Scalaris En Disco CouchDB, MongoDB, Riak (archivos) Voldemort (BDB o MySQL) Configurable BigTable, Cassandra, Hbase, HyperTable

26 Dynamo Producto interno de Amazon
Orientado a AP (Availability, Partition Tolerance) Sacrifica Consistency Adopta Eventual Consistency Muchos servicios internos de Amazon necesitan acceder por Clave a un Valor Los Datos son Particionados Los Datos son Replicados Dynamo is an AP system; it is highly available, even under network partitions, but eventually consistent.  Data is replicated within a single cluster, so even under partitions most data is available, however one node’s latest version might not match that of another, so every reader is only guaranteed to see every write eventually.

27 Cientos de Servicios en Amazon
amazon-dynamo-sosp2007.pdf

28 Operaciones Cada clave tiene un nodo coordinador asignado
La clave-valor se replica en otros servidores Put(key, value, context) Clave y valor Siempre toma el “write” Contexto tiene información como la versión Puede pedir que se escriba en W nodos Get(key) Dado la clave, recupera el valor Y el contexto Puede dar un valor, o una lista de valores en conflicto La aplicación decide qué hacer con los conflictos Puede pedir valores de R nodo

29 Anillo de Nodos Si el nodo B se cae, pasa a usar otro para manejar la clave K

30 Manejo de Modificaciones
Maneja versiones, marcando [Sx, T]: qué servidor, qué “tiempo”

31 BigTable Nace en Google Orientado a CA:
Strong Consistency High Availability Pero no resuelve Network Partitions No tiene replicación a nivel de una base de datos: La replicación la hace el Google File System Usado en Web indexing, Google Earth, Google Finance, Google Analytics, etc. Estas aplicaciones manejan datos desde simples URLs a fotos satelitales, desde batch hasta datos para usuarios finales en el momento BigTable is a CA system; it is strongly consistent and highly available, but can be unavailable under network partitions.  BigTable has no replication at the database level, rather replication is handled underneath by GFS.

32 Modelo de Datos Filas con clave string Columnas con clave string
Cada valor tiene: clave de fila, clave de columna, timestamp (int64) El valor es string

33 Filas BigTable las mantiene ordenadas por clave
Cada tabla es particionada El rango se llama tablet El programa cliente decide la clave Puede aprovechar que datos relacionados vayan al mismo tablet Ejemplo: clave com.google.maps queda “cerca” de otro com.google

34 Ejemplo de operación // Open the table
Table *T = OpenOrDie("/bigtable/web/webtable"); // Write a new anchor and delete an old anchor RowMutation r1(T, "com.cnn.www"); r1.Set("anchor: "CNN"); r1.Delete("anchor: Operation op; Apply(&op, &r1);

35 Voldemort Open Source Key-Value Usado en LinkedIn
Datos replicados automáticamente en múltiples servidores Datos automáticamente particionados La caída de un servidor es manejada transparentemente Cada nodo es independiente de los demás, no hay un punto central de coordinación Versionamiento de los datos Capa de storage: mockeable!

36 Simple Pros Cons value = store.get(key) store.put(key, value)
store.delete(key) Pros Fácil de distribuir en un cluster Cons No hay queries complejas (sólo simples) Todos los joins deben hacerse en código No hay control de “clave foránea”

37 SimpleDB Acceso por servicios web Ofrecido por Amazon con cargo
Replicación en data centers Eventual consistency en read Consistency en read

38 SimpleDB

39 Conceptos Cuenta del cliente: la planilla completa Dominio: cada hoja
Particionar dominio: en vez de Products: Books, DVDs, CDs Items: cada fila Atributo: cada columna Valores: en la celda, pueden ser multivaluadas

40 Consistent vs Eventually Consistent Read
W1 R1 color: red Consistent: W2 Eventual: W1, W2, o nada Cliente 1 Timeline Cliente 2 W2 R2 color: ruby Consistent: W2 Eventual: W1, W2, o nada

41 Consistent vs Eventually Consistent Read
W1 color: red Consistent: W1 oW2 Eventual: W1, W2, o nada Cliente 1 Timeline Cliente 2 W2 R2 color: ruby Consistent: W1 o W2 Eventual: W1, W2, o nada

42 Consistent vs Eventually Consistent Read
W1 R1 color: red Consistent: W1 oW2 Eventual: W1, W2, o nada Cliente 1 Timeline Cliente 2 R2 W2 Consistent: W1 o W2 Eventual: W1, W2, o nada color: ruby

43 Apache Cassandra Proyecto Apache de código abierto, escrito en Java
Originalmente desarrollado en Facebook Rackspace, Digg, SimpleGeo, Twitter, etc.. Alta disponibilidad: desde “write nunca falla” hasta “esperar a que todas las réplicas se puedan leer” Eventualmente consistente Decentralizado: todos los nodos en el cluster son iguales Tolerante a fallas: los datos son replicados automáticamente en múltiples nodos Flexible: agregado de nuevos nodos sin bajar el servicio Es base de datos distribuida, usando el modelo de datos de BigTable, y la infraestructura de Dynamo

44 Modelo de Datos: Columna
Unidad básica Nombre, valor, timestamp

45 Modelo de Datos: SuperColumna
Tiene nombre Y un map de Key-Column

46 ColumnFamily Lo más parecido a Table de base de datos Tiene Nombre
Se le agregan mapas de columnas

47 Modelo de Datos SuperColumnFamily KeySpace
Como ColumnFamily pero contiene SuperColumns KeySpace Contiene varias familias (tablas) Generalmente uno por aplicación

48 Un caso: Twitter

49 Un Tweet Buscar por Id: Buscar por Id de Usuario: int

50 Implementación original
Relacional Una sola tabla, escalada Replicación Master-Slave Memcached para reads

51 Implementación Original
Base Escribir Memcached Leer Memcached Rails Master Memcached Slave Slave

52 Problema Los disk arrays no pasan de 800GB
Con 2,954,291,678 tweets, el 90% del espacio está utilizado Solución: Partition

53 Posible: Partition por primary key
Buscar los tweets recientes, implica buscar N particiones

54 Posible: Partition por usuario
Buscar los tweets por Id, implica buscar N particiones

55 Actual: Partition por Tiempo
Las queries buscan en las particiones por orden, hasta acumular suficientes datos

56 Situación Baja latencia, PK lookup: Principios Memcached 1 ms
MySQL <10ms (dependiendo de las particiones a consultar) Principios Particionar e indexar Explotar localidad (lo local, localidad temporal) Los nuevos tweets son los más frecuentes consultados, en general en la primera partición

57 Problemas Capacidad de Write
A grandes velocidades de Tweets, MySQL deadlocks Crear un shard temporal Mucho trabajo de DBA

58 Adoptar Cassandra Partición por Primary Key Indice manual por User Id
Memcached para el 90% de los reads

59 Apache CouchDB Orientada a documentos RESTFul API
MapReduce desde JavaScript Escrito en Erlang

60 Documentos Compuesto de campos
Strings, números, fechas, listas ordenadas, mapas asociativos. Cada documento se identifica con un Id "Subject": "I like Plankton" "Author": "Rusty" "PostedDate": "5/23/2006" "Tags": ["plankton", "baseball", "decisions"] "Body": "I decided today that I don't like baseball. I like plankton."

61 Propiedades Provee ACID
Las actualizaciones son serializadas (ejecutadas en serie) Las lecturas pueden ser concurrentes: cada lector obtiene un “snapshot” consistente de la base

62 Distribuida La base de datos se distribuye entre pares
Servidores y clientes offline Si vuelve a online, una instancia replica los cambios bidireccionalmente Resuelve los conflictos, los trata no como excepciones, sino el estado normal Los conflictos pueden resolverse manualmente o mediante agentes distribuidos

63 MongoDB Open Source Orientada a Documentos estilo JSON
Replicación y Disponibilidad Auto-Sharding Rico modelo de queries Documentos con documentos embebidos o referenciados

64 Datos en MongoDB

65 Probar en linea

66 Levantando el servidor
Desde la línea de comando Mongodb.exe –dbpath .\db

67 Cliente de linea Mongo.exe

68 Primer ejemplo Creando documentos y grabando

69 Consultas Query “by example” Query con operadores

70 Ejemplo en C#

71 Otro modelo: Graph Neo4j

72 Nodos y Relaciones Node neo = graphdb.createNode();
node.setProperty("name", "Neo"); Node morpheus = graphdb.createNode(); morpheus.setProperty("name", "Morpheus"); neo.createRelationshipTo(morpheus, KNOWS);

73 De vuelta: Modelo de Datos
Key-Value Column Document Tamaño Graph +90% de los casos Complejidad

74 El tema a seguir Ir más allá de escalabilidad o disponibilidad ¿Podrá NoSQL ofrecer un mejor soporte para modelar modelos de dominio ricos?