1

Introducción al NoSQL y MongoDB

13 de septiembre, 2012

Robert Stam

2

• 1970's Aparecen las bases de datos relacionales– El almacenamiento es costoso– Los datos se normalizan– El almacenamiento es abstraído de la

aplicación

Un poco de historia

3

• 1970's Aparecen las bases de datos relacionales– El almacenamiento es caro– Los datos se normalizan– El almacenamiento es abstraído de la

aplicación

• 1980's Aparecen versiones comerciales de las RDBMS– Modelo cliente/servidor– SQL emerge como estándar

Un poco de historia

4

• 1970's Aparecen las bases de datos relacionales– El almacenamiento es caro– Los datos se normalizan– El almacenamiento es abstraído de la

aplicación

• 1980's Aparecen versiones comerciales de las RDBMS– Modelo cliente/servidor– SQL emerge como estándar

• 1990's Las cosas empiezan a cambiar– Cliente/servidor => arquitectura 3-niveles– Aparecen el internet y la web

Un poco de historia

5

• 2000's Web 2.0– Aparece "Social Media"– Aceptación de E-Commerce– Continuan bajando precios de HW– Incremento masivo de datos coleccionados

Un poco de historia

6

• 2000's Web 2.0– Aparece "Social Media"– Aceptación de E-Commerce– Continuan bajando precios de HW– Increment masivo de datos coleccionados

• Resultado– Requerimiento continuo para escalar dramáticamente– ¿Cómo podemos escalar?

Un poco de historia

7

OLTP / operational

BI / reporting

Bases de datos entre 2000 - 2010

+ transacciones complejas+ datos tabulares+ consultas ad hoc- O<->R mapeo es difícil- problemas de velocidad y escalabilidad- no es muy ágil

8

OLTP / operational

BI / reporting

Bases de datos entre 2000 - 2010

+ transacciones complejas+ datos tabulares+ consultas ad hoc- O<->R mapeo es difícil- problemas de velocidad y escalabilidad- no es muy ágil

+ consultas ad hoc+ SQL como protocolo estándar entre clientes y servidores+ crece horizontalmente mejor que las bases de datos operacionales- algunos limites de escalabilidad - esquemas rígidos- no es en tiempo real, pero funciona bien con cargas masivas en horas de la madrugada

9

OLTP / operational

BI / reporting

Bases de datos entre 2000 - 2010

+ transacciones complejas+ datos tabulares+ consultas ad hoc- O<->R mapeo es difícil- problemas de velocidad y escalabilidad- no es muy ágil

+ consultas ad hoc+ SQL como protocolo estándar entre clientes y servidores+ crece horizontalmente mejor que las bases de datos operacionales- algunos limites de escalabilidad - esquemas rígidos- no es tiempo real, pero funciona bien con cargas masivas en horas de la madrugada

Menos problemas aquí

10

OLTP / operational

BI / reporting

Bases de datos entre 2000 - 2010

+ transacciones complejas+ datos tabulares+ consultas ad hoc- O<->R mapeo es difícil- problemas de velocidad y escalabilidad- no es muy ágil

+ consultas ad hoc+ SQL como protocolo estándar entre clientes y servidores+ crece horizontalmente mejor que las bases de datos operacionales- algunos limites de escalabilidad - esquemas rígidos- no es tiempo real, pero funciona bien con cargas masivas en horas de la madrugada

Menos problemas aquí Más problemas aquí

11

OLTP / operational

BI / reporting

cacheo

Archivos

planos

Particionamiento al nivel de la aplicación

Bases de datos entre 2000 - 2010

+ transacciones complejas+ datos tabulares+ consultas ad hoc- O<->R mapeo es difícil- problemas de velocidad y escalabilidad- no es muy ágil

+ consultas ad hoc+ SQL como protocolo estándar entre clientes y servidores+ crece horizontalmente mejor que las bases de datos operacionales- algunos limites de escalabilidad - esquemas rígidos- no es tiempo real, pero funciona bien con cargas masivas en horas de la madrugada

12

• Metodología de desarrollo ágil• Ciclos de desarrollo cortos• Constante evolución de

requerimientos• Flexibilidad de diseño

Desarrollo de software

13

• Metodología de desarrollo ágil• Ciclos de desarrollo cortos• Constante evolución de

