PDF de programación - Gestores NoSQL - MongoDB

Gestores NoSQL –
MongoDB

1

Marta Zorrilla – Diego García-Saiz
Enero 2017

Este material se ofrece con licencia: Creative Commons BY-NC-SA 4.0

Tabla de contenidos

M.Zorrilla – D.García

- 2 -

• Introducción
• Arquitectura
• Tareas administrativas
• Modelo de datos
• BSON y operaciones CRUD
• Ventajas y desventajas de MongoDB

Bibliografía y documentación
complementaria

M.Zorrilla – D.García

- 3 -

• Bibliografía:

• Rick Copeland: MongoDB Applied Design Patterns. O'Reilly Media

• Kristina Chodorow: MongoDB: The Definitive Guide. O'Reilly Media

(2013)

(2013)

• Tutoriales:

• https://www.tutorialspoint.com/mongodb/
• https://docs.mongodb.com/manual/tutorial/ (oficial)

• Manuales:

• https://docs.mongodb.com/manual/ (oficial)
• http://bsonspec.org/ (lenguaje BSON)

Introducción: Revisión histórica de
MongoDB

M.Zorrilla – D.García

- 4 -

• BD NoSQL orientada a documentos.

• MongoDB: derivado de la palabra inglesa “humongous” (enorme,

extraordinariamente largo).

• Primera versión publicada en marzo de 2009: 0.9

• Publicada en código abierto bajo licencia AGPL.

• Primera versión estable publicada en agosto de 2009: 1.0

• En 2011, se lanzó la versión 1.4, la primera considerada como

apta para su producción y distribución.

• Última versión publicada el 29 de noviembre de 2016:

3.4

• Las únicas versiones que actualmente se mantienen actualizadas

son de la 2.0 en adelante.

Introducción: ¿Pará que se usa
MongoDB?

M.Zorrilla – D.García

- 5 -

• Internet de las cosas, grupo industrial Bosch.
• Visualización geospacial de elementos de una ciudad en tiempo real

(Boston city).

• Gestión de contenidos, caso de Sourceforge.
• Aplicaciones móviles, como compra de viajes por Expedia.
• Videojuegos como FIFA online 3.
• Log de eventos, caso de Facebook para recoger anuncios accedidos
• Algunos usuarios conocidos de MongoDB son:

Ebay, Expedia, Orange, Barclays, Adobe, Telefónica…

Ver más en:
https://www.mongodb.com/use-cases
https://www.mongodb.com/who-uses-mongodb

Arquitectura: conceptos

M.Zorrilla – D.García

- 6 -

• mongod: proceso primario (demonio) instanciable de MongoDB para la

gestión del acceso a los datos.

• mongos: servicio de enrutado entre la aplicación y la Base de Datos.
• Config. server: servidor que almacena los metadatos para localizar los

datos de las operaciones requeridas por el cliente.

• Replica set: grupo de procesos mongod que almacenan las mismas copias

de los datos.

• Primary: guarda las copias principales.
• Secondary: guarda las copias secundarias de Primary.
• Arbitrer: Si el Primary se cae, vota para decidir que Secondary pasa a ser

Primary.

• Shard: replica set que almacena una parte de los datos de la BD.

