0% encontró este documento útil (0 votos)
3 vistas102 páginas

No SQL BD

El documento aborda la gestión de grandes volúmenes de datos, centrándose en bases de datos NoSQL orientadas a documentos, específicamente MongoDB. Se discuten modelos de datos, operaciones CRUD, técnicas de distribución y un caso de estudio sobre MongoDB, destacando su estructura, tipos de datos y consultas. El objetivo es clasificar y explorar el uso de bases de datos NoSQL en diferentes contextos de desarrollo.
Derechos de autor
© All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd
0% encontró este documento útil (0 votos)
3 vistas102 páginas

No SQL BD

El documento aborda la gestión de grandes volúmenes de datos, centrándose en bases de datos NoSQL orientadas a documentos, específicamente MongoDB. Se discuten modelos de datos, operaciones CRUD, técnicas de distribución y un caso de estudio sobre MongoDB, destacando su estructura, tipos de datos y consultas. El objetivo es clasificar y explorar el uso de bases de datos NoSQL en diferentes contextos de desarrollo.
Derechos de autor
© All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd

GESTIÓN DE GRANDES

VOLÚMENES DE DATOS
Maestría en Sistemas de Información

Profa. Mercy Ospina

13/5/2023 Gestión de Grandes Volumenes de Datos 1


GESTIÓN DE GRANDES
VOLÚMENES DE DATOS
Unidad 4 Bases de Datos NoSQL Orientadas a
Documentos

Profa. Mercy Ospina

13/5/2023 Gestión de Grandes Volumenes de Datos 2


Agenda
Modelo de datos

Operaciones

Técnicas usadas

Cuando usar

Caso de estudio

Estructuras y datos

Consultas

Estructuras

Técnicas
Objetivos del tema

Clasificar las BD NoSQL según el modelo


de datos que implementa.

Identificar ámbitos de desarrollo y


requerimientos donde es
recomendable usar BD NoSQL y
establecer elementos que permitan
seleccionar el uso de estos sistemas.

Explorar y usar en casos prácticos


algunos motores de bases de datos
NoSQL.
Agenda
Modelo de datos

Operaciones

Técnicas usadas

Cuando usar

Caso de estudio

Estructuras y datos

Consultas

Estructuras

Técnicas
Modelo de datos
 Usa un modelo semiestructurado basado en
Json o XML
 El más usado en Json:
• Es un conjunto de clave:valor o arreglos de
clave:valor
• Los documentos están almacenados por una clave
• El sistema entiende la estructura arbitraria de los
documentos
• Da soporte a listas, apuntadores a documentos y
documentos anidados
• Permite crear índices secundarios además de
índices sobre la clave

18/01/2017 Modelos de datos - taxonomía 6


Modelo de datos

7
Modelo de datos - Estructuras

Base de • Contenedor físico de


colecciones o
datos documentos

• Agrupaciones de
Colecciones documentos, no todas las
BD Documento lo tienen

• Unidad básica de
Documento datos en Json

• Atómicos
Valores • Listas o arreglos
• Adjuntos (pdf, jpg, etc)

8
Caso de Estudio – Tipos de datos
• Los definidos por Json
•String - Cadenas de caracteres.
•Integer - Números enteros.
•Double - Números con decimales.
•Boolean - Booleanos verdaderos o falsos.
•Timestamp - Marcas de tiempo.
•Null - Valor nulo.
•Array - Arreglos de otros tipos de dato.
•Object - Otros documentos embebidos.
•ObjectID - Identificadores únicos creados por la Base de datos al crear
documentos sin especificar valores para el campo _id.
•Data Binaria - Punteros a archivos binarios.
•Javascript - código y funciones Javascript

9
Caso de Estudio – Tipos de datos

10
Caso de Estudio – Tipos de datos

[Link]

11
Agenda
Modelo de datos

Operaciones

Técnicas usadas

Cuando usar

Caso de estudio

Estructuras y datos

Consultas

Estructuras

Técnicas
Operaciones

CRUD
• Create: Crea un nuevo documento
• Read: Lee uno o mas documentos
• Update: Actualiza un documento nuevo
• Delete: Elimina uno o más documentos

REST
• GET: Retorna un documento con un id dado
• PUT: Crea un nuevo documento o una nueva versión
• DELETE: Marca un documento como borrado

Map - Reduce
13
Agenda
Modelo de datos

Operaciones

Técnicas usadas

Cuando usar

Caso de estudio

Estructuras y datos

Consultas

Estructuras