requerimientos• Flexibilidad de diseño

• Esquema relacional• Difícil de evolucionar

• Migraciones lentas y difíciles• En sincronía con la aplicación

• Pocos desarrolladores interactúan directamente con la base de datos

Desarrollo de software

14

Soluciones parciales

15

Soluciones parciales

16

Necesidades reales

• Escalabilidad horizontal• Más resultados en tiempo real• Desarrollo más veloz• Modelo de datos flexible• Bajo costo inicial• Bajo costo de operación

17

Relacional vs

No-relacional

¿Qué es NoSQL?

18

Bases de datos en el 2012

Escalableno-

relacional (“nosql”)

OLTP / operational

BI / reporting

+ velocidad y escalabilidad- consultas ad hoc limitadas- no son muy transaccionales- no usan SQL/no hay estándares+ se acoplan bien al model OO+ ágiles

19

¿Qué es NoSQL?

La próxima generación de bases de datos no-relacionales

Una colección de productos muy diferentes• Diferentes modelos de datos (no-relacionales)• La mayoría no usan SQL para las consultas• No requieren un esquema predefinido• Algunos permiten estructuras de datos

flexibles

20

• Relacional • Key-Value• Documentos• XML• Grafos• Columnas

Relacional vs NoSQL

21

• Relacional

• ACID• (atomicity, consistency,

isolation, durability)

• Key-Value• Documentos• XML• Grafos• Columnas

• BASE• (basically available, soft

state, eventual consistency)

Relacional vs NoSQL

22

• Relacional

• ACID

• Confirmación en 2 fases (two-phase commit)

• Key-Value• Documentos• XML• Grafos• Columnas

• BASE

• Transacciones atómicas al nivel de documentos

Relacional vs NoSQL

23

• Relacional

• ACID

• Confirmación en 2 fases (two-phase commit)

• Uniones (joins)

• Key-Value• Documentos• XML• Grafos• Columnas

• BASE

• Transacciones atómicas al nivel de documentos

• No hay uniones (joins)

Relacional vs NoSQL

24

Productos principales NoSQL

25

• Cantidad de transacciones

• Confiabilidad• Mantenimiento• Facilidad de uso• Escalabilidad• Costo

Factores determinantes

26

MongoDB: Introducción

27

Breve historia de MongoDB

• Diseñado y desarrollado por los fundadores de DoubleClick, ShopWiki, GILT Groupe, etc…

• Programación empieza a fines del 2007

• Primer sitio en producción: marzo 2008 businessinsider.com

• Código abierto – AGPL, escrito en C++

• Versión 0.8 – primera versión oficial febrero 2009

• Versión 1.0 – agosto 2009

• Versión 2.0 – septiembre 2011

• Versión 2.2 – agosto 2012

28

MongoDBObjetivos de diseño

29

MongoDB: NoSQL, alto rendimiento, escalable

30

• Orientado a documentos• Basado en documentos JSON• Esquema flexible

• Arquitectura escalable• Auto-sharding• Replicación y alta disponibilidad

• Características importantes• Índices secundarios• Lenguaje de consulta (consultas ad hoc)• Map/Reduce (agregación)

MongoDB: NoSQL, alto rendimiento, escalable

31

Documentos JSON• Modelo de datos poderoso y flexible• Conversión transparente de objetos en la aplicación (OO) a documentos JSON• Flexibilidad para datos dinámicos• Mejor localidad de datos

32

Ejemplo de esquema relacional

33

{ _id : ObjectId("4e2e3f92268cdda473b628f6"),title : “Too Big to Fail”,when : Date(“2011-07-26”),author : “joe”,text : “blah”

}

Ejemplo de documento JSON

34

{ _id : ObjectId("4e2e3f92268cdda473b628f6"),title : “Too Big to Fail”,when : Date(“2011-07-26”),author : “joe”,text : “blah”,tags : [“business”, “news”, “north america”]

}

> db.posts.find( { tags : “news” } )

Ejemplo de documento JSON

35

{ _id : ObjectId("4e2e3f92268cdda473b628f6"),title : “Too Big to Fail”,when : Date(“2011-07-26”),author : “joe”,text : “blah”,tags : [“business”, “news”, “north america”],votes : 3,voters : [“dmerr”, “sj”, “jane” ]

}

Ejemplo de documento JSON

