• Author / Uploaded
• Piipe Nuñez

Citation preview

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