Técnicas
Distribución de los datos
• Sharding automático:
• Por rango de clave, con servidor de metadata que
mantiene la ubicación de los rangos
• MongoDB
• HBase
• Hashing consistente
• CouchDB
Técnicas usadas - ejemplos
Problema MongoDB CouchDB
Topología Cluster (maestro esclavo) Anillo
Particionamiento por rango,
Sharding particionamiento por hash y Hashing Consistente DHT
splitting
Bloqueo compartido (S) para
lectura y Exclusivo (X) para MVCC y relojes de vector con
Control de concurrencia
escritura con intentos de bloqueo reconciliación durante lecturas
(IS e IX)
Manejo de fallas temporales Sloppy Quorum y hinted handoff
Servidor de configuración

Replica sets maestro esclavo con Anti- entropía con árboles Merkle
Manejo de fallas permanentes elección de nuevo maestro cuando para Consistencia de Replicas
se presentan fallas usando Paxos
Protocolo de membresía basado
Nodos salientes o entrantes Sharded Collection Balancing en Gossip y detección de fallas.

Árboles B+ para Índices por clave Árboles B+ para Índices por clave
Búsquedas
y secundarios y secundarios
Agenda
Modelo de datos

Operaciones

Técnicas usadas

Cuando usar

Caso de estudio

Operaciones

Consultas

Estructuras

Técnicas
Caso de Estudio
• Viene de la palabra en inglés “humongous” que significa
enorme
• Su desarrollo empezó en octubre de 2007 por la
compañía de software 10gen, aunque su lanzamiento fue
en el 2009
• Es de código abierto, con licencia GNU AGPL (para las
versiones hasta el 2018). Todas las versiones posteriores
al 16 de octubre de 2018, se publican bajo la Server Side
Public License (SSPL) v1.
• Última versión estable 6.0.1 el 19 de Agosto de 2022
• Guarda estructuras de datos en documentos
tipo JSON con un esquema dinámico (MongoDB llama
ese formato BSON)
• Escrito en C++. Go, Javascript y Python

• [Link]
18
Caso de estudio
Caso de estudio
Caso de estudio
Caso de Estudio
• Trabaja en una configuración de sistema
distribuido Master-Slave propia o puede trabajar
en un cluster de Hadoop
• Es factible tanto en soluciones pequeñas como de
Big Data
• Soporta principalmente las propiedades CP del
teorema de CAP, con atomicidad sobre un
documento
• La documentación en:
• [Link]

22
Caso de estudio
Caso de estudio
Caso de estudio
Agenda
Modelo de datos

Operaciones

Técnicas usadas

Cuando usar

Caso de estudio

Operaciones

Consultas

Estructuras

Técnicas
Caso de Estudio- Operaciones
• CRUD
• Create/Insert
• Agregan documentos nuevos a una colección, si la colección
no existe se crea
• Métodos

• Las operaciones insert se realizan sobre una colección. Esta


operación es atómica a nivel de documento.

[Link]

27
Caso de Estudio- Operaciones
• Create/Insert

28
Caso de Estudio- Operaciones
• [Link]() puede insertar múltiples
documentos en una colección, recibe un arreglo de
documentos
[Link]([
{ item: "journal", qty: 25, tags: ["blank", "red"], size: { h: 14, w:
21, uom: "cm" } },
{ item: "mat", qty: 85, tags: ["gray"], size: { h: 27.9, w: 35.5, uom:
"cm" } },
{ item: "mousepad", qty: 25, tags: ["gel", "blue"], size: { h: 19, w:
22.85, uom: "cm" } }
])

• Retorna un documento con los Objectid de los


documentos insertados

29
Caso de estudio - Operaciones
• CRUD
• Update
[Link](
{ item: "paper" },
{$set: { "[Link]": "cm", status: "P" },
$currentDate: { lastModified: true } }
)

•[Link](<filter>, <update>, <options>)


•[Link](<filter>, <update>, <options>)
•[Link](<filter>, <update>, <options>)

30
Caso de estudio - Operaciones
• CRUD
• Delete

• Otros métodos
•[Link]()

•[Link]() New in version 3.2

•[Link]() New in version 3.2

31
Caso de estudio - Operaciones
• CRUD
• Escritura Masiva (Bulk Writes)
• MongoDB brinda a los clientes la capacidad de realizar
operaciones de escritura en masa.
• Las operaciones de escritura masiva afectan a
una sola colección
• El método es [Link]()
• Operaciones soportadas
• insertOne
• updateOne
• updateMany
• replaceOne
• deleteOne
• deleteMany