36

{ _id : ObjectId("4e2e3f92268cdda473b628f6"),title : “Too Big to Fail”,when : Date(“2011-07-26”),author : “joe”,text : “blah”,tags : [“business”, “news”, “north america”],votes : 3,voters : [“dmerr”, “sj”, “jane” ],comments : [

{ by : “tim157”, text : “great story” },{ by : “gora”, text : “i don’t think so” },{ by : “dmerr”, text : “also check out...” }

]}

Ejemplo de documento JSON

37

{ _id : ObjectId("4e2e3f92268cdda473b628f6"),title : “Too Big to Fail”,when : Date(“2011-07-26”),author : “joe”,text : “blah”,tags : [“business”, “news”, “north america”],votes : 3,voters : [“dmerr”, “sj”, “jane” ],comments : [

{ by : “tim157”, text : “great story” },{ by : “gora”, text : “i don’t think so” },{ by : “dmerr”, text : “also check out...” }

]}

> db.posts.find( { “comments.by” : “gora” } )> db.posts.ensureIndex( { “comments.by” : 1 } )

Ejemplo de documento JSON

38

Tiempo de búsqueda en disco y velocidad de lectura

Búsqueda = 5+ ms Lectura = súper rápido

Post

Author Comment

39

Post

Author

CommentCommentCommentCommentComment

Tiempo de búsqueda en disco y velocidad de lectura

40

MongoDB es una base de datos de propósito general

• Índices secundarios• Consultas dinámicas• Orden de los resultados (sort)• Operaciones poderosas: update, upsert• Funciones para agregaciones• Viable como almacenamiento primario

41

Escalabilidad

• Escalabilidad lineal• Alta disponibilidad• Incrementar capacidad sin sacar la

aplicación de servicio• Transparente a la aplicación

42

Alta disponibilidad

Conjunto de réplicas (replica sets)• Alta disponibilidad/transferencia automática• Redundancia de los datos• Recuperación en caso de desastre• Transparente a la aplicación• Posibilidad de mantenimiento sin sacar la

aplicación de servicio

43

Replica Sets

AsynchronousReplication

44

Replica Sets

AsynchronousReplication

45

Replica Sets

AsynchronousReplication

46

Replica Sets

47

Replica Sets

Elección automática

48

Replica Sets

49

Escalabilidad lineal• Incrementar capacidad sin sacar la aplicación de servicio• Transparente a la aplicación

50

Escalabilidad lineal• Incrementar capacidad sin sacar la aplicación de servicio• Transparente a la aplicación• Particiones basados en rangos de valores• Particionamiento y balanceo automático

51

Sharding

mongod

Escalabilidad para escribir

Key Range0..100

52

Sharding

Escalabilidad para escribir

mongod mongod

Key Range0..50

Key Range51..100

53

Sharding

mongod mongodmongod mongod

Key Range0..25

Key Range26..50

Key Range51..75

Key Range76.. 100

Escalabilidad para escribir

54

Primary

Secondary

Secondary

Primary

Secondary

Secondary

Primary

Secondary

Secondary

Primary

Secondary

Secondary

Key Range0..25

Key Range26..50

Key Range51..75

Key Range76.. 100

Sharding

55

Primary

Secondary

Secondary

Primary

Secondary

Secondary

Primary

Secondary

Secondary

Primary

Secondary

Secondary

Key Range0..25

Key Range26..50

Key Range51..75

Key Range76.. 100

MongoS

Aplicación

56

Primary

Secondary

Secondary

Primary

Secondary

Secondary

Primary

Secondary

Secondary

Primary

Secondary

Secondary

Key Range0..25

Key Range26..50

Key Range51..75

Key Range76.. 100

MongoS MongoS MongoS

Aplicación

57

Primary

Secondary

Secondary

Primary

Secondary

Secondary

Primary

Secondary

Secondary

Primary

Secondary

Secondary

Key Range0..25

Key Range26..50

Key Range51..75

Key Range76.. 100

MongoS MongoS MongoS

Config

Config

Config

Aplicación

58

MongoDB es fácil de administrar• Pocas opciones para configurar• La configuración estándar funciona bien• Fácil de instalar y administrar

59

MongoDB es fácil de usar

