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
– Anteriores a las relacionales
• Hoy, relacionales en todos lados
• Brillan:
– Manejo de conjuntos
– Transacciones
– Seguridad
– ACID
ACID
• Atomic
– Todo o
nada
• Consistent
– Estado
lógico
consist
ente
• Isolated
– Concurre
ncia
sin
interfer
encia
• Durable
 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
 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
 Teorema CAP
-C o n siste n cy
-To d o o N a d a
-S ih a y ré p lica s,
e n e lm ism o
To m e e sta d o
DOS
-A va ila b ility
-S ie m p re
d isp o n ib le
-S ica e u n a
ré p lica ,
sig u e o tra
-Pa rtitio n -
To le ra n ce
 Dos nodos, el valor v0
N1

A V0

N2

B V0
Un nodo actualiza el valor
N1

A V1

N2

B V0
El valor se traslada al otro
nodo
N1

A V1

N2

B V1
 Nodo 2 lee el valor
N1

A V1

N2

B V1
El problema de tener Partition
Tolerance
N1

A V1

N2

B V0
 La transacción
A1: Write

Sync

A2: Read

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

 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
– 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/m
arissa-mayer-at-web-20.html
BASE
• Basic
• Available
• Soft state
• Eventually
consisten
t
 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
 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
Pro ce so R e g istro s
D a to s
D a to s

A rch ivo
S e cto r 1
S e cto r 2
S e cto r 3
 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
 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
 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
 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
Cientos de
Servicios
en Amazon
 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
manej
ar 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
 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

Ta b le * T =
O p e n O rD ie (" / b ig ta b le / w e b / w e b ta b le " );
// Write a new anchor and delete an old
a n ch o r
R o w M u ta tio n r1 ( T , " co m . cn n . w w w " );
r1 . S e t(" a n ch o r: w w w . c - sp a n . o rg " , " C N N " );
r1 . D e le te (" a n ch o r: w w w . a b c . co m " );
O p e ra tio n o p ;
A p p ly (&o p , &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
va lu e = sto re . g e t( ke y )
sto re . p u t( ke y , va lu e )
sto re . d e le te ( ke y )

• 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
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

W 1 R1

co lo r: re d C o n siste n t: W 2
C lie n te 1 E ve n tu a l: W 1 , W 2 , o n a d a
Tim e lin e
C lie n te 2 W 2 R2

co lo r: ruby C o n siste n t: W 2
E ve n tu a l: W 1 , W 2 , o n a d a
 Consistent vs Eventually
Consistent Read

W 1 R1

co lo r: re d C o n siste n t: W 1 o W 2
E ve n tu a l: W 1 , W 2 , o n a d a
C lie n te 1
Tim e lin e
C lie n te 2 W 2 R2

co lo r: rubyC o n siste n t: W 1 o W 2
E ve n tu a l: W 1 , W 2 , o n a d a
 Consistent vs Eventually
Consistent Read

W 1 R1

co lo r: re d C o n siste n t: W 1 o W 2
C lie n te 1 E ve n tu a l: W 1 , W 2 , o n a d a
Tim e lin e
C lie n te 2 R2
W 2
C o n siste n t: W 1 o W 2
co lo r: ruby
E ve n tu a l: W 1 , W 2 , o n a d a
 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
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

S e le a g re g a n m a p a s d e co lu m n a s
 Modelo de Datos
• SuperColumnFamily
– Como ColumnFamily pero contiene
SuperColumns
• KeySpace
– Contiene varias familias (tablas)
– Generalmente uno por aplicación
Un caso: Twitter
 Un Tweet
B u sca r p o r Id : 1 4 4 9 1 8 4 7 8 8 0

B u sca r p o r Id d e U su a rio : in t
 Implementación original

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

E scrib ir B a se
M e m ca ch e d
Le e r
M e m ca ch e d
R a ils
M a ste r
M e m ca ch e d

S la ve S la ve
 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:
– 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 likePlankton "
" Author " : " Rusty "
" PostedDate " : " 5 / 23 / 2006 "
" Tags " : [ " plankton " , " baseball " , " decisions " ]
" Body " : " I decided today that I don't likebaseball .
I like p la n kto n ."
 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
 MongoDB
• Open Source
• Orientada a Documentos estilo JSON
• Replicación y Disponibilidad
• Auto-Sharding
• Rico modelo de queries
• Documentos con documentos
embebidos o referenciados
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”

Q u e ry co n o p e ra d o re s
Ejemplo en C#
Otro modelo: Graph Neo4j
 Nodos y Relaciones

N o d e n e o = g ra p h d b . cre a te N o d e ();
n o d e . se tPro p e rty (" n a m e " , " N e o " );
N o d e m o rp h e u s =
g ra p h d b . cre a te N o d e ();
m o rp h e u s. se tPro p e rty (" n a m e " ,
" Morpheus " );
n e o . cre a te R e la tio n sh ip To ( morpheus ,
K N O W S );
De vuelta: Modelo de Datos

Key-Value

Column
Tamaño

Document

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?