32
Caso de estudio – Escritura Masiva
try {
[Link]( [ [Link]( [
{ _id: 0, type: "pepperoni", size: "small", price: 4 { insertOne: { document: { _id: 3, type: "beef", size: "medium",
price: 6 } } },
},
{ insertOne: { document: { _id: 4, type: "sausage", size: "large",
{ _id: 1, type: "cheese", size: "medium", price: 7 }, price: 10 } } },
{ _id: 2, type: "vegan", size: "large", price: 8 } { updateOne: {
filter: { type: "cheese" },
])
update: { $set: { price: 8 } }
} },
{ deleteOne: { filter: { type: "pepperoni"} } },
{ replaceOne: {
filter: { type: "vegan" },
replacement: { type: "tofu", size: "small", price: 4 }
}}
])
} catch( error ) {
print( error )
}

33
Agenda
Modelo de datos

Operaciones

Técnicas usadas

Cuando usar

Caso de estudio

Operaciones

Consultas

Estructuras

Técnicas
Caso de Estudio - Consultas
una consulta se Especifican criterios
dirige a una o condiciones , que
colección identifican los
específica de documentos que
documentos . MongoDB vuelve a
los clientes

Opcionalmente, se
puede imponer
límites o criterios Puede incluir una
de ordenación a las proyección que
consultas.. especifica los campos
de los documentos.

35
Caso de Estudio - Operadores

• Selección
• Comparación
• Lógicos
• Elementos
• Otros
• Proyección

• [Link]

36
Consultas – Operadores de comparación

Operador Descripción
$eq Documentos que coinciden con los valores que son iguales a un valor especificado
$gt Documentos que coinciden con los valores que son mayores a un valor especificado
$gte Documentos que coinciden con los valores que son mayores o iguales a un valor
especificado
$lt Documentos que coinciden con los valores que son menores a un valor especificado
$lte Documentos que coinciden con los valores que son menores o iguales a un valor
especificado
$ne Documentos que coinciden con los valores que no son iguales a un valor especificado
$in Documentos que coinciden con alguno de los valores especificados en un arreglo
$nin Documentos que no coinciden con ninguno de los valores especificados en un
arreglo

37
Consultas – Operadores lógicos

Operador Descripción
$or Une a las cláusulas con un OR lógico y devuelve todos los documentos que
coinciden con las condiciones de cualquiera de las cláusulas
$and Une a las cláusulas con un OR lógico y devuelve todos los documentos que
coinciden con las condiciones de ambas cláusulas
$not Invierte el efecto de una condición retornando los documentos que no cumplen
con la condición
$nor Une a las cláusulas con un NOR lógico y devuelve todos los documentos no
cumplan con ambas cláusulas.

38
Consultas – Operadores de Elementos

Operador Descripción
$exists Coincide con los documentos que tienen o no el campo especificado, recibe el
parámetro true o false
[Link]( { album: { $exists: true } } )
Documentos que tienen el campo álbum
[Link]( { autor: { $exists: false } } )
Documentos que no contienen el campo autor
$type Selecciona documentos donde el field es de un tipo BSON específico.
{ field: { $type: <BSON type number> | <String alias> } }

39
Consultas – Operadores de Proyección

Operador Descripción
$exists Coincide con los documentos que tienen o no el campo especificado, recibe el
parámetro true o false
[Link]( { album: { $exists: true } } )
Documentos que tienen el campo álbum
[Link]( { autor: { $exists: false } } )
Documentos que no contienen el campo autor
$type Selecciona documentos donde el field es de un tipo BSON específico.
{ field: { $type: <BSON type number> | <String alias> } }

40
Caso de Estudio - Consultas

41
Caso de Estudio - Consultas
• Correspondencia con SQL
MongoDB SQL

[Link]() SELECT * FROM inventory


[Link]( { status: "D" } ) SELECT * FROM inventory WHERE status
= "D"
[Link]( { status: { $in: [ "A", "D" ] SELECT * FROM inventory WHERE status
}}) in ("A", "D")
[Link]( { status: "A", qty: { $lt: 30 } SELECT * FROM inventory WHERE status
}) = "A" AND qty < 30
[Link]( { $or: [ { status: "A" }, { SELECT * FROM inventory WHERE status
qty: { $lt: 30 } } ] } ) = "A" OR qty < 30
[Link]( { status: "A" }, { name: 1, status: SELECT id, name, status FROM user
1}) WHERE status = "A"
[Link]( { status: "A" }, { name: 1, status: SELECT name, status FROM user WHERE
1, _id: 0 } ) status = "A"

42
Agenda
Modelo de datos

Operaciones

Técnicas usadas

Cuando usar

Caso de estudio

Operaciones

Estructuras y Técnicas