• Se basa en el concepto de Sharding, que se define como “un método para distribuir los
datos en varias máquinas” (definición en https://docs.mongodb.com/manual/sharding/)

Arquitectura: Sharding, repartiendo
los documentos

M.Zorrilla – D.García

- 7 -

3 Config.
Servers

• Los clientes (Apps) se conectan
a un router (mongos) de la Base
de Datos.

• El mongos se comunica con los
Config. Server para determinar
en
datos
requeridos, o en dónde escribir
los nuevos.

donde

están

los

con

conecta

• A través de un mongos, la App
se
Shard
(conjunto de réplicas). Cada
un mongod
Shard
principal y cero o varios mongod
secundarios (ver más adelante).

tendrá

el

App Server

Router (mongos)

App Server

Router (mongos)

...

App Server

Router (mongos)

Shard (Replica

set)

Shard (Replica

set)

...

Shard (Replica

set)

Arquitectura: Sharding, repartiendo
los documentos

M.Zorrilla – D.García

- 8 -

• Tres Config. Server: garantizan acceso

aunque 1 ó 2 de ellos “se caigan”.

• También reparten la carga de

trabajo.

• Sólo se escribe en ellos si
los
metadatos cambian (p.e. si
los
chunks de una colección cambian
de ubicación).

• Si se caen los tres, aún se puede
(datos)
acceder a los
siempre que los mongos no se
reinicien.

shards

• Dos o más mongos: reparten la carga
las

peticiones

parte

por

de

de
aplicaciones.

• Dos o más shards: para repartir los
nodos del

varios

en

documentos
clúster.

3 Config.
Servers

Shard (Replica

set)

Shard (Replica

set)

...

Shard (Replica

set)

App Server

Router (mongos)

App Server

Router (mongos)

...

App Server

Router (mongos)

Sharding: chunks y Shard key

M.Zorrilla – D.García

- 9 -

• Chunks: “trozos” en los que se
reparten los documentos de una
colección en varios shards.

• Shard key: clave que determina
cómo se divide una colección en
diferentes chunks.

• La Shard key siempre ha de ser
un campo del documento que
esté indexado (más adelante
veremos los tipos de índices en
mongoDB).

Colección I

1 TB

256 GB

Colección I

Shard A

Shard B

Shard C

Sharding: chunks y Shard key

M.Zorrilla – D.García

- 10 -

• Range Based Sharding:
los chunks se crean en
base a rangos de valores
de la Shard key.

• Documentos con un valor
de
similar
estarán probablemente en
un mismo shard.

Shard

key

Chunk 1

Chunk 2

Chunk 3

X = ...

X = ...

X = ...

• Bueno para consultas.

• Si hay muchos documentos
con un Shard key en el
mismo rango, habrá shards
“sobrecargados” de datos.

Key Space para X

X = min

X = 50

X = 130

X = max

Sharding: chunks y Shard key

M.Zorrilla – D.García

- 11 -

• Hash

Based

Sharding:
cálculo de valor hash en
base a la Shard Key.

• No hay rangos.

• Los documentos se reparten
de forma “aleatoria” entre los
shards.

• Buen equilibrio.

X = 47

X = 48

X = 52

Función Hash

Chunk 1

Chunk 2

Chunk 3

• Las consultas por rangos sobre
la
requerirán
acceder a varios shards (más
lentas).

Shard

key

La importancia de la Shard key

M.Zorrilla – D.García

- 12 -

• Si en una consulta se

incluye la Shard key:

Petición de lectura
con x = 7

• Sólo

se

consultarán
aquellos
que
contengan los documentos
requeridos.

shards

mongos

Colección I con
Shard key “x”

x = 7

Shard A

Shard B

Shard C

La importancia de la Shard key

M.Zorrilla – D.García

- 13 -

• Si en una consulta NO se

incluye la Shard key:

Petición de lectura
sin Shard Key

• Búsqueda

secuencial:

se
busca en todos los shards
(consulta ineficiente).

mongos

Colección I con
Shard key “x”

x = 7

Shard A

Shard B

Shard C

Replicación de los datos

• En mongoDB,

copias

existen

o
réplicas de los datos principales y
secundarias.
es
controlada por una instancia del
proceso mongod.

Cada

réplica

• Las operaciones de escritura del cliente
se realizan exclusivamente sobre el
primario.

• Las de lectura, por defecto también. Si
bien, se puede reconfigurar la BD para
que se hagan sobre los secundarios.

• El primario almacena en una estructura
de log los cambios en los datos, que
luego son propagados a los secundarios.

M.Zorrilla – D.García

- 14 -

ESCRITURA

LECTURA

PRIMARIO

REPLICACIÓN

REPLICACIÓN

SECUNDARIO

SECUNDARIO

Replicación de los datos

M.Zorrilla – D.García

- 15 -

• Heartbeat:

comunicación
entre nodos del mismo
replica set indicando que
“siguen vivos”. Se envía
cada 2 segundos.

• Si el primario cae,

los
que
secundarios
elegir un nuevo primario
de entre ellos.

tiene

que

ha

• Para

considerar

el
primario
por
defecto, ha de estar 10
segundos sin responder.

caído,

PRIMARIO

REPLICACIÓN

REPLICACIÓN

SECUNDARIO

Heartbeat

SECUNDARIO

Replicación de los datos

M.Zorrilla – D.García

- 16 -

PRIMARIO

• Los secundarios votan para
decidir quién de ellos se
convierte
nuevo
primario.

en

el

SECUNDARIO

Heartbeat

SECUNDARIO

Elección de un nuevo primario

PRIMARIO

REPLICACIÓN

Heartbeat

SECUNDARIO

Nuevo primario elegido

Replicación de los datos

M.Zorrilla – D.García

- 17 -

• ¿Y si hay un empate en las

votaciones?.

• Arbitrer

(Árbitro):
instancia mongod que se
encarga de desempatar las
votaciones.

SECUNDARIO

• No almacena réplicas.
• Se recomienda sólo cuando
se
con

replica
votaciones

los
en
prevean
empates.

sets

SECUNDARIO

PRIMARIO

SECUNDARIO

ÁRBITRO

Casos especiales de secundarios

M.Zorrilla – D.García

- 18 -

• Priority 0 (Prioridad 0): secundarios
en

convertirse

pueden

que
no
primarios.

• Almacenan las réplicas de los primarios.
• Votan para elegir primarios al igual que el

• Se puede “forzar” a que los primarios sólo

sean de un Data Center.

• Pueden ser leídos por el cliente, si

la

configuración de la BD lo permite.

• Útil en BDs repartidas en múltiples Data

resto.

Centers:

Data Center 1

Data Center 2

PRIMARIO

PRIORIDAD: 1

SECUNDARIO

SECUNDARIO

PRIORIDAD: 1

PRIORIDAD: 0

Casos especiales de secundarios

M.Zorrilla – D.García

- 19 -

• Hidden replica set: invisibles

a la aplicación cliente.

• Siguen guardando todas

las

aplicación cliente.

• Útiles para realizar backups.

copias del primario.

• Participan en las votaciones.
• No pueden ser escogidos como

primarios (Prioridad 0).

• No pueden ser leídos por la

SECUNDARIO

SECUNDARIO

PRIMARIO

SECUNDARIO

PRIORIDAD: 0
HIDDEN: TRUE

SECUNDARIO

Casos especiales de secundarios

M.Zorrilla – D.García

- 20 -

• Delayed replica set: guardan
las copias del principal “con
retraso”.

• No

puede

convertirse

en

primario (Prioridad 0).

• No puede ser accesible al

primario.

snapshots.

cliente (Hidden).

• Puede votar en la elección del

• Útil para guardar backups y

SECUNDARIO

SECUNDARIO

PRIMARIO

SECUNDARIO

PRIORIDAD: 0
HIDDEN: TRUE
DELAYED: 3600

SECUNDARIO

Lectura de datos: configuración

M.Zorrilla – D.García

- 21 -

• En la propia consulta, se define la configuración del lectura.

• Por defecto, la lectura se hace siempre sobre el primario.
• Otras posibilidades:

• PrimaryPreferred: si el primario no está disponible, no se espera a que lo

esté, se va a un secundario.

• Secondary: siempre sobre secundarios.

• SecondaryPreferred: preferencia sobre secundarios, y si no hay ninguno

disponible, sobre el primario.

• Nearest: replica set “más cercano” (menor tiempo de latencia).

Lectura de datos: consistencia

M.Zorrilla – D.García

- 22 -

• En la