1 / 74

Introducción a NoSQL

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

taro
Download Presentation

Introducción a NoSQL

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related