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

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

¿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

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

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

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

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

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 http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf

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 http://www.julianbrowne.com/article/viewer/brewers-cap-theorem http://cacm.acm.org/blogs/blog-cacm/83396-errors-in-database-systems-eventual-consistency-and-the-cap-theorem/fulltext http://blog.mongodb.org/post/475279604/on-distributed-consistency-part-1

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

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

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

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

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

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

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 http://www.allthingsdistributed.com/2008/12/eventually_consistent.html

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)

En el negocio Amazon Google Una décima de segundo más, cuesta 1% de las ventas http://highscalability.com/latency-everywhere-and-it-costs-you-sales-how-crush-it Google Medio segundo de latencia, baja el tráfico en un quinto http://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20.html

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

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

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.

Un poco de historia: Pick Systems Proceso Registros Datos Datos Archivo Todo en paginas Pagina en memoria o en disco, es lo mismo http://blog.knuthaugen.no/2010/03/a-brief-history-of-nosql.html Sector 1 Sector 2 Sector 3

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 http://www.vineetgupta.com/2010/01/nosql-databases-part-1-landscape.html

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

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

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 http://s3.amazonaws.com/AllThingsDistributed/sosp/amazon-dynamo-sosp2007.pdf http://devblog.streamy.com/tag/eventual-consistency/ 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.

Cientos de Servicios en Amazon amazon-dynamo-sosp2007.pdf http://s3.amazonaws.com/AllThingsDistributed/sosp/amazon-dynamo-sosp2007.pdf

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

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

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

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 http://labs.google.com/papers/bigtable.html http://devblog.streamy.com/tag/eventual-consistency/ 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.

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

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

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:www.c-span.org", "CNN"); r1.Delete("anchor:www.abc.com"); Operation op; Apply(&op, &r1);

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!

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”

SimpleDB Acceso por servicios web Ofrecido por Amazon con cargo Replicación en data centers Eventual consistency en read Consistency en read http://awsdocs.s3.amazonaws.com/SDB/latest/sdb-gsg.pdf http://awsdocs.s3.amazonaws.com/SDB/latest/sdb-dg.pdf

SimpleDB

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

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

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

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

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

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

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

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

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

Un caso: Twitter http://nosql.mypopescu.com/post/619925133/learning-nosql-from-twitters-experience http://www.slideshare.net/nkallen/q-con-3770885?from=ss_embed http://nosql.mypopescu.com/post/407159447/cassandra-twitter-an-interview-with-ryan-king

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

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

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

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

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

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

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

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

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

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

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

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."

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

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

MongoDB Open Source Orientada a Documentos estilo JSON Replicación y Disponibilidad Auto-Sharding Rico modelo de queries Documentos con documentos embebidos o referenciados http://www.mongodb.org/ http://msdn.microsoft.com/en-us/magazine/ee310029.aspx

Datos en MongoDB

Probar en linea http://www.mongodb.org

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

Cliente de linea Mongo.exe

Primer ejemplo Creando documentos y grabando

Consultas Query “by example” Query con operadores

Ejemplo en C#

Otro modelo: Graph Neo4j http://www.infoq.com/articles/graph-nosql-neo4j

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

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

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