Introducción a NoSQL

1. Introducción a NoSQL Angel “Java” Lopezhttp://www.ajlopez.comhttp://www.msmvps.com/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 • Anteriores a las relacionales • Hoy, relacionales en todos lados • Brillan: • Manejo de conjuntos • Transacciones • Seguridad • ACID

5. ACID • 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 • 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 Tome DOS

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

11. Un nodo actualiza el valor N1 A V1 N2 B V0

12. El valor se traslada al otro nodo N1 A V1 N2 B V1

13. Nodo 2 lee el valor N1 A V1 N2 B V1

14. El problema de tener Partition Tolerance N1 A V1 N2 B V0

15. La transacción 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 • 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

19. BASE • 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 Sector 1 Sector 2 Sector 3

23. Implementaciones • 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 • 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 • 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

27. Cientos de Servicios en Amazon

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

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:www.c-span.org", "CNN"); r1.Delete("anchor:www.abc.com"); 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 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: W2Eventual: W1, W2, o nada Cliente 1 Timeline Cliente 2 W2 R2 color: ruby Consistent: W2Eventual: W1, W2, o nada

41. Consistent vs Eventually Consistent Read R1 W1 color: red Consistent: W1 oW2Eventual: W1, W2, o nada Cliente 1 Timeline Cliente 2 W2 R2 color: ruby Consistent: W1 o W2Eventual: W1, W2, o nada

42. Consistent vs Eventually Consistent Read W1 R1 color: red Consistent: W1 oW2Eventual: W1, W2, o nada Cliente 1 Timeline Cliente 2 R2 W2 Consistent: W1 o W2Eventual: 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 • 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: 14491847880 Buscar por Id de Usuario: int

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