Este documento introduce las bases de datos NoSQL. Explica que las bases de datos relacionales no son adecuadas para ciertas necesidades como la escalabilidad horizontal, los resultados en tiempo real y la agilidad en el desarrollo. Las bases de datos NoSQL se desarrollaron para satisfacer estas necesidades al permitir un crecimiento horizontal, ser de código abierto y no requerir esquemas. El documento luego describe varios tipos de bases de datos NoSQL como clave-valor, columnar y documentales, así como conceptos como replicación, sharding y MapReduce.

1. INTRODUCCIÓN A NOSQL
Resum Executiu 東京‘
TOKIOTA

2. Base de datos relacionales
 Nacen en los años 70 porque
 Almacenamiento es caro
 Los datos se normalizan
 El almacenamiento se separa de la aplicación
 Ventajas
 Único modelo disponible por muchos años
 Integración
 Control de concurrencia
東京‘ TOKIOTA Presentación de compañía

3. Base de datos relacionales
 Desventajas
 No esta preparado para cluster
 Hardware caro
 Coste de licencias
 Limitar el desarrollo haciéndolo poco ágil
 Con lógica de la aplicación
 Join
 Nuevo requisitos de escalabilidad continua
東京‘ TOKIOTA Presentación de compañía

4. Desarrollo de software
 Metodologías ágiles
 Ciclos de desarrollo cortos
 Constante evolución de requerimientos
 Flexibilidad de diseño
 Pero las bases de datos relacionales
 Difíciles
de evolucionar (migrar)
 Pocos desarrolladores interactúan con la base de datos
 Tienen un modelo diferente al que se usa en el
desarrollo
東京‘ TOKIOTA Presentación de compañía

5. Necesidades reales
 Escalar horizontalmente
 Resultados en tiempo real
 Agilidad en el desarrollo
 Modelo de datos flexibles
 Bajo coste
東京‘ TOKIOTA Presentación de compañía

6. Base de datos NoSQL
 Nacen por las necesidades:
 No usan el modelo relacional
 Se ejecutan bien sobre clusters
 Crecen horizontalmente (sharding)
 Open-source
 Sin schemas
東京‘ TOKIOTA Presentación de compañía

7. Base de datos NoSQL
 Ventajas
 Veloces
 Escalables
 Se acoplan al modelo de objetos
 Agiles
 Desventajas
 No son transaccionales – tampoco lo necesitan
 No son ACID, son BASE
 Consultas
Ad-hoc limitadas
 Modelo de escritura y modelo de lectura
東京‘ TOKIOTA Presentación de compañía

8. Alta disponibilidad – Replica sets
 Alta disponibilidad
 Redundancia de datos
 Recuperación en caso de desastre
 Transparente a la aplicación
 En caliente
東京‘ TOKIOTA Presentación de compañía

9. Escribir
Leer
Primaria
Driver
Replicas asíncronas
Leer Secundaria
Leer Secundaria
東京‘ TOKIOTA Presentación de compañía

10. Recuperación ante caidas
Escribir
Leer
Primaria
Driver
Leer Secundaria
Leer Secundaria
東京‘ TOKIOTA Presentación de compañía

11. Recuperación ante caidas
Primaria
Escribir
Driver
Leer Primaria
Leer Secundaria
東京‘ TOKIOTA Presentación de compañía

12. Recuperación ante caidas
Leer Secundaria
Primaria
Escribir
Driver
Leer Primaria
Leer Secundaria
東京‘ TOKIOTA Presentación de compañía

13. Sharding
data{a , b}
Key[0...100]
Nodo Clave
V 0 … 15
W 16 … 45
X 46 … 60
Y 61 … 75 V W X Y Z
Z 76 … 100
東京‘ TOKIOTA Presentación de compañía