MySQLSTART TRANSACTION;INSERT INTO contacts VALUES (NULL, ‘joeblow’);INSERT INTO contact_emails VALUES ( NULL, ”joe@blow.com”, LAST_INSERT_ID() ), ( NULL, “joseph@blow.com”, LAST_INSERT_ID() );COMMIT;

MongoDBdb.contacts.save( { userName: “joeblow”, emailAddresses: [ “joe@blow.com”, “joseph@blow.com” ] } );

60

MongoDB es fácil de usar

MySQLSTART TRANSACTION;INSERT INTO contacts VALUES (NULL, ‘joeblow’);INSERT INTO contact_emails VALUES ( NULL, ”joe@blow.com”, LAST_INSERT_ID() ), ( NULL, “joseph@blow.com”, LAST_INSERT_ID() );COMMIT;

MongoDBdb.contacts.save( { userName: “joeblow”, emailAddresses: [ “joe@blow.com”, “joseph@blow.com” ] } );

• Existen interfaces (drivers) para docenas de lenguajes de programación

• Una relación natural entre objetos (OO) y documentos

61

MongoDB ejemplos de uso

62

MongoDB puede ser usado para muchas aplicaciones

Manejo de datos de usuarios Procesamiento de datos de alto volúmen

Manejo de contenido Inteligencia de operaciones E-Commerce

63

Analyze a staggering amount of data for a system build on continuous stream of high-quality text pulled from online sources

Adding too much data too quickly resulted in outages; tables locked for tens of seconds during inserts

Initially launched entirely on MySQL but quickly hit performance road blocks

Problem

Life with MongoDB has been good for Wordnik. Our code is faster, more flexible and dramatically smaller. Since we don’t spend time worrying about the database, we can spend more time writing code for our application. -Tony Tam, Vice President of Engineering and Technical Co-founder

Migrated 5 billion records in a single day with zero downtime

MongoDB powers every website request: 20m API calls per day

Ability to eliminate memcached layer, creating a simplified system that required fewer resources and was less prone to error.

Why MongoDB Reduced code by 75%

compared to MySQL Fetch time cut from 400ms to

60ms Sustained insert speed of 8k

words per second, with frequent bursts of up to 50k per second

Significant cost savings and 15% reduction in servers

Impact

Wordnik uses MongoDB as the foundation for its “live” dictionary that stores its entire text corpus – 3.5T of data in 20 billion records

64

Intuit hosts more than 500,000 websites

wanted to collect and analyze data to recommend conversion and lead generation improvements to customers.

With 10 years worth of user data, it took several days to process the information using a relational database.

Problem

MongoDB's querying and Map/Reduce functionality could server as a simpler, higher-performance solution than a complex Hadoop implementation.

The strength of the MongoDB community.

Why MongoDB In one week Intuit was able to

become proficient in MongoDB development

Developed application features more quickly for MongoDB than for relational databases

MongoDB was 2.5 times faster than MySQL

Impact

Intuit relies on a MongoDB-powered real-time analytics tool for small businesses to derive interesting and actionable patterns from their customers’ website traffic

We did a prototype for one week, and within one week we had made big progress. Very big progress. It was so amazing that we decided, “Let’s go with this.” -Nirmala Ranganathan, Intuit

65

Managing 20TB of data (six billion images for millions of customers) partitioning by function.

Home-grown key value store on top of their Oracle database offered sub-par performance

Codebase for this hybrid store became hard to manage

High licensing, HW costs

Problem

JSON-based data structure Provided Shutterfly with an

agile, high performance, scalable solution at a low cost.

Works seamlessly with Shutterfly’s services-based architecture

Why MongoDB 500% cost reduction and 900%

performance improvement compared to previous Oracle implementation

Accelerated time-to-market for nearly a dozen projects on MongoDB

Improved Performance by reducing average latency for inserts from 400ms to 2ms.

Impact

Shutterfly uses MongoDB to safeguard more than six billion images for millions of customers in the form of photos and videos, and turn everyday pictures into keepsakes

The “really killer reason” for using MongoDB is its rich JSON-based data structure, which offers Shutterfly an agile approach to develop software. With MongoDB, the Shutterfly team can quickly develop and deploy new applications, especially Web 2.0 and social features. -Kenny Gorman, Director of Data Services

66

Miles de organizaciones están usando MongoDB

67

Una base de datos de código abierto y de alto rendimiento