BASE DE DATOS II

CONSULTA MONGODB

ANDRES FELIPE NUÑEZ CASTRO

CORPORACIÓN UNIVERSITARIA DEL HUILA CORHUILA

NEIVA - HUILA

2019
 CONSULTA
- Enumera ventajas y desventajas de implementar bases de datos con MongoDB con respecto
a su versión en un gestor relacional.
• Ventajas:
1. Esquema muy flexible: cada documento de la colección puede almacenar campos
diferentes.
2. Lenguaje de consulta y manipulación sencillos (operaciones CRUD).
3. Facilidad de integración con aplicación gracias al uso del lenguaje BSON,
fácilmente traducibles a JSON.
4. Accesibilidad a los datos.
5. Posibilidad de realizar lecturas en instancias secundarias, repartiendo la carga de
trabajo.

• Desventajas:
1. Aplicaciones clientes mas complejas de desarrollar al trabajar con esquemas
flexibles, desnormalizados y dinámicos.
2. No garantiza ACID.
3. Consistencia eventual, podrían leerse datos de nodos secundarios que aun no estén
actualizados.
4. Sin soporte transaccional.
5. No es capaz de realizar transacciones.
6. Carece de algo tan fundamental como los joins para las consultas

- Define el concepto de Shard Key y cómo afecta al rendimiento de las consultas.

Shard Key es la clave para repartir los documentos de manera particionada, es un campo de
MongoDB, que permite decidir en que servidor debe almacenarse los documentos.
Mediante un proceso conocido como mongos, que recibe las peticiones y las envía al
servidor correcto.

Afecta al rendimiento de las consultas debido a que balancea la carga de datos o

documentos al servidor, el rendimiento de la base de datos depende de la clave se que se
elija, ya que influyen la latencia de las consultas en los servidores, ya que las consultas se
realizan sobre los Shards, y la consultan incluye la Shard Key y estas afectan las latencias
de todos los servidores, lo que hace que sea muy importante elegir la Shard Key de forma
correcta, ya que marcara el rendimiento futuro de la base de datos.

La Shard Key es la clave que determina como se divide una colección en diferentes chunk,
siempre ha de ser un campo del documento que este indexado, si en una consulta se incluye
la shard key solo se consultaran aquellos shard que contengan los documentos requerido, si
en una consulta no se incluye la shard key, se busca en todos los shard , haciendo que la
consulta sea ineficiente

- Explica cómo actúa MongoDB si el nodo primario de un replica set se cae.

Si el nodo primario de una replica set se cae, ya que este es el mecanismo que proporciona
MongoDB para garantizar la alta disponibilidad de la base de datos, el nodo primario es el
 nodo sobre el que se realizan las escrituras y principalmente las lecturas, afectando
directamente las consultas en las bases de datos, este nodo es el único capaz de recibir
escrituras y guarda las copias principales.
En este caso uno de los secundarios toma el papel de primario, se elige por un sistema de
votaciones que tiene varias cosas en cuenta, considerando que al menos 2 secundarios que
estén activos. El driver del cliente automáticamente redirige sus peticiones al nuevo
primario. Si después el antiguo primario vuelve a conectarse asumirá el papel de
secundario. El problema surge cuando el antiguo primario tenía información antes de caer
que aún no había transmitido a los secundarios.

- Resumen las diferentes opciones de Write Concern y de lectura de datos.

Write Concern o cometido de escritura

o Puede no requerirse confirmación alguna, la aplicación cliente supone que se ha
escrito el dato.
o Confirmación de escritura únicamente en primario.
o Confirmación de escritura en primario y uno o varios secundarios.
o Confirmación que se haya escrito o no en el Journal
El problema es que cuanto mayor sea la durabilidad exigida, mayor será el tiempo
necesario en obtener esa garantía, puesto que será necesario esperar la confirmación de
un mayor número de nodos. Existen varios niveles:

0 - No se espera confirmación. Es suficiente con tener una conectividad con el conjunto

y poder emitir el comando de escritura. Simplemente lanza la orden y no espera a saber
si se ha ejecutado correctamente. Es un método rápido pero inseguro.
1 (valor por defecto) - Se espera únicamente la confirmación del nodo primario
>=2 - Se espera la confirmación del nodo primario y al menos uno de los secundarios
majority - Se espera la confirmación de una mayoría simple de nodos dentro del
conjunto.Esta mayoría se obtiene dividiendo por 2 el número de nodos del conjunto y
redondeando hacia arriba. Por ejemplo, en caso de un conjunto de 3 nodos, la mayoría
simple sería 2.
Lectura de datos
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).

Existen 4 modalidades de read concern:

local: devuelve el dato más reciente en el cluster. Cualquier dato que haya sido escrito en el
nodo primario puede ser elegido para devolverse en el read concern local. Sin embargo, no
se garantiza que este dato sea replicado a los miembros del conjunto en caso de fallo. Este
es el nivel por defecto en las operaciones de lectura contra el nodo primario.
available: es el equivalente de local, pero cuando las operaciones de lectura se efectúan
contra un nodo secundario.
majority: únicamente devuelve datos que hayan sido confirmados en una mayoría de nodos
dentro del conjunto. El único escenario en el que un dato obtenido con majority no sea
consistente, es cuando se produce un fallo en una mayoría de nodos del conjunto, y ese dato
no ha sido escrito a ninguno de los nodos restantes.
linearizable: a partir de MongoDB 3.4, devuelve datos que hayan sido confirmados por una
mayoría de nodos, pero permite al desarrollador establecer su propia funcionalidad.

- Explica, de forma resumida, los tipos de índices que se pueden definir en un MongoDB,
cual es el objetivo de cada uno y los posibles modificadores con los que se pueden definir.
Los índices ayudan a optimizar las consultas.

• Default_id: existe por defecto sobre el campo_id. Garantiza Unicidad.

• Single field: índice creado sobre un solo campo de la colección. Puede ser ascendente
(1) o descendente (-1): db.socios.createIndex({“nombre”:1})
• Compound: índice creado sobre varios campos de la colección:
db.socios.createIndex({“nombre”:1, “apellido1”:-1})
Algunas propiedades de los índices:
TTL: índices que “caducan” al cabo de un tiempo.
Db.socidos.createIndex({“nombre”:1}, {expireAfterSeconds: 7200})
Unique: garantiza unicidad
Db.socios.createIndex ({“numSocio”:1}, {unique: true})
Partial: Se crean exclusivamente sobre documentos con valores concretos en el campo
(índice condicionado)
Db.socios.createIndex ({“nombre:1”}, {partialFilterExpression: {numsocio: {$gt:300}}})
Sparse: Sólo se crea el índice en documentos que contienen el campo.
 db.socios.createIndex({“nombre”: 1}, {sparse: true})
Entregar archivo PDF, plazo hasta el 13 de noviembre de 2019