Date post: | 22-Nov-2014 |
Category: |
Technology |
Upload: | mongodb |
View: | 3,200 times |
Download: | 1 times |
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, ”[email protected]”, LAST_INSERT_ID() ), ( NULL, “[email protected]”, LAST_INSERT_ID() );COMMIT;
MongoDBdb.contacts.save( { userName: “joeblow”, emailAddresses: [ “[email protected]”, “[email protected]” ] } );
60
MongoDB es fácil de usar
MySQLSTART TRANSACTION;INSERT INTO contacts VALUES (NULL, ‘joeblow’);INSERT INTO contact_emails VALUES ( NULL, ”[email protected]”, LAST_INSERT_ID() ), ( NULL, “[email protected]”, LAST_INSERT_ID() );COMMIT;
MongoDBdb.contacts.save( { userName: “joeblow”, emailAddresses: [ “[email protected]”, “[email protected]” ] } );
• 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