Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
josebyte
Este libro está a la venta en http://leanpub.com/mongodbcastellano
This is a Leanpub book. Leanpub empowers authors and publishers with the Lean Publishing
process. Lean Publishing is the act of publishing an in-progress ebook using lightweight tools and
many iterations to get reader feedback, pivot until you have the right book and build traction once
you do.
Agradecimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Introducción a MongoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Un poco de historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
¿Qué es MongoDB? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Documentos JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
BSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Mongo Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
CRUD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Insert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
save . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
find y findOne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
remove . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
findAndModify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Operadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Operadores especiales: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Modelado de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Índices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Consideraciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Ver indices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Funcionamiento de los índices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Crear indices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
mongotop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
mongostat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Agregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
ReplicaSet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
ÍNDICE GENERAL
Sharding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
DBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Store engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Agradecimientos
Me llamo Joseba Madrigal¹, soy graduado en informática además de una persona curiosa y analítica,
me encanta descubrir nuevas tecnologías y ayudar a las personas de mi entorno, por ello he dedicado
un par de meses a escribir este libro que espero ayude a la gente a profesionalizarse en MongoDB.
El libro está escrito para programadores con interés en utilizar MongoDB a un nivel profesional.
El motivo de escribir este libro es que cuando intente realizar el salto del mundo SQL, en el cual
me encontraba muy cómodo, no encontré ninguna documentación en Español y aunque todo buen
desarrollador debe tener buen nivel de inglés, siempre es más cómodo leer en la lengua materna.
Había pasado muchos años trabajando con Oracle PL-SQL y más de los que me gustaría trabajando
con MYSQL hasta que entre en “Tapquo S.L.” y conocí más de cerca el mundo no-sql. Fue entonces
cuando me apunté a los cursos de MongoDB-University y comencé a apreciar las virtudes de este
mundo no-sql tan desconocido para mí. En apenas 3 meses había logrado la certificación oficial
de MongoDb tanto de sus cursos como en su examen, por lo que me di cuenta de que la curva de
aprendizaje es realmente rápida y buena, por consiguiente quería hacerla aún mejor para todos los
hispanohablantes que quieran profesionalizarse en MongoDB.
Escribí este libro en mis ratos libres, es difícil encontrar un rato libre cuando tienes una vida con
un trabajo a jornada completa, impartes clases después de la jornada de trabajo, estudias, tienes
familia, novia y amigos. Estas líneas no hubieran sido posibles sin el apoyo incondicional de todo mi
entorno, desde aquí me gustaría agradecer a todos su comprensión y sus ánimos. A toda mi familia,
pero en especial a mi hermano Aitor, por ayudarme a mejorar mi inglés, apoyarme, animarme y
además hacer la revisión final del libro. A mi novia Katy agredezco su paciencia, aguantarme en los
buenos y los malos momentos y por permitirme ponerme en el ordenador para escribir pese a que
no le guste verme delante del PC. A mis amigos les agradezco que me ayuden a desconectar, lo cual
es imprescindible de vez en cuando. A todos ellos les estaré eternamente agradecido por apoyarme
siempre en todas mis decisiones.
Y como no, gracias a ti por descargar este libro, espero que sea de tu agrado.
¹http://www.josebamadrigal.com
1
Introducción a MongoDB
Un poco de historia
Actualmente se escucha hablar de BigData, pero antes de comenzar hablando de grandes cantidades
de datos es mejor empezar por el origen, ¿cuál es el motivo de la existencia de bases de datos para
Big Data?
Desde el origen de la informática ha existido la necesidad de almacenar información de forma
permanente. Con el término permanente se hace alusión a datos almacenados en un medio físico
como un disco duro ,(la memoria RAM no es almacenamiento permanente), la cual puede ser leída
posteriormente incluso despues de apagar y encender el equipo. Inicialmente se guardaban los datos
en ficheros de texto, pero pronto surgieron limitaciones, es un método poco eficaz, ¿qué ocurre si
cambiamos la estructura de los datos? ¿y si cambiamos algunos datos? ¿inconsistencias?… Por ello
surgieron las bases de datos históricas como las jerárquicas, en red o transaccionales. Estas bases
de datos se siguen estudiando actualmente en las universidades pero ya no son utilizadas debido a
sus limitaciones: Complejidad, duplicidad de registros, Integridad referencial, (No existe garantía de
que un registro hijo esté relacionado con un registro padre válido), Desnormalización…
Debido a esas limitaciones surgieron las bases de datos que se utilizan actualmente. Existen tres tipos
de bases de datos: - Bases de datos relacionales: Hasta la actualidad son las más usadas, utilizan
SQL. Por ejemplo: Oracle, MS SQL Server, MySQL o MariaDB son bases de datos relacionales. -
Bases de datos orientadas a objetos: Se han diseñado para trabajar bien en conjunción con lenguajes
de programación orientados a objetos como Java, C#, Visual Basic.NET y C++. (No están muy
extendidas en la actualidad.) - Bases de datos no-relacionales: No utilizan lenguaje SQL y están
orientadas a la escalabilidad, por ejemplo MongoDB.
¿Qué es MongoDB?
MongoDB es una base de datos no-relacional de documentos JSON y de código abierto escrito en
C++, que proporciona alto rendimiento, alta disponibilidad y escalabilidad automática.
El concepto de escalabilidad está totalmente ligado con “Big data” debido a que cuando se trabaja
con grandes cantidades de datos, en otros tipos de bases de datos es complejo y costoso de gestionar.
Las bases de datos como MongoDb proporcionan escalabilidad automática, lo cual hace que esta
base de datos sea idonea para grandes cantidades crecientes de información.
El desarrollo de MongoDB comenzó en el año 2007 por la empresa 10gen3, publicando una versión
final en el 2009 y actualmente se encuentra en la versión 3.0.
Por lo tanto hemos mencionado que MongoDB es una base de datos escalable, no-relacional y orien-
tada a documentos JSON(BSON), pero ¿qué significa no-relacional? y ¿documentos JSON(BSON)?
2
Introducción a MongoDB 3
No-relacional
No-relacional es un término nuevo que se aplica a todas las bases de datos que no son relacionales.
Este tipo de base de datos también son conocidas como “no-SQL” o “Big Data”. MongoDB tiene las
siguientes características no-relacionales: - No-SQL. - No tiene JOINs. - No tiene esquema. - Escala
horizontalmente. - No tiene transacciones atómicas para multiples documentos.
No-SQL
MongoDB no usa SQL como lenguaje de consultas, en su lugar dispone de una serie de métodos en
JavaScript que permiten realizar consultas y operaciones.
No tiene JOINs
En MongoDB no se puede hacer una relación entre dos colecciones, no existen las “join” del mundo
SQL. La razón es que MongoDB está orientado a ser escalable y las join de las bases de datos
relacionales escalan muy mal.
Sin esquema
Una misma colección (en sql: “colección”==”tabla”) de documentos puede contener documentos con
distinto formato, a esto se le llama “schemeless” o “sin esquema”. Es decir podremos tener ,por
ejemplo, una colección de usuarios en donde guardemos datos diferentes para cada usuario. A esa
capacidad le llamamos polimorfismo.
Escalabilidad horizontal
Uno de los motivos más importantes por el que se han creado las bases de datos no-relacionales
es por la escalabilidad. Actualmente cada vez más nos encontramos con gran cantidad de datos
en diferentes servidores. Las bases de datos relacionales son lentas y poco escalables en esos
casos, no están pensadas para que la información almacenada sea muy grande y se encuentre
distribuida, por ello ha surgido MongoDB. Este sistema de base de datos tiene la capacidad de escalar
horizontalmente correcta y fácilmente sin penalización. Un sistema escala horizontalmente bien si
al agregar más nodos al mismo, el rendimiento de éste mejora. Quizá ahora entiendas un poco mejor
el término que comentamos anteriormente que se usa para estas bases de datos, están diseñadas para
grandes cantidades de información, por ese motivo son conocidas también como bases de datos de
“Big Data”.
Introducción a MongoDB 4
Documentos JSON
MongoDB está orientada a documentos en “JavaScript Object Notation” (JSON), por lo que
almacenamos documentos en lugar de “registros” o “filas”.
Un ejemplo de un documento JSON puede ser:
1 {
2 "name" : "Joseba",
3 "surname" : "Madrigal",
4 "age" : 28,
5 "skills" : ["javascript", "MongoDB", "jquery", "angularjs", "php"],
6 "address" : {
7 "street_address": "23 Elm Drive" ,
8 "city": "Palo Alto",
9 "state": "California",
10 "zipcode": "94305"
11 }
12 }
Introducción a MongoDB 5
Más adelante comentaremos los tipos de datos de JSON y veremos que internamente se almacenan
BSONs. Existe un límite de 16MB por documento en MongoDB. En 16MB cabe mucha información
y si tuviésemos que introducir más podríamos partir esa información en varias colecciones. Para
usar documentos más grandes MongoDB proporciona GridFS.
JSON es un estándar y puedes saber más en JSON.org²
BSON
Pese a que nosotros a priori en MongoDB usemos documentos en formato JSON, MongoDB trabaja
internamente con BSON (JSON Binario). Un BSON no es más que la representación binaria de un
documento JSON.
Puedes ver más información en BSONspec³. BSON extiende del modelo JSON para proporcionar
“tipos de datos” para una correcta codificacion y decodificación en los diferentes lenguajes. Por lo
tanto BSON proporciona a MongoDB dos capacidades: 1. Rápida escaneabilidad 2. Tipos de datos
JSON proporciona únicamente 6 tipos de dato: - String - Number - booleans - null - arrays - objetos
/ documentos
Los tipos de datos que maneja internamente BSON son los siguientes: - Double - String - Object -
Array - Binary data - Undefined (Deprecated) - Object id - Boolean - Date - Null - Regular Expression
- JavaScript Symbol JavaScript (with scope) - 32-bit integer - Timestamp - 64-bit integer - Min key
- Max key
Podemos ver BSON como un formato serializado de JSON.
Esquema BSON
²http://json.org
³http://bsonspec.org
Introducción a MongoDB 6
7
Mongo Shell 8
Cuando accedes a un cursor por un índice, internamente mongo llama a “cursor.toArray()” para
convertir el cursor en un array donde poder manejar índices y almacena TODOS los documentos
que devuelve el cursor en la memoria RAM. Para resultados muy grandes de documentos es posible
que mongo devuelva: “out of available memory” ya que no cabe todo en la RAM.
CRUD
Las operaciones CRUD (Create, Read, Update, Delete) existen en Mongodb en forma de funciones.
No se puede usar SQL, se utilizan las funciones o métodos que nos proporciona MongoDB. - C(create)
-> insert, save, update(upsert) - R(read) -> find, findOne - U(update) -> update, save - D(delete) ->
remove
Insert
1 db.collection.insert(
2 <document or array of documents>,
3 {
4 writeConcern: <document>,
5 ordered: <boolean>
6 }
7 )
Para insertar un documento en MongoDb utilizaremos la función insert sobre la colección de una
base de datos. Si la colección no existe, la creará automáticamente. Por ejemplo:
1 db.people.find();
9
CRUD 10
El _id de este documento será “mjoseba@gmail.com”. He elegido una cuenta de correo ya que es
una clave primaria única e inmutable para la mayoría de aplicaciones ,(es muy raro que se cambie
el email), normalmente se suele utilizar como nombre de usuario para el login. Podríamos utilizar
el dni perfectamente ya que identifica este tipo de documento, pero debes ser cuidadoso al elegir la
clave, si no crees que puedas hacerlo deja que MongoDb genere automáticamente el _id por ti.
update
1 db.collection.update(
2 {<query>},
3 {<update>},
4 {
5 upsert: <boolean>,
6 multi: <boolean>,
7 writeConcern: <document>
8 }
9 )
• upsert: true -> Hace que si el documento no existe se cree y si existe lo actualiza. Si lo
establecemos a false ,si existe lo actualiza, en caso contrario no hace nada.
• multi: true -> Especificamos que queremos actualizar múltiples documentos, por defecto es
false de modo que solo se actualiza un único documento, esto es importante ya que en SQL
un update actualiza todas las coincidencias, en MongoDB por defecto multi es false por lo que
solo actualizará la primera coincidencia.
• writeConcer -> Hablaremos de este concepto en el tema de “ReplicaSet”, se trata de una opción
para definir en cuantas réplicas de servidores mongo debe estar escrito el cambio para devolver
un “OK”.
CRUD 11
Con el update anterior vamos a editar el documento completo con “name” “Joseba” y vamos a
introducir el nombre “Jose” y active con valor 1.
Realizando esta update perderemos los campos que no hayamos especificado, quedara un documento
tal y como hemos especificado:
Para editar uno o varios campos y preservar el documento o lo que es lo mismo realizar un “update
parcial” debemos utilizar el operador $set, por ejemplo:
save
.save realiza la misma acción que update con “upsert” por defecto. Es decir, si no exist el _id insertará
el nuevo documento y si existe lo actualizará.
1 db.collection.save(
2 <document>,
3 {
4 writeConcern: <document>
5 }
6 )
Por ejemplo:
CRUD 12
find y findOne
find({WHERE},{PROJECTION})
Para buscar los documentos que insertemos en la base de datos podemos utilizar find() o findOne().
La diferencia es que find retorna un cursor con todos los documentos coincidentes y findOne solo un
documento, si existiese más de una coincidencia será uno al azar. Si lanzamos find() sin argumentos:
1 db.people.find()
Obtendremos todos los documentos de la colección. Por el contrario si ejecutamos sin argumentos
findOne() :
1 db.people.findOne()
1 db.people.findOne({"\_id": "mjoseba@gmail.com"})
En este caso retornará nuestro registro y estamos seguros que no hay más ya que hemos buscado
sobre la clave primaria y única.
Si queremos buscar todos los usuarios que se llaman “Joseba” dentro de la colección: db.people.find({“name”:
“Joseba”})
Retorna todos los usuarios llamados “Joseba”.
Si especificamos un segundo parámetro definiremos los campos que queremos recibir: db.people.find({“name”:
“Joseba”}, {“surname”: true, _id:false})
Devuelve los apellidos de las personas que se llaman Joseba: {“surname”: “Madrigal”}
remove
CRUD 13
Es un borrado de múltiples documentos por defecto a no ser que se especifique justOne a true.
findAndModify
Modifica y retorna un único documento.
1 findAndModify: <collection-name>,
2 query: <document>,
3 sort: <document>,
4 remove: <boolean>,
5 update: <document>,
6 new: <boolean>,
7 fields: <document>,
8 upsert: <boolean>
Operadores
Podemos utilizar los siguientes operadores para evaluar en nuestras consultas.
Por ejemplo si queremos buscar los usuarios de 18 años: db.people.find({ age : { $eq : 18 }
} )
Por ejemplo si queremos buscar los usuarios mayores de 18 años y menores de 50 o de 50 en nuestra
colección “people”:
Si queremos buscar los documentos con una cantidad menor que 20 o un precio de 10: db.inventory.find(
{ $or: [ { quantity: { $lt: 20 } }, { price: 10 } ] } )
14
Operadores 15
Operadores especiales:
Geoespaciales
• $geoWithin: Selecciona geometrías dentro de una geometría GeoJSON. Los índices 2dsphere
y 2d soportan $geoWithin.
• $geoIntersects: Seleccionan las geometrías con intersección en un GeoJSON. Los índices
2dsphere y 2d lo soportan.
• $geoIntersects.
• $near: Devuelve un objeto geoespacial en la proximidad de un punto. Require un índice
geoespacial. Los índices 2dsphere y 2d soportan $near.
• $nearSphere: Devuelve un objeto geoespacial en la proximidad de un punto de la esfera.
Require un índice geoespacial. Los índices 2dsphere y 2d soportan $nearSphere.
Array
Para los campos que contienen Arrays, MongoDB proporciona los siguientes operadores: - $elem-
Match - $slice - $. - $size
Por ejemplo, the inventory collection contains the following document: { "\_id" : 1, "name" :
"Joseba", "languages" : [ "JS", "PHP", "HTML" ] }
Si quisiéramos obtener solo los dos primeros elementos del array languages lo haríamos de la
siguiente manera: db.inventory.find( { \_id: 1 }, { languages: { $slice: 2 } } )
Modelado de datos
Si vienes del mundo sql estarás acostumbrado a crear entidades, aplicar las formas normales… En
MongoDb se crean los esquemas de la base de datos orientados al uso que se le da a los datos en la
aplicación. Este tipo de diseño de esquema se llama “Application driven schema”. Analizaremos los
datos y los patrones de acceso que se usarán en el programa para crear un esquema a esos datos.
Muchas veces nos encontraremos con la duda de si embeber un documento o no. Por ejemplo en un
blog, imaginemos una colección post:
1 {
2 "author" : "Joseba",
3 "title" : "Mongodb introduction",
4 "text" : "MongoDB is a no-sql document oriented data base ...",
5 "comments" : [
6 {"author": "Patxi", "comment": "Thanks for this post!" },
7 {"author": "Juan", "comment": "Nice post!" }
8 ],
9 "tags" : ["javascript", "mongodb", "jquery", "angularjs"],
10 }
16
Modelado de datos 17
1 {
2 nick: "josebyte",
3 pass: "1234",
4 type: "admin",
5 cars:[
6 {marca: "Ford", año: "2009", matricula:"1234-GGG"},
7 {marca: "Opel", año: "2001", matricula:"4321-JJJ"}
8 ]
9 }
• Relaciones n-m: Si pensamos en el ejemplo anterior y que un coche puede tener varios usuarios
el ejemplo anterior sería n-m y en lugar de embeber los datos en el documento deberiamos
crear otra coleccion:
1 Colección usuarios:
2 {
3 nick: "josebyte",
4 pass: "1234",
5 type: "admin",
6 cars:[
7 11154,
8 11155
9 ]
10 }
11
12 Colección coches:
13 {"_id": 11154, "marca": "Ford", "año": "2009", "matricula":"1234-GGG"}
14 {"_id": 11155, "marca": "Opel", "año": "2001", "matricula":"4321-JJJ"}
Nota: Se podra embeber en usuarios el array de coche o a la inversa, un array conductores dentro
de los documentos coches que contendrá el _id de cada usuario de ese coche. Dependerá de cómo
se va a acceder a los datos en el programa.
Embeber documentos 1-1 y 1-n proporcionará mayor rapidez de lectura. Es importante que se
analicen las lecturas y escrituras que realizará el programa sobre la base de datos para orientar
el modelo de base de datos y mejorar la eficiencia.
Índices
Introducción
Los índices en MongoDB funcionan igual que en cualquier base de datos. Si realizamos una consulta
en una base de datos sin usar índices la consulta será lenta debido a que se recorrerán todos los
documentos de la colección para comprobar si se cumple la consulta. Sin embargo si disponemos
de un índice, los elementos están ordenados y como sabréis no es lo mismo buscar palabras en un
diccionario que en una sopa de letras… el diccionario lleva un índice alfabético en las palabras.
Consideraciones
Cuando creas índices debes tener en cuanta lo siguiente: - Por defecto los _id de todas las colecciones
tienen un índice. - Cada índice requiere 8KB de espacio. - Añadir un índice tiene un impacto
negativo para las operaciones de escritura. Para colecciones con alto ratio escritura>lectura, los
índices son caros ya que cada inserción también debe actualizar los índices. - Las colecciones con
alto ratio lectura>escritura a menudo se benefician de índices adicionales. Los índices no afectan al
rendimiento de las lecturas que no usen índices. - Cada índice activo consume espacio en disco y
memoria. Este uso puede ser importante y debe ser analizado para la planificación de la capacidad.
Ver indices
Puedes ver todos los índices de la base de datos con la siguiente consulta:
1 db.system.indexes.find()
18
Índices 19
índice. - Las consultas sobre “apellido” NO usarán el índice. - Las consultas sobre “nombre” y “edad”
usarán el índice pero solo la parte de “nombre”.
Puedes forzar usar un índice determinado indicando a la consulta .hint({campo:1}) .hint({$natural:1})
//para no usar indice
Por defecto en el log encontraremos las consultas que tardan mas de 100ms
Podemos usar profiler para establecer el nivel de capturas que deseamos realizar: - 0 desactivado - 1
consultas lentas - 2 todas las consultas
1 db.setProfilingLevel(2)
1 db.system.profile.find()
Crear indices
Para crear un índice: db.micoleccion.createIndex({micampo:1}) db.micoleccion.ensureIndex({micampo:1})
//Para versiones previas a 3.0
Podemos crear índices compuestos de varios campos db.micoleccion.createIndex({{micampo:1
, orden:1})
Índice unico
1 db.micoleccion.createIndex({{micampo:1},{unique:true})
Eliminar duplucados
Si en la creación indicamos la opción dropDups:1 eliminaremos los valores duplicados.
Borrar indece:
1 db.micoleccion.dropIndex({micampo:1});
Multikey index
Si creamos un índice de un campo que es un array será un índice multikey. No puedes crear un
índice compuesto sobre dos campos multikey, en ese caso debes crear dos índices separados.
Si existe un documento con valores y creas un índice ya se considera multikey pese a que el resto de
valores sean numéricos o string.
Si hacemos un .explain() de una consulta y dice isMultiKey significa que usa es un índice multikey.
Índices 20
Sparse index
Los índices creados con la opción sparse:1 generará índices solo para los campos con valor disntito de
null. Es usado principalmente en conjunto con unique ya que si no disponen ese campo se considera
que tienen null y hay valores duplicados.
Índices en background
Por defecto se lanzan en foreground y son mas rápidas pero bloquean las escrituras en la misma
base de datos. En background no bloqueará las escrituras pero será bastante más lento.
Una instancia de mongod solo puede construir un índice en background por base de datos. Una
creación de índices en background permite escrituras pero bloquea el shell.
Indices geoespaciales
Hay dos tipos de indices geoespaciales: - 2D [x,y] - 2D Sphere [long, lat]
2d createIndex({location: "2d", type: 1}) find({ location:{$near:[x,y]} }).limit(30)
mongotop
Muestra tiempos de lectura, escritura y totales por cada colección. Podemos lanzarlo con: mongotop
5 Refrescará cada 5milisegundos
mongostat
Muestra update, query delete por query. Nos dice si el índice está en memoria o no.
Agregation
MongoDB dispone de herramientas para hacer consultas sobre agrupaciones de documentos. Pode-
mos agrupar datos de varios documentos y realizar operaciones sobre esa agrupación. Utilizaremos
agregaciones por ejemplo para mostrar estadísticas sobre nuestros documentos. Funciona de forma
similar al comando GROUP BY y HAVING de SQL.
Si quisiésemos agrupar y contar cuantos usuarios hay por país:
1 db.usuarios.aggregate([
2 {
3 $group: {
4 "_id": "$pais",
5 "num_usuarios": {$sum: 1}
6 }
7 }
8 ])
Si quisiéramos sumar los puntos de cada pais que han obtenido los usuarios: db.usuarios.aggregate([
{ $group: { "_id": "$pais", "puntosPorPais": {$sum: "$puntos"} } } ])
21
Agregation 22
23
Sharding
La forma de lograr alta disponibilidad y tolerancia a fallos es con las replicaSet. Con sharding lo que
haces es partir la información en varios fragmentos por lo que lo que logramos es escalabilidad.
Las particiones se realizan basadas en rangos sobre la shard-key.
The config server processes are mongod instances that store the cluster’s metadata. You designate a
mongod as a config server using the –configsvr option. Each config server stores a complete copy
of the cluster’s metadata.
In production deployments, you must deploy exactly three config server instances, each running on
different servers to assure good uptime and data safety. In test environments, you can run all three
instances on a single server.
IMPORTANT All members of a sharded cluster must be able to connect to all other members of a
sharded cluster, including all shards and all config servers. Ensure that the network and security
systems including all interfaces and firewalls, allow these connections. Create data directories for
each of the three config server instances. By default, a config server stores its data files in the
/data/configdb directory. You can choose a different location. To create a data directory, issue a
command similar to the following: mkdir /data/configdb Start the three config server instances.
Start each by issuing a command using the following syntax: mongod –configsvr –dbpath <path>
–port <port> The default port for config servers is 27019. You can specify a different port. The
following example starts a config server using the default port and default data directory: mongod
–configsvr –dbpath /data/configdb –port 27019 For additional command options, see mongod or
Configuration File Options. NOTE All config servers must be running and available when you first
initiate a sharded cluster. Start the mongos Instances
The mongos instances are lightweight and do not require data directories. You can run a mongos
instance on a system that runs other cluster components, such as on an application server or a server
running a mongod process. By default, a mongos instance runs on port 27017.
When you start the mongos instance, specify the hostnames of the three config servers, either in the
configuration file or as command line parameters.
TIP To avoid downtime, give each config server a logical DNS name (unrelated to the server’s
physical or virtual hostname). Without logical DNS names, moving or renaming a config server
requires shutting down every mongod and mongos instance in the sharded cluster. To start a mongos
instance, issue a command using the following syntax:
mongos –configdb <config server hostnames> For example, to start a mongos that connects to config
server instance running on the following hosts and on the default ports:
cfg0.example.net cfg1.example.net cfg2.example.net You would issue the following command:
24
Sharding 25
Determine what you will use for the shard key. Your selection of the shard key affects the efficiency
of sharding. See the selection considerations listed in the Considerations for Selecting Shard Key. If
the collection already contains data you must create an index on the shard key using createIndex(). If
the collection is empty then MongoDB will create the index as part of the sh.shardCollection() step.
Enable sharding for a collection by issuing the sh.shardCollection() method in the mongo shell. The
method uses the following syntax: sh.shardCollection(“<database>.<collection>”, shard-key-pattern)
Replace the <database>.<collection> string with the full namespace of your database, which consists
of the name of your database, a dot (e.g. .), and the full name of the collection. The shard-key-pattern
represents your shard key, which you specify in the same form as you would an index key pattern.
EXAMPLE The following sequence of commands shards four collections:
sh.shardCollection(“records.people”, { “zipcode”: 1, “name”: 1 } ) sh.shardCollection(“people.addresses”,
{ “state”: 1, “_id”: 1 } ) sh.shardCollection(“assets.chairs”, { “type”: 1, “_id”: 1 } ) sh.shardCollection(“events.alerts”,
{ “_id”: “hashed” } ) In order, these operations shard: The people collection in the records database
using the shard key { “zipcode”: 1, “name”: 1 }. This shard key distributes documents by the value of
the zipcode field. If a number of documents have the same value for this field, then that chunk will
be splittable by the values of the name field. The addresses collection in the people database using
the shard key { “state”: 1, “_id”: 1 }. This shard key distributes documents by the value of the state
field. If a number of documents have the same value for this field, then that chunk will be splittable
by the values of the _id field. The chairs collection in the assets database using the shard key {
“type”: 1, “_id”: 1 }. This shard key distributes documents by the value of the type field. If a number
of documents have the same value for this field, then that chunk will be splittable by the values of
the _id field. The alerts collection in the events database using the shard key { “_id”: “hashed” }. New
in version 2.4.
This shard key distributes documents by a hash of the value of the _id field. MongoDB computes the
hash of the _id field for the hashed index, which should provide an even distribution of documents
across a cluster.
DBA
Store engine
El store engine es una capa entre la Base de datos y el hardware. El store engine define: -Como se
guardan los datos en disco. -Como se borra la información de disco. -Como se lee la información de
disco. -Las estructuras que se usan para almecenar los daots.
Existe dos storage engines actualmente: - MMAP v1 - WiredTiger
El store engine determina dos aspectos fundamentales: -Formato de los indices -El formato de datos
y archivos.
27
Bibliografía
El material que me ha ayudado a escribir este libro y considero de tu interés es el siguiente:
Documentación oficial de MongoDB: https://docs.mongodb.org/manual/
Cursos gratuitos de Mongo University: M101
28