No SQL BD
No SQL BD
VOLÚMENES DE DATOS
Maestría en Sistemas de Información
Operaciones
Técnicas usadas
Cuando usar
Caso de estudio
Estructuras y datos
Consultas
Estructuras
Técnicas
Objetivos del tema
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
7
Modelo de datos - Estructuras
• 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
[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" } }
])
29
Caso de estudio - Operaciones
• CRUD
• Update
[Link](
{ item: "paper" },
{$set: { "[Link]": "cm", status: "P" },
$currentDate: { lastModified: true } }
)
30
Caso de estudio - Operaciones
• CRUD
• Delete
• Otros métodos
•[Link]()
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
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
46
Caso de estudio- Índices
• El uso de índices busca mejorar la eficiencia de las operaciones de consulta
47
Caso de estudio - Índices
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
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
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
[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
mongod mongod
mongod
63
Caso de estudio - Sharding
64
Caso de estudio - Sharding
65
Caso de estudio - Sharding
Aplicación
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
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
• 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 } ] }
]);
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
• 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)
$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
• 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> },
...
]
}