14. Sharding - búsquedas
Nodo Clave
find{a=30} a 0 … 15
b 16 … 45
c 46 … 60
d 61 … 75
e 76 … 100
La query se envía a un solo nodo
東京‘ TOKIOTA Presentación de compañía

15. Sharding - búsquedas
Nodo Clave
find{20>a<50} a 0 … 15
b 16 … 45
c 46 … 60
d 61 … 75
e 76 … 100
La query se envía a mas de un nodo
東京‘ TOKIOTA Presentación de compañía

16. Sharding - búsquedas
Nodo Clave
find{b=hola} a 0 … 15
b 16 … 45
c 46 … 60
d 61 … 75
e 76 … 100
Tabla-Scan es igual de malo
東京‘ TOKIOTA Presentación de compañía

17. Sharding - búsquedas
Nodo Clave
Crear índice sobre b a 0 … 15
find{b=hola} b 16 … 45
c 46 … 60
d 61 … 75
e 76 … 100
Penaliza un poco el coste de comunicación
東京‘ TOKIOTA Presentación de compañía

18. Sharding - búsquedas
Nodo Clave
find{b=hola, a=51} a 0 … 15
b 16 … 45
c 46 … 60
d 61 … 75
e 76 … 100
Se envía solo a un nodo
東京‘ TOKIOTA Presentación de compañía

19. Sharding - búsquedas
Nodo Clave
find{b=hola, a=51} a 0 … 15
b 16 … 45
c 46 … 60
d 61 … 75
e 76 … 100
Se envía solo a un nodo
東京‘ TOKIOTA Presentación de compañía

20. Sharding – Order by …
東京‘ TOKIOTA Presentación de compañía

21. Velocidad de lectura
東京‘ TOKIOTA Presentación de compañía

22. Tipos de NoSQL y uso
Tipo Uso Productos
Key - Value Cache Redis
MemCached
Colum-Family Clave + multiples Cassandra
columnas Amazon Simple DB
Google BigTable
HBase
Documentales Guardar objetos enteros MongoDB
con una clave RavenDB
CrounchDB
Azure Table Storage
Grapho Guardan nodos y Neo4j
relaciones entre nodos
東京‘ TOKIOTA Presentación de compañía

23. Key-Value
 Una única clave que apunta a un único ítem.
東京‘ TOKIOTA Presentación de compañía

24. Column-Family
 Es el mas parecido a SQL. Mantiene la información
separada en columnas.
東京‘ TOKIOTA Presentación de compañía

25. Documentos
{ "customer": { "id": 1, "name": "Martin",
"billingAddress": [{"city": "Chicago"}],
"orders": [{"id":99, "customerId":1,
"orderItems":[ {"productId":27, "price": 32.45}],
"shippingAddress":[{"city":"Chicago"}]
"orderPayment":[{
"ccinfo":"1000-1000-1000-1000",
"txnId":"abelif879rft",
"billingAddress": {"city": "Chicago"}
}],
}]
}
}

26. Grafos
 Se representa por nodos que están unidos por
relaciones, donde ambos tienen propiedades

27. ¿Qué pasa con BI?
 ¿Como hago vistas o DW?
Aplicar una función por cada elemento de una
colección
Combina los elementos usando una
operación

28. Ejemplo, cuanto he vendido de cada producto

29. Beneficios de MapReduce
 Preparado para gran volumen de información
 Pero puedo hacer pruebas con pequeñas muestras
 Tolerable a fallos
 Piso los datos porque los recalculo
 Seguro ante problemas de threading
 No tocan la información de entrada

30. Implementaciones
 La implementación mas grande de Cassandra tiene
300 TB repartidos en 400 ordenadores
 Disney tiene los datos de usuarios y juegos
repartidos en 1400 instancias de MongoDB
 Para un listado mas detallado visitar
http://www.mongodb.org/display/DOCS/Producti
on+Deployments

31. MUCHAS GRACIAS POR TU CONFIANZA
Resum Executiu 東京‘
TOKIOTA