Consultas
Caso de estudio- Índices
• [Link]( <key and index type specification>, <options> )
• Solo crea el índice si este no existe
• Los indices creados son del tipo B+ tree.
• Ejemplo [Link]({score: 1})

44
Caso de estudio- Índices
• Los índices en MongoDB son a nivel de colección y son similares a
los índices en otros sistemas de base de datos
• Índices primarios para _id (clave primaria): se crean por defecto
• Índices secundarios para atributos en el documento
• Un solo campo
• Múltiples campos

45
Caso de estudio - Índices

• Múltiples campos (Índices compuestos): hace referencia a


múltiples campos en una colección de documentos
• [Link]( { "username" : 1, “score" : -1 } )

• Este índice soporta las siguientes consultas


• [Link]().sort( { username: 1, score: -1 } )
• [Link]().sort( { username: -1, score: 1 } )

46
Caso de estudio- Índices
• El uso de índices busca mejorar la eficiencia de las operaciones de consulta

47
Caso de estudio - Índices

• Otros tipos de índices


• Multiclave: para indexar el contenido almacenado
en arreglos
• Geoespacial: Para consultas sobre coordenadas
geográficas
• Text: soporta búsquedas sobre contenido de texto
en una colección.
• Hashed: crea un índice hash o aleatorio sobre los
valores de un campo.

48
Caso de estudio - Índices

• Limitaciones
• El tamaño total de una entrada de índice debe ser
menor a 1024 bytes
• Una colección no puede tener mas de 64 índices
• El nombre del índice no puede ser mayor a 128
caracteres
• Los índices compuestos no pueden tener más de 31
campos
• Una consulta no puede usar índices de texto y
geoespaciales a la vez

49
Caso de estudio Almacenamiento
• Motor de almacenamiento (storage engine)
• Componente principal responsable de la gestión de datos
• Maneja como son almacenados los datos tanto en disco como en
memoria principal.
• Seleccionar el motor adecuado puede impactar en el rendimiento de la
aplicación.

50
Caso de estudio Almacenamiento
• Mongo tiene 3 motores de almacenamiento
• WiredTiger. Es el motor de almacenamiento por defecto de MongoDB
desde la versión 3.2.
• Provee control de concurrencia a nivel de documento usando MVCC con
intención de bloqueo global
• Cifrado nativo: para encriptar archivos de datos
• Para escribir en disco se colocan los datos en una instantánea que sea
consistente con todos los archivos de datos y se marca un checkpoint que
garantiza la consistencia hasta ese punto.
• Utiliza un log de transacciones de escritura anticipada write-ahead log (WAL) en
combinación con checkpoints para garantizar la durabilidad de los datos.

51
Caso de estudio Almacenamiento
• MMAPv1
• Es el motor de almacenamiento original de MongoDB y es el motor de
almacenamiento por defecto para las versiones previas a la 3.2.
• Basado en archivos mapeados en memoria.
• Se destaca en las cargas de trabajo con inserciones de alto volumen,
lecturas y actualizaciones en el lugar.
• Una un log para almacenar todos los cambios a la base de datos al cual se
copia en disco con más frecuencia que los datos
• Todos los registros se encuentran contiguos en el disco, y cuando un
documento se vuelve más grande que el registro asignado, MongoDB debe
asignar un nuevo registro.

52
Caso de estudio Almacenamiento
• MMAPv1
• Las nuevas asignaciones requieren que MongoDB mueva un documento
y actualice todos los índices que hacen referencia al documento, lo que
lleva a la fragmentación del almacenamiento.
• De forma predeterminada, se deja relleno en los registros (“Power of 2
Sized Allocations”) que permite que el documento crezca como
resultado de actualizaciones minimizando al mismo tiempo la
probabilidad de reasignaciones.
• Usa automáticamente toda la memoria disponible como cache, de
manera dinámica otorgándola a otro proceso si es necesario.

53
Caso de estudio Almacenamiento
• El Motor de almacenamiento "In-Memory"
• solo está disponible en MongoDB Enterprise. En lugar de almacenar
documentos en el disco, se les retiene en memoria el mayor tiempo de
latencia de datos posible.
• Asi mismo mantiene en memoria índices, datos de configuración,
credenciales de usuario, entre otros.
• La data no persiste luego de hacer shutdown.
• No usa logs
• La concurrencia es a nivel de documento para operaciones de escritura.

54
Caso de Estudio – Arquitectura

mongod es el proceso demonio primario para el


sistema de MongoDB. Se ocupa de las solicitudes
de datos , gestiona el acceso de datos, y realiza
operaciones de gestión en background.

Mongos para " MongoDB Shard", es un servicio


de enrutamiento para las configuraciones de
fragmento MongoDB que procesa las consultas
de la capa de aplicación , y determina la ubicación
de los datos en el clúster fragmentado, con el fin
de completar estas operaciones.

Config Server Mongos utiliza tres servidores de


configuración para almacenar los metadatos del
cluster, y los tres deben estar disponibles para
apoyar cambios que incluyen divisiones de chunks
y migraciones . Si uno de los servidores de
configuración no está disponible debe
reemplazarlo a la brevedad posible .

55
Caso de estudio - Replicación
• Un conjunto de replica
• Es un grupo de instancias de mongod que mantiene el mismo conjunto
de datos, donde el primario recibe las actualizaciones de los clientes
quien las replica a los secudarios

56
Caso de estudio - Replicación
• Fallo del primario
• Automaticamente se elige como primario a uno de los secundarios

Algoritmo de paxos para elección de nuevo primario


57
Caso de estudio - Replicación
• Si el nodo se recupera
• Pasa a ser secundario

58
• Tipos de replicas
• Prioridad 0: Miembro del conjunto de replica que no puede ser primario
y no puede llamar a elecciones, sin embargo si puede votar

• Funciona como un respaldo por si otro miembro del set de réplicas no


está disponible
• Tipos de replicas
• Hidden: Mantiene una copia del primario pero es invisible a las
aplicaciones cliente. Además su prioridad siempre es 0

• Su tarea es para reportes y backup


• Tipos de replicas
• Arbitro (Arbiter): No mantiene una del set de datos y no puede ser
primario es invisible a las aplicaciones cliente pero puede votar

• Usado para lograr consenso en elecciones de primario

[Link]
Caso de estudio - Sharding
• Divide el conjunto de datos y distribuye los datos a través de
múltiples servidores o fragmentos .
• Cada fragmento es una base de datos independiente ,
• y colectivamente , los fragmentos forman una sola base de datos lógica.

62
Caso de estudio - Sharding

Key Range Key Range


0..50 51..100
Key Range
0..100

mongod mongod
mongod

Escalabilidad para escribir

63
Caso de estudio - Sharding

Key Range Key Range Key Range Key Range


0..25 26..50 51..75 76.. 100

mongod mongod mongod mongod

Escalabilidad para escribir

64
Caso de estudio - Sharding

Key Range Key Range Key Range Key Range


0..25 26..50 51..75 76.. 100

Primary Primary Primary Primary

Secondary Secondary Secondary Secondary

Secondary Secondary Secondary Secondary

65
Caso de estudio - Sharding
Aplicación

MongoS MongoS MongoS

Key Range Key Range Key Range Key Range


0..25 26..50 51..75 76.. 100

Primary Primary Primary Primary

Secondary Secondary Secondary Secondary

Secondary Secondary Secondary Secondary


Caso de estudio - Sharding
Aplicación
Config
Config
MongoS MongoS MongoS
Config

Key Range Key Range Key Range Key Range


0..25 26..50 51..75 76.. 100

Primary Primary Primary Primary

Secondary Secondary Secondary Secondary

Secondary Secondary Secondary Secondary


Caso de estudio - Splitting
• Splitting o división es un proceso en background que asegura que los datos
almacenados no excedan un tamaño específico Mongo divide los datos en trozos
(chunks). Cuando un trozo crece más allá de un tamaño especificado, MongoDB lo
divide por la mitad y distribuye los trozos en un servidor de fragmentos.

68
Caso de estudio - Splitting
• GridFS: Especificación para almacenar y recuperar archivos
(documentos) que excedan el tamaño límite de documento Bson
de 16MB
• Divide el archivo en pedazos o chunks, por defecto de 255 KB
• Usa dos coleccciones para almacenar los datos
• En una se almacenan los chunks
• En otra se almacena la metadata
• [Link]

69
Caso de estudio - Seguridad

Autenticación Autorización TLS/SSL Solamente


Enterprise
Método Control de Encriptación de Autenticación
[Link]() acceso Basado transporte por Kerberos y
en Roles LDAP
Mecanismos Manejo de roles Configuración Encriptación
y usuarios REST
Auditoria

70
Caso de estudio - Seguridad
• Método [Link]()
[Link]( {
user: <username>,
Parámetro Tipo Descripción
pwd: <password>,
Especifica un usuario
mechanism:
username string existente con privilegios de
<authentication mechanism>, acceso a esta base de datos.
digestPassword: <boolean>
Especifica la contraseña
}) password string
correspondiente
Opcional. Especifica
el mecanismo usado:
mechanism string
• SCRAM-SHA-1
• MONGODB-CR
Opcional. Determina si el
servidor recibe la contraseña
digestPassword boolean “digested” o “undigested”.
False = undigested
True = digested
71
Caso de estudio - Seguridad
• Mecanismos de Autenticación
• SCRAM-SHA-1:
• Estandar de la IEFT (Internet Engineering Task Force)
• Uno de los más usados para la autenticación de aplicaciones en Internet
• Usado junto con TLS (Transport Layer Security) aumenta el nivel de seguridad de las aplicaciones
• [Link]
• MONGODB-CR
• Usan las credenciales del cliente (usuario, password, base de datos) para
permitir el acceso.

72
Caso de estudio - Seguridad

• MongoDB provee control de acceso basado en Roles


• Privilegios: acción permitida sobre un recurso
• Recurso: Base de datos, colección, conjunto de
colecciones, o el cluster
• Privilegios:
• Query and Write Actions
• Database Management Actions
• Deployment Management Actions
• Replication Actions
• Sharding Actions
• Server Administration Actions
• Diagnostic Actions
• Internal Actions
73
Caso de estudio - Seguridad

• Roles predefinidos
• Database User Roles
• Database Administration Roles
• Cluster Administration Roles
• Backup and Restoration Roles
• All-Database Roles
• Superuser Roles
• Internal Role
• [Link]
built-in-roles/

74
Caso de estudio - Seguridad
• Roles definidos por el usuario
• Pueden heredar de otros roles
• [Link](role, writeConcern)
{
role:"<name>",
privileges: [
{ resource: {<resource>}, actions: [
"<action>", ... ] },
...
],
roles: [
{ role: "<role>", db :"<database>" } |
"<role>",
...
]
}
75
Caso de estudio - Seguridad
• Creación de usuarios
• Se crean a partir de los Roles
• [Link](user, writeConcern)

{
user: "<name>",
pwd: "<cleartext password>",
customData: { <any information> },
roles: [
{ role: "<role>", db: "<database>" } |
"<role>",
...
]
}

[Link]
76
Agenda
Modelo de datos

Operaciones

Técnicas usadas

Cuando usar

Caso de estudio

Operaciones

Técnicas

Consultas
Caso de estudio – Consultas avanzadas
• Consultas con documentos embebidos
[Link]( [
{ item: "journal", instock: [ { warehouse: "A", qty: 5 }, { warehouse: "C", qty: 15 } ] },
{ item: "notebook", instock: [ { warehouse: "C", qty: 5 } ] },
{ item: "paper", instock: [ { warehouse: "A", qty: 60 }, { warehouse: "B", qty: 15 } ] },
{ item: "planner", instock: [ { warehouse: "A", qty: 40 }, { warehouse: "B", qty: 5 } ] },
{ item: "postcard", instock: [ { warehouse: "B", qty: 15 }, { warehouse: "C", qty: 35 } ] }
]);
No
retorna
[Link]( { "instock": { warehouse: "A", qty: 5 } } ) un
resultado
[Link]( { "instock": { qty: 5, warehouse: "A" } } )
Caso de estudio – Consultas avanzadas
• Consultas con documentos embebidos
[Link]( [
{ item: "journal", instock: [ { warehouse: "A", qty: 5 }, { warehouse: "C", qty: 15 } ] },
{ item: "notebook", instock: [ { warehouse: "C", qty: 5 } ] },
{ item: "paper", instock: [ { warehouse: "A", qty: 60 }, { warehouse: "B", qty: 15 } ] },
{ item: "planner", instock: [ { warehouse: "A", qty: 40 }, { warehouse: "B", qty: 5 } ] },
{ item: "postcard", instock: [ { warehouse: "B", qty: 15 }, { warehouse: "C", qty: 35 } ] }
]);

[Link]( { '[Link]': { $lte: 20 } } )

[Link]( { '[Link]': { $lte: 20 } } )


Caso de estudio – Consultas avanzadas
• Consultas con documentos embebidos
[Link]( [
{ item: "journal", instock: [ { warehouse: "A", qty: 5 }, { warehouse: "C", qty: 15 } ] },
{ item: "notebook", instock: [ { warehouse: "C", qty: 5 } ] },
{ item: "paper", instock: [ { warehouse: "A", qty: 60 }, { warehouse: "B", qty: 15 } ] },
{ item: "planner", instock: [ { warehouse: "A", qty: 40 }, { warehouse: "B", qty: 5 } ] },
{ item: "postcard", instock: [ { warehouse: "B", qty: 15 }, { warehouse: "C", qty: 35 } ] }
]);

[Link]( { "instock": { $elemMatch: { qty: 5, warehouse: "A" } } } )


Caso de estudio – Consultas avanzadas
• Cursores:
• El método [Link]() consulta una colección y retorna un cursor
a los documentos resultantes
• Para acceder a los documentos se necesita iterar el cursor

var myCursor = [Link]( { type: 2 } );


var myCursor = [Link]( { type: 2 } );

while ([Link]()) {
[Link](printjson);
print(tojson([Link]()));
}

[Link]
Caso de estudio – Consultas avanzadas
• Agregación: operaciones que procesan registros de datos y
retornan resultados calculados
• Posee tres formas de agregación

Operaciones de
Pipeline de agregación: Map-Reduce: agregación de
propósito simple:
• framework para • Operaciones con dos • comandos de base de
llevar a cabo tareas fases Map y Reduce. datos de propósito
de agregación. Usa funciones de especial
Modelado en el Javascript
concepto de
pipelines de
procesamiento de
datos
Caso de estudio – Consultas avanzadas
• Pipeline de agregación: Es una serie de transformación de
Documentos
• Se ejecuta en estapas (stages)
• La entrada original es una colección
• Las salidas son documentos, cursores o colecciones

$match $project $group $sort

• Escrito en C++
• Trabaja bien con Shardings

[Link]
Pipeline de agregación – algunas etapas
$match: $project: $group:
•fitra documentos •agrega o elimina columnas •aplica operaciones de
en el documento agrupación a cada grupo de
documentos ($sum, $avg,
$min, $max, etc)

$unwind: $sort: $limit /$skip:


•convierte documentos en •ordena los documentos •página los documentos
una matriz con ciertas
características

$geoNear: $lookup:
•ordena los documentos por •realiza un left outer join
proximidad geográfica con otra colección en la
misma base de datos

[Link]
Pipeline de agregación - etapas

• Ejemplo:
Pipeline de agregación - etapas

• Ejemplo lookup:

[Link]
Pipeline de agregación – Ejemplo lookup

[Link]
Pipeline de agregación – Ejemplo lookup

[Link]
Pipeline de agregación
[Link]( [
{ _id: 0, name: "Pepperoni", size: "small", price: 19, [Link]( [
quantity: 10, date: ISODate( "2021-03-13T08:14:30Z" ) },
{ _id: 1, name: "Pepperoni", size: "medium", price: 20,
// Stage 1: Filter pizza order documents by pizza size
quantity: 20, date : ISODate( "2021-03-13T09:13:24Z" ) },
{
{ _id: 2, name: "Pepperoni", size: "large", price: 21,
quantity: 30, date : ISODate( "2021-03-17T09:22:12Z" ) }, $match: { size: "medium" }
{ _id: 3, name: "Cheese", size: "small", price: 12, },
quantity: 15, date : ISODate( "2021-03-13T11:21:39.736Z" ) },
{ _id: 4, name: "Cheese", size: "medium", price: 13,
// Stage 2: Group remaining documents by pizza name and calculate total quantity
quantity:50, date : ISODate( "2022-01-12T21:23:13.331Z" ) },
{ _id: 5, name: "Cheese", size: "large", price: 14, {
quantity: 10, date : ISODate( "2022-01-12T05:08:13Z" ) }, $group: { _id: "$name", totalQuantity: { $sum: "$quantity" } }
{ _id: 6, name: "Vegan", size: "small", price: 17, }
quantity: 10, date : ISODate( "2021-01-13T05:08:13Z" ) },
{ _id: 7, name: "Vegan", size: "medium", price: 18,
quantity: 10, date : ISODate( "2021-01-13T05:10:13Z" ) }
])
])

[Link]
Pipeline de agregación

[Link]
Caso de estudio – Consultas avanzadas
• Map-Reduce:
• Map: procesa cada documento y emite uno o dos objetos y
• Reduce: combina la salida de la operación Map.

[Link]
Caso de estudio – Consultas avanzadas
• Operaciones de agregación de propósito simple: comandos de
base de datos de propósito especial
• Count: cuenta los elementos de una colección que cumplen la condición
de la consulta
• Disctint: Encuentra los valores diferentes de un campo
[Link](
[Link]( { count: 'orders' }
{ )
count: <collection or view>,
query: <document>, { "n" : 26, "ok" : 1 }
limit: <integer>,
skip: <integer>,
comment: <any>
}
)
Caso de estudio – Consultas avanzadas
• Operaciones de agregación de propósito simple: comandos de
base de datos de propósito especial
• Count: cuenta los elementos de una colección que cumplen la condición
de la consulta
• Disctint: Encuentra los valores diferentes de un campo
[Link](
{
distinct: "<collection>",
key: "<field>",
[Link] ( { distinct: "inventory", key: "dept" } )
query: <query>,
readConcern: <read concern document>,
collation: <collation document>,
comment: <any>
}
)
Caso de estudio – Consultas avanzadas - Explain
• Retorna informacion del plan de consulta para las siguientes
operaciones:
• aggregate(); count(); find(); group(); remove(); and update() methods.
• [Link]().<method(...)>
• Presenta el plan de consulta (query plan) como un árbol de etapas.
• Cada etapa pasa sus resultados (es decir, documentos o claves de índice) al nodo
padre.
• Los nodos hoja acceden a la colección o los índices.
• Los nodos internos manipulan los documentos o las claves de índice que se
derivan de los nodos secundarios.
• El nodo raíz es la etapa final de la que MongoDB deriva del conjunto de
resultados
Caso de estudio – Consultas avanzadas - Explain
• Algunas de las operaciones del plan son:
• COLLSCAN Scan de una coleccion
• IXSCAN para búsqueda en el índice
• FETCH para recuperación de documentos
• SHARD_MERGE para mezclar results de fragmentos

• El explain tiene los siguientes parámetros opcionales (modos de


verbosity)
• queryPlanner: es el modo por defecto, retorna solamente el plan de consulta
• executionStats: muestra el plan de consulta e información de ejecución
• allPlansExecution: muestra todos los posibles planes de ejecución.
Caso de estudio – EXPLAIN
• Ejemplos
• [Link]().count( { quantity: { $gt: 50 } } )
• Retorna solo el plan de consulta
• [Link]( { quantity: { $gt: 50 }, category: "apparel" }
).explain("executionStats")
• Retorna el plan de consulta e información de ejecución
• [Link]({ quantity: { $lt: 1000}, category: "apparel" },
{ $set: { reorder: true } }).explain("allPlansExecution")

• No modifica los datos pero retorna todos los posibles planes de ejecución
Caso de estudio – Optimizador
• El optimizador de MongoDB, procesa las consultas y selecciona el
plan más eficiente con los índices disponibles.
• El optimizador de consultas solo almacena en caché los planes
para aquellas formas de consulta que pueden tener más de un
plan viable.
• Para cada consulta, el planificador de consultas busca en la
memoria caché del plan de consultas una entrada que se ajuste a
la forma de la consulta.
Caso de estudio – Optimizador
• Para cada consulta, el planificador de consultas busca en la
memoria caché del plan de consultas una entrada que se ajuste a
la forma de la consulta.
• Si no hay entradas coincidentes, genera planes candidatos para la
evaluación durante un período de prueba, elige un plan ganador, crea
una entrada de caché que contiene el plan ganador y lo utiliza para
generar los documentos resultantes.
• Si existe una entrada coincidente, el planificador de consultas genera un
plan basado en esa entrada y evalúa su desempeño a través de un
mecanismo de replanificación.
Caso de estudio – Optimizador
• Este mecanismo toma una decisión de aprobación / falla basada
en el rendimiento del plan y mantiene o desaloja la entrada de
caché. En el desalojo, el planificador de consultas selecciona un
nuevo plan utilizando el proceso de planificación normal y lo
almacena en caché.
• El planificador de consultas ejecuta el plan y devuelve los
documentos de resultados para la consulta.
Caso de estudio – EXPLAIN
• Ejemplo queryPlanner

{
"queryPlanner" : {
"plannerVersion" : <int>, "namespace" : <string>, "indexFilterSet" : <boolean>,
"parsedQuery" : {
...
},
"winningPlan" : {
"stage" : <STAGE1>,
...
"inputStage" : {
"stage" : <STAGE2>,
...
"inputStage" : {
...
}
}
},
"rejectedPlans" : [
<candidate plan 1>,
...
]
}
Caso de estudio – EXPLAIN
• Ejemplo execucionStats

"executionStats" : { "inputStage" : {
"executionSuccess" : <boolean>, "stage" : <STAGE2>,
"nReturned" : <int>, ...
"executionTimeMillis" : <int>, "nReturned" : <int>,
"totalKeysExamined" : <int>, "executionTimeMillisEstimate" : <int>,
"totalDocsExamined" : <int>, "keysExamined" : <int>,
"executionStages" : { "docsExamined" : <int>,
"stage" : <STAGE1> ...
"nReturned" : <int>, "inputStage" : {
"executionTimeMillisEstimate" : <int>, ...
"works" : <int>, }
"advanced" : <int>, }
"needTime" : <int>, },
"needYield" : <int>, "allPlansExecution" : [
"isEOF" : <boolean>, { <partial executionStats1> },
... { <partial executionStats2> },
...
]
}

También podría gustarte