2. Un poco de historia
• Las bases de datos relacionales eran la única opción
• Las aplicaciones web tienen picos
• Especialmente las aplicaciones transaccionales (e-commerce)
• Los desarrolladores encontraron en memchached principalmente la solución a
sus problemas de escalabilidad
3. Escalando verticalmente
• Las bases de datos no están diseñadas para tener un esquema de datos
distribuídos
• Cuando la concurrencia aumenta la “única” manera es escalar verticalmente
• Después entontraron soluciones provistas por los proveedores de base de datos
que brindaban soluciones de escalabilidad (master-slave/sharding)
• Conocido como ‘scaling out’ o ‘horizontal scaling’
4. Escalando Base de datos – Master/Slave
• Master-Slave
• Todos las escrituras van al master, todas las lecturas se realizan sobre los slaves
• Los reads críticos pueden ser incorrectos ya que las escrituras no se propagan
inmediatamente
• Los tamaños de los data sets pueden plantear problemas ya que los master necesitan
duplicar información hacia lo slaves.
5. Transacciones – Propiedades ACID
• Atomic – Todo el trabajo en una transacción se completa o nada de la
transacción se realiza
• Consistent – Una transacción transforma la base de datos desde un
estado consistente hacia otro estado consistente. La consistencia está
definida en términos de restricciones.
• Isolated – Los resultados realizados por una transacción no son
visibles hasta que la transacción se complete (commit).
• Durable – Los resultados de una transacción terminada sobrevive a
fallos
6. Sistemas distribuidos
• CAP “Theorem”
• Consistency: Todos los clientes ven la misma información siempre
• Availability: Cada cliente puede siempre escribir y leer
• Partition tolerance: El Sistema funciona bien aunque tengamos la
información distribuída en particiones y alguna partición sufre alguna
anomalía
• “CAP theorem” dice que solo podés tener 2 de estas condiciones en un
Sistema distribuído
8. Propiedades – Propiedades BASE
• Acrónimo opuesto a ACID
• Basically Available,
• Soft state,
• Eventually Consistent
• Características
• Poca consistencia – los datos leidos pueden no ser los correctos
• Disponibilidad primero
• El mayor esfuerzo por brindar la mejor solución
• Simples y rápidos
In partitioned databases,
trading some consistency for availability
can lead to dramatic improvements in scalability.
Dan Pritchett, Ebay
9. La aparición de “NoSQL” y sus características
• Grandes volúmenes de información
• Google’s “big tables”
• Replicación y distribución escalable
• Potencialmente miles de máquinas
• Potencialmente distribuídas en todo el mundo
• Las consultas necesitan retornar respuestas rápidamente
• Sistemas con muchísimas consultas y pocos updates
• Inserciones y actualizaciones asincrónicas
• Sin un schema definido
• Responden al esquema transaccional BASE
• Responden al teorema CAP
• Principalmente de código abierto
10. Una definición de NoSQL
From www.nosql-database.org:
Next Generation Databases mostly addressing some of the points: being non-
relational, distributed, open-source and horizontal scalable. The original
intention has been modern web-scale databases. The movement began early
2009 and is growing rapidly. Often more characteristics apply as: schema-free,
easy replication support, simple API, eventually consistent / BASE (not ACID), a
huge data amount, and more.
11. Tipos de base de datos NoSQL
Existen varios tipos de base de datos del tipo NoSQL:
• Column Store – Cada porción guardada contiene datos de una sola
columna
• Document Store – guarda un documento organizado por tags
• Key-Value Store – guarda un valor por cada key
• Graph Databases – Persisten relaciones entre nodos
12. NoSQL: Column Store
• Cada porción de almacenamiento contiene información de una sola
columna
• Ejemplos: Hadoop/Hbase
• http://hadoop.apache.org/
• Yahoo, Facebook
13. NoSQL: Key/Value store
• Una table hash de keys
• Los valores se almacenan en cada uno de esos keys
• Rápido acceso, sencillo de administrar y fácil de usar
• Ejemplos:
• Voldermont/redis/memcached
14. NoSQL: Graph
• Cada nodo guarda información de relacionamiento con otros nodos
(grado de cercanía, etc)
• Ejemplos: neo4j
15. NoSQL: Document store
• Cada key es un documento que puede contener a su vez otros
documentos (subdocumentos)
• Ejemplos:
• CouchDB
• http://couchdb.apache.org/
• BBC
• MongoDB
• http://www.mongodb.org/
• Foursquare, Shutterfly
16. Qué es mongodb (10gen)
• MongoDB (sacado de mongodb.com):
Es una base de datos para las aplicaciones de hoy, innovativa, de rápido
time to market, que escala globalmente, fácil de operar y seguro.
17. Beneficios
• Rápido e iterativo desarrollo:
• La flexibilidad de los modelos de datos de mongodb y la posibilidad de tener
esquemas dinámicos hacen que sea sencillo para los desarrolladores crear y
evolucionar aplicaciones. El provisionamiento automático hacen que la integración y
evolución de aplicaciones sea realmente sencilla.
• Modelo de datos flexible:
• Los documentos de mongo pueden almacenar y combinar datos de cualquier tipo de
estructura dentro de una misma colección
• El acceso a la información es MUY sencilla, pocas condiciones y bien detalladas
• Los esquemas de datos se pueden modificar dinámicamente sin downtime.
• Menos inversión de tiempo pensando como persistir información y más trabajando
con los mismos
• Operaciones del tipo ALTER_TABLE o peor rediseñar los esquemas desde el principio
18. +Beneficios
• Multi-Datacenter Scalability.
• MongoDB puede escalar dentro de un datacenter o a través de multiples datacenters
distribuídos proveyendo nuevos niveles de disponibilidad y escalabilidad. A medida
que las estructuras son más grandes en términos de datos y niveles de acceso,
MongoDB escala rápidamente sin downtime y sin que uno tenga que modificar la
aplicación para que tome la nueva configuración.
• Conjunto integrado de funcionalidades
• Analísis, text search, datos geoespaciales, replicación global, hacen que uno pueda
usar mongodb como “solución” única para muchas aplicaciones del tipo real-time.
• Bajo TCO.
• MongoDB corre en servidores de tipo “commodity” y escala horizontalmente como
así verticalmente. Sin costo (open source) pero algunos beneficios si se quiere pagar
licenciamiento.
19. MondoDB Data Model
19
• Una instalación de MongoDB está compuesta por un
conjunto de base de datos. Una base de datos
contiene un conjunto de colecciones. Una colección
contiene un conjunto de documentos. Un document
es un conjunto de pares de key-value.
RDBMS MongoDB
Table
Row(s)
Index
Join
Partition
Partition Key
Collection
BSON (binary json)
Document
Index
Embedding & Linking
Shard
Shard Key
20. Reglas para crear documentos (estructuras de
datos)
• Regla 1: Todo documento si o si tiene que tener un _id
• Regla 2: Tamaño máximo de un documento 16 MB
21. Qué es un objeto JSON
{
"business_id": "rncjoVoEFUJGCUoC1JgnUA",
"full_address": "8466 W Peoria AvenSte 6nPeoria, AZ
85345",
"open": true,
"categories": ["Accountants", "Professional Services", "Tax
Services",],
"city": "Peoria",
"review_count": 3,
"name": "Peoria Income Tax Service",
"longitude": -112.241596,
"state": "AZ",
"stars": 5.0,
"latitude": 33.581867000000003,
"type": "business“
}
22. MongoDB Data Model
• MongoDB almacena documentos en una representación llamada
BSON (Binary JSON). Generalmente los documentos similares están
organizados como colecciones.
• Cada documento de MongoDB tiende a tener toda la información que
lo representa como un todo.
• Ej: data-model y blog (entradas, categorías, tags, usuarios, comentarios).
23. SQL Statement MongoDB commands
SELECT *
FROM table
db.collection.find()
SELECT *
FROM table
WHERE artist = ‘Nirvana’
db.collection.find({Artist:”Nirvana”})
SELECT*
FROM table
ORDER BY Title
db.collection.find().sort(Title:1)
DISTINCT .distinct()
GROUP BY .group()
>=, < $gte, $lt
Obteniendo información
24. Esquemas dinámicos
MONGODB RELATIONAL KEY-VALUE
Rich Data Model Yes No No
Dynamic Schema Yes No Yes
Typed Data Yes Yes No
Data Locality Yes No Yes
Field Updates Yes Yes No
Easy for Programmers Yes No Not When
Modelling Complex
Data Structures
25. Indices
• Indices como en cualquier base de datos es un mecanismo
importantísimo para el correcto procesamiento de información
• Uno puede definir índices de tipo unique, compuestos, para arrays,
con ttl, geoespaciales, de texto
• El optimizador de queries de mongo analiza y selecciona el índice más
eficiente. (explain al rescate)
• Mongodb puede llegar a utilizar más de un índice para optimizar una
consulta.
26. Tipos de consultas
• MongoDB soporta muchos tipos distintos de consultas y ofrece
frameworks que ayudan a cumplimentar sus debilidades. Además
mongodb (siempre que su driver lo soporte) puede devolver no
únicamente un documento completo, sino también subdocumentos)
• Consultas Key-value
• Consultas de rango
• Consultas Geoespaciales (con índices especiales)
• Consultas del tipo texto (con índices especiales)
• Aggregation Framework
• MapReduce
27. Consistencia y disponibilidad en MongoDB
Modelo Transaccional
• MongoDB proporciona las propiedades ACID a nivel de documento.
• Una o más propiedades pueden ser escritas en una sola operación,
incluyendo updates a multiple subdocumentos y elementos de un array. ACID
provisto por mongodb asegura la completa separación cuando uno
documento se está actualizando. Si un error se produce cuando se actualiza la
operación hace roll-back y siempre se obtiene una vista consistente del
documento.
• Con Write concerns nos permite definir como queremos asegurarnos que la
operación realmente se haya producido a distintos niveles.
28. IN-MEMORY Performance con ON-DISK
CAPACITY
• MongoDB hace uso extensivo de RAM para optimizar las operaciones
en la base de datos.
• Toda la información es manipulada y mapeada a través de memory-
mapped files.
• Leer desde memoria es mucho más rápido que leer de disco
• Muchas veces es suficiente con mongodb y no es necesario otro layer
de caching.
29. ALTA DISPONIBILIDAD - REPLICA SETS
• MongoDB puede mantener multiples copias de información llamada
replicasets usando mecanismos nativos de replicación. Una replica es
autónoma y previene downtime. Failover automático elimina las
necesidades de administradores de intervener manualmente.
• El número de replicas es configurable.
• Una operación sobre una replica puede devolver un ack cuando
determinada cantidad de replicasets devuelvan el OK de la operación.
30. ESCALABILIDAD: AUTO-SHARDING
• MongoDB prove escalabilidad horizontal utilizando una técnica
llamada sharding.
• Sharding distribuye información a lo largo del shar which is
transparent to applications. Sharding distributes data across multiple
physical partitions called shards. Sharding allows MongoDB
deployments to address the hardware limitations of a single server,
such as bottlenecks in RAM or disk I/O, without adding complexity to
the application. MongoDB automatically balances the data in the
cluster as the data grows or the size of the cluster increases or
decreases.
31. Seguridad
• Authentication. Built in o con integración con
LDAP, AD, Kerberos, etc
• Authorization. 2 tipos de roles: sobre los datos y
sobre las bases de datos.
• Auditoria. For regulatory compliance, security
administrators can use MongoDB's native audit
log to track access and administrative actions
taken against the database.
• Encripción. MongoDB data puede ser encriptada
tanto en transmission como en disco. Conexión
vía SSL.
35. Diferencias con el esquema tradicional de
diseño
• Tradicional
• No importa tu aplicación
• Solo importan los datos
• Unicamente relevante
durante el diseño
• Formas normales y
desnormalización para
performance
MongoDB
• Siempre dependerá de tu
aplicación
• No únicamente importan los
datos sino como serán usados
• Relevante durante toda la vida
útil de tu aplicación
36. Modelado de datos con mongodb
El diseño de esquema es evolucionario
• Diseño y desarrollo
• Implementación y monitoreo
• Modificaciones iterativas
37. 3 Componentes para diseñar los esquemas
1. La información que tu aplicación necesita
2. Cómo tu aplicación lee información
3. Cómo tu aplicación persiste información
38. Patrones de diseño comunes
Embeber para tener los datos a mano
Emb
// Contacto embebido
{"_id": 3,“nombre": “Perez, José",“CP": “1007",“telefonos": [ “011-4564-3456",
“011-4334-3411" ]}
Ref
// Contact document:
{"_id": 3,"nombre": "Perez, José", "CP": "1007"}
// Number documents:
{ "contacto_id": 3, “telefono": " 011-4564-3456"}
{ "contacto_id": 3, “telefono": "011-4334-3411"}
39. Patrones de diseño comunes
Referenciar para tener flexibilidad o necesidad
Emb
// post embebido
{"_id": "Primer Post", "author": "Juan", "text": "Arranco un blog que nunca continuaré",
"comments": [{ "author": "Pedro", "text": "Bienvenido!" },...]}
db.posts.find({“comments.author”: “Pedro”})
Ref
db.post esquema
{"_id": "Primer Post", "author": "Juan", "text": "Arranco un blog que nunca continuaré“}
db.comments esquema
{"_id": ObjectId(...),"post_id": “Primer Post","author": “Pedro","text": “Bienvenido! "}
db.comments.find({“comments.author”: “Pedro”})
• Límite 16 MB por documento y todo en RAM
• Documentos que crecen se mueven a nuevos lugares
44. MapReduce
Algo un poquito más complejo
var map = function () {
for (var i = 0; i< this.scores.length; i++){
var key = this.scores[i].type;
var value = { count:1, score: this.scores[i].score};
emit(key, value);
}}
var reduce = function(type, scores) {
reducedVal = { count: 0, score: 0.0 };
for (var idx = 0; idx < scores.length; idx++) {
reducedVal.count += scores[idx].count;
reducedVal.score += scores[idx].score;
}
return reducedVal;
var finalize = function (key, reducedVal) {
reducedVal.avg = reducedVal.score/reducedVal.count;
return reducedVal;
};
db.students.mapReduce( map, reduce,
{
out: { merge: "map_reduce_example" },
query: { name:
{ $gt: 'J' }
},
finalize: finalize
}
)
45. MapReduce
Troubleshooting Map-Reduce Functions
> var map = function (){emit(key, value)}
> var emit = function (key, value){print (key, tojson(value)}
> var doc = db.coll.findOne()
> doc
map.apply(doc)
var reduceFunction1 = function(keyCustId, valuesPrices){}
var myTestValues = [ 5, 5, 10 ];
reduceFunction1('myKey', myTestValues);
46. mapReduce desde c#
var map = “”;
Var reduce =“”;
var collection = db.GetCollection("movies");
var options = new MapReduceOptionsBuilder();
options.SetFinalize(finalize);
options.SetOutput(MapReduceOutput.Inline);
var results = collection.MapReduce(map, reduce, options);
foreach (var result in results.GetResults())
{
Console.WriteLine(result.ToJson());
}
47. Aggregation Framework
- Evolución de mapReduce. c++, código compilado, 10x veces más rápido que
mapReduce
• Qué es básicamente?
• Una serie de transformaciones sobre los documentos de una colección
• Ejecutados en etapas
• El resultado es un cursor o una colección
• Conjunto grande de librerías de funciones
• Filtrado, computo, grupo, sumarización
• El resultado de una etapa es enviada a la siguiente
• Las operaciones se ejecutan en un orden secuencial
$match $Project $group $sort