13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

Inicio

SEMANA 1

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 1/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

UD3: Bases de Datos NoSQL

Las bases de datos NoSQL han emergido como una solución clave
para los desafíos planteados por la creciente necesidad de
almacenar y procesar grandes volúmenes de datos no
estructurados o semiestructurados. A diferencia de las bases de
datos relacionales tradicionales, NoSQL ofrece una mayor
flexibilidad y una escalabilidad horizontal adecuada para
aplicaciones modernas que manejan datos en tiempo real y
grandes cantidades de usuarios concurrentes. Con la llegada de
tecnologías como el Big Data, Internet de las Cosas (IoT) y aplicaciones web y móviles altamente
dinámicas, NoSQL se ha convertido en una pieza fundamental en el arsenal de herramientas de
desarrollo.

El enfoque de NoSQL no implica reemplazar a las bases de datos relacionales, sino más bien
complementarlas, aportando modelos de almacenamiento alternativos que permiten resolver
problemáticas específicas, tales como la necesidad de una alta disponibilidad y la capacidad de
respuesta rápida ante cargas de trabajo masivas. En esta unidad, exploraremos diferentes tipos de
bases de datos NoSQL, sus características, arquitecturas y cuándo es conveniente su uso para
solucionar problemas reales.

Videos de apoyo

[Link]

HolaMundo. NO SQL . 19 mar 2021

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 2/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

3.1 Generalidades de NoSQL

Las bases de datos NoSQL representan una alternativa a las bases de

datos relacionales tradicionales, pensadas para enfrentar los desafíos de
escalabilidad, flexibilidad en el modelado de datos, y el manejo de
grandes volúmenes de datos que pueden ser no estructurados o
semiestructurados. Surgieron como respuesta a las necesidades de
aplicaciones modernas, que requieren un mayor rendimiento y la capacidad de adaptarse
rápidamente a cambios en los requerimientos del negocio. Estas bases de datos no siguen el esquema
rígido de las tablas relacionales, lo que les permite manejar datos de formas más variadas y
distribuidas.

Videos de apoyo

[Link]

Miguel Hernandez Liebano. Introducción a Bases de Datos NoSQL. 27

abr 2020

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 3/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

3.1.1 Introducción a NoSQL:

Las bases de datos NoSQL (Not Only SQL) surgieron

como una respuesta a las limitaciones de las bases de
datos relacionales tradicionales en el manejo de grandes
volúmenes de datos y la necesidad de escalabilidad
horizontal. A diferencia de las bases de datos relacionales,
que almacenan datos en tablas con esquemas rígidos y
utilizan el lenguaje SQL para las consultas, las bases de
datos NoSQL ofrecen modelos de datos más flexibles y
están diseñadas para manejar datos no estructurados o semiestructurados.

Definición y Contexto Histórico

El término "NoSQL" se refiere a sistemas de gestión de bases de datos que no siguen el modelo
relacional tradicional. Estas bases de datos permiten el almacenamiento y la consulta de datos fuera
de las estructuras tabulares convencionales, ofreciendo una mayor flexibilidad en el modelado de
datos. El concepto de NoSQL ganó prominencia a finales de la década de 2000, impulsado por
empresas como Amazon, Google y Facebook, que enfrentaban desafíos significativos en el manejo de
grandes volúmenes de datos y requerían soluciones más escalables y flexibles que las ofrecidas por
las bases de datos relacionales tradicionales.

Razones del Surgimiento de las Bases de Datos NoSQL

Las bases de datos NoSQL surgieron para abordar varias limitaciones de las bases de datos
relacionales:

Escalabilidad

Las bases de datos relacionales suelen escalar verticalmente (mejorando el hardware del
servidor), lo que puede ser costoso y tiene límites físicos. En contraste, las bases de datos
NoSQL están diseñadas para escalar horizontalmente, permitiendo la adición de más
servidores para manejar incrementos en la carga de trabajo.

Flexibilidad en el Esquema

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 4/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

Las bases de datos relacionales requieren esquemas predefinidos, lo que puede ser restrictivo
cuando los datos evolucionan con el tiempo. Las bases de datos NoSQL permiten esquemas
dinámicos, facilitando la adaptación a cambios en la estructura de los datos sin necesidad de
reestructuraciones complejas.

Rendimiento

Para ciertas aplicaciones, especialmente aquellas que manejan grandes volúmenes de datos
o requieren baja latencia, las bases de datos relacionales pueden no ofrecer el rendimiento
necesario. Las bases de datos NoSQL están optimizadas para operaciones de lectura y
escritura rápidas, adecuadas para aplicaciones en tiempo real.

Diferencias Fundamentales con los Sistemas Relacionales

Modelo de Datos

Las bases de datos relacionales utilizan tablas con filas y columnas, mientras que las bases
de datos NoSQL emplean diversos modelos, como documentos, clave-valor, grafos y
columnas anchas.

Esquema

Las bases de datos relacionales requieren un esquema fijo y definido antes de la inserción de
datos. Las bases de datos NoSQL permiten esquemas flexibles o incluso la ausencia de
esquema, facilitando la incorporación de datos heterogéneos.

Escalabilidad

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 5/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

Las bases de datos relacionales generalmente escalan verticalmente, mejorando el hardware

existente. Las bases de datos NoSQL están diseñadas para escalar horizontalmente,
distribuyendo la carga a través de múltiples servidores.

Consistencia y Disponibilidad

Las bases de datos relacionales suelen priorizar la consistencia de los datos, siguiendo las
propiedades ACID (Atomicidad, Consistencia, Aislamiento, Durabilidad). Las bases de datos
NoSQL, en cambio, pueden priorizar la disponibilidad y la partición tolerancia, siguiendo el
teorema CAP, lo que puede implicar una consistencia eventual en lugar de inmediata.

Estas diferencias hacen que las bases de datos NoSQL sean especialmente adecuadas para
aplicaciones que requieren alta escalabilidad, flexibilidad en el manejo de datos y rendimiento
optimizado para grandes volúmenes de información.
Videos de apoyo

[Link]

Miguel Hernandez Liebano . Introducción a Bases de Datos NoSQL. 27

abr 2020

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 6/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

3.1.2 Clasificación de Bases de Datos NoSQL:

Las bases de datos NoSQL se clasifican en varios tipos, cada uno diseñado para satisfacer
necesidades específicas de almacenamiento y consulta de datos. A continuación, se detallan las
principales categorías, junto con ejemplos y aplicaciones prácticas:

Bases de Datos de Documentos

Las bases de datos de documentos son ideales para almacenar datos

semiestructurados y no estructurados. Los datos se guardan en un
formato similar a JSON o XML, donde cada documento es independiente
y puede tener un esquema diferente, lo que proporciona una gran
flexibilidad.

Características:
Los documentos contienen pares de clave-valor que pueden
incluir datos anidados y listas, lo que facilita el modelado de
objetos complejos.
No requieren un esquema fijo, lo que significa que cada
documento puede tener diferentes campos y estructuras, lo
cual es útil para datos que evolucionan frecuentemente.
Ejemplos:
MongoDB: Utiliza BSON (una extensión de JSON) para
almacenar documentos. Es ampliamente usado debido a su
capacidad para escalar horizontalmente y manejar consultas
complejas de documentos.
CouchDB: Almacena documentos JSON y permite la
sincronización de bases de datos distribuidas, lo que la hace
adecuada para aplicaciones móviles que necesitan
replicación.
Aplicaciones Prácticas:
Catálogos de productos: Tiendas en línea utilizan MongoDB
para almacenar productos con diferentes atributos que
cambian constantemente (tallas, colores, descripciones).
Sistemas de gestión de contenido (CMS): Aplicaciones que
necesitan manejar contenido generado por usuarios y no
requieren un esquema fijo. Ejemplo: aplicaciones como

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 7/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

WordPress que manejan blogs y publicaciones

personalizadas.

Bases de Datos Clave-Valor

Las bases de datos clave-valor son extremadamente eficientes para

almacenar datos simples, donde cada valor es accesible a través de una
clave única. Este modelo es similar a un diccionario o mapa hash.

Características:
Simplicidad extrema: solo admite operaciones básicas como
almacenar, recuperar y borrar mediante una clave.
Ideal para situaciones en las que la velocidad y simplicidad
son críticas.
Ejemplos:
Redis: Es una base de datos en memoria que permite
velocidades de acceso extremadamente rápidas. Soporta
operaciones complejas como conjuntos ordenados y listas,
además de replicación y persistencia.
Amazon DynamoDB: Proporciona un servicio totalmente
gestionado y es utilizado para manejar grandes volúmenes de
datos con baja latencia.
Aplicaciones Prácticas:
Almacenamiento de sesiones de usuario: Redis es
ampliamente utilizado para guardar información de sesión de
los usuarios, como las credenciales y el estado de la
navegación en sitios web.
Caché: Los datos que se necesitan recuperar rápidamente se
pueden almacenar temporalmente en Redis para reducir la
carga en los sistemas subyacentes.

Bases de Datos de Grafos

Las bases de datos de grafos están diseñadas para manejar relaciones

complejas y nodos interconectados. Los nodos representan las entidades

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 8/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

y las aristas, las relaciones entre estas entidades.

Características:
Almacenan relaciones entre nodos directamente en la base
de datos, lo que permite realizar consultas complejas de
relaciones en tiempo real.
Muy eficientes en la ejecución de consultas como "caminos
más cortos" o "detectar patrones", lo que no es eficiente en
bases de datos relacionales.
Ejemplos:
Neo4j: La base de datos de grafos más popular. Utiliza un
modelo de grafo propiedad y permite consultas rápidas para
analizar redes complejas.
JanusGraph: Escalable y diseñado para gestionar grandes
volúmenes de datos distribuidos en varios nodos.
Aplicaciones Prácticas:
Redes Sociales: Neo4j se utiliza para modelar redes de
amigos o conexiones en redes sociales, permitiendo
encontrar conexiones comunes, sugerir amigos y realizar
recomendaciones.
Motores de recomendación: Análisis de relaciones y
preferencias entre usuarios y productos para hacer
recomendaciones personalizadas. Netflix y Amazon son
ejemplos de empresas que usan grafos para recomendar
contenido y productos.

Bases de Datos Columnares

Las bases de datos columnares almacenan los datos en columnas en

lugar de filas. Este enfoque es ideal para la agregación de grandes
volúmenes de datos y consultas analíticas.

Características:
Almacenan cada columna por separado, lo que hace que las
operaciones de lectura para determinadas columnas sean
más rápidas.
Son altamente eficientes para tareas que requieren el
escaneo de grandes cantidades de datos para producir
informes.

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 9/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

Ejemplos:
Apache Cassandra: Desarrollado por Facebook y ahora
utilizado por empresas como Netflix para manejar datos a
gran escala. Cassandra tiene alta disponibilidad y permite
escribir datos en múltiples centros de datos sin interrumpir la
consistencia.
Apache HBase: Basada en Hadoop, HBase permite el
almacenamiento distribuido y escalable de datos grandes. Es
una buena opción para el procesamiento masivo de datos en
sistemas Hadoop.
Aplicaciones Prácticas:
Sistemas de registro: Cassandra se utiliza para almacenar
registros de actividad de usuarios y eventos, que luego
pueden ser analizados en busca de patrones de
comportamiento o problemas de rendimiento.
Análisis de Datos en Tiempo Real: HBase es utilizada para
almacenar y analizar datos en tiempo real en aplicaciones
como análisis de redes sociales y registros de sistemas de
monitoreo.

Comparación de los Tipos de Bases de Datos NoSQL

Cada tipo de base de datos NoSQL tiene sus propias fortalezas y limitaciones, lo que significa que
son más adecuadas para ciertos escenarios:

Cuadro Comparativo de Tipos de Bases de Datos NoSQL

Tipo de Base de Modelo de Datos Ejemplos Ventajas

Datos NoSQL

Documentos Documentos JSON, BSON, MongoDB, CouchDB Flexibilidad en el esquema,

XML ideal para datos
semiestructurados

Clave-Valor Pares clave-valor Redis, DynamoDB Altísimo rendimiento,

simplicidad

Grafos Nodos y aristas Neo4j, JanusGraph Representación y consulta de

relaciones complejas

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 10/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

Columnares Columnas de datos Apache Cassandra, Escalabilidad horizontal,

HBase optimización de consultas
masivas

Cada tipo de base de datos NoSQL se adapta mejor a ciertos tipos de problemas. La elección correcta
dependerá de las necesidades específicas de la aplicación, el volumen de datos, la complejidad de
las relaciones y los requisitos de rendimiento.
Videos de apoyo

[Link]

IntelDigital. Los 4 tipos más populares de base de datos NoSQL . 6

may 2018

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 11/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

3.1.3 Teorema CAP:

El teorema CAP (también conocido como teorema de Brewer) establece que es

imposible para un sistema distribuido garantizar Consistencia, Disponibilidad y
Tolerancia a Particiones de manera simultánea. En lugar de esto, un sistema
puede garantizar solo dos de las tres propiedades en un momento dado. Esta
limitación tiene un impacto profundo en el diseño de sistemas distribuidos,
obligando a los arquitectos a tomar decisiones de compromiso entre estos tres aspectos en función de
los requisitos específicos de cada aplicación.

Explicación del Teorema CAP

El teorema CAP describe tres propiedades fundamentales que cualquier sistema distribuido puede
proporcionar:

Consistencia (Consistency)

Definición: Todos los nodos del sistema distribuyen la misma información

en un momento dado. Cuando un dato es actualizado en uno de los
nodos, todos los demás nodos del sistema ven esa misma actualización al
mismo tiempo.

Ejemplo: En un sistema consistente, una vez que un cliente escribe

un dato, cualquier otro cliente que lea ese dato inmediatamente
después recibirá el valor actualizado.

Disponibilidad (Availability)

Definición: Cada solicitud realizada por un cliente debe recibir una

respuesta, incluso si hay fallos en algunos de los nodos del sistema.

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 12/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

Ejemplo: Un sistema con alta disponibilidad siempre devuelve una

respuesta, sin importar si se produjo un fallo, aunque en algunos
casos esa respuesta pueda ser de datos antiguos o inconsistente.

Tolerancia a Particiones (Partition Tolerance)

Definición: El sistema sigue operando incluso si existe una partición en la

red que impide la comunicación entre nodos. Esto significa que si se
pierde la conectividad entre dos partes del sistema, ambas partes
seguirán funcionando independientemente.

Ejemplo: En un sistema tolerante a particiones, aunque se divida la

red en dos partes, ambas continuarán aceptando solicitudes.

Impacto del Teorema CAP en el Diseño de Sistemas Distribuidos

El teorema CAP tiene un impacto significativo en cómo se diseñan y se construyen los sistemas
distribuidos. Al tener que elegir solo dos de las tres propiedades, los diseñadores de sistemas deben
determinar cuál de estas propiedades tiene mayor prioridad según el contexto de la aplicación. Las
elecciones son típicamente:

Consistencia y Tolerancia a Particiones (CP):

Ejemplo: HBase es un ejemplo de una base de datos que prioriza

consistencia y tolerancia a particiones. En caso de una partición de red, el
sistema dejará de ser disponible hasta que se pueda garantizar la
consistencia de los datos.

Aplicaciones: Esta opción es preferida en situaciones donde la

consistencia de los datos es crucial, como en sistemas financieros o
transacciones bancarias.

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 13/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

Disponibilidad y Tolerancia a Particiones

(AP):

Ejemplo: Cassandra y DynamoDB son ejemplos de bases de datos que

priorizan disponibilidad y tolerancia a particiones. En caso de que haya
una partición en la red, el sistema puede devolver datos antiguos, pero
nunca dejará de responder.

Aplicaciones: Este tipo de sistema se utiliza en aplicaciones donde

es más importante que el sistema siempre responda, incluso si no
garantiza la consistencia más actual, como servicios de mensajería
instantánea.

Consistencia y Disponibilidad (CA):

En la práctica, ningún sistema distribuido puede garantizar al mismo

tiempo consistencia y disponibilidad sin perder tolerancia a particiones.
Esta combinación se puede lograr en sistemas que no son distribuidos o
en los que no se consideran fallos de red.

Ejemplo: Bases de datos relacionales con una única instancia

que garantizan consistencia y disponibilidad mientras no haya
problemas de partición en la red.

Compromisos del Teorema CAP

Los compromisos inherentes al teorema CAP significan que los sistemas distribuidos deben priorizar
una u otra propiedad según sus necesidades. Algunos ejemplos clave de cómo se aplica esto incluyen:

Sistemas de e-commerce

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 14/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

Para aplicaciones como compras en línea, la alta disponibilidad es crucial, ya que un cliente
debe poder realizar sus compras sin interrupciones. Sin embargo, una ligera inconsistencia
temporal puede ser tolerada, ya que los sistemas de pagos u órdenes se sincronizan
eventualmente.

Sistemas de pagos y bancos

En el ámbito financiero, la consistencia es prioritaria. Los sistemas bancarios necesitan

asegurar que cada transacción esté perfectamente sincronizada entre todos los nodos antes
de proceder con la siguiente operación. En estos casos, la disponibilidad puede
comprometerse temporalmente durante una partición.

El teorema CAP es una guía fundamental para el diseño de sistemas distribuidos. Determina que no
se puede garantizar simultáneamente consistencia, disponibilidad y tolerancia a particiones, obligando
a los arquitectos de sistemas a hacer compromisos en función de las prioridades de su aplicación. La
elección entre CP y AP depende del contexto específico y de la naturaleza del problema que se intenta
resolver, y cada una tiene sus ventajas y limitaciones. Los sistemas modernos, especialmente las
bases de datos NoSQL, adoptan enfoques que priorizan estos aspectos según las demandas del
mercado, la naturaleza de los datos y los requisitos de los usuarios.
Videos de apoyo

[Link]

Programación en español .CAP Theorem - Explicación con ejemplos.11 jul 2022

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 15/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

3.1.4 Ventajas y Desventajas de NoSQL

Las bases de datos NoSQL presentan una serie de ventajas y desventajas frente a las bases de datos
relacionales tradicionales. A continuación se presenta un análisis detallado de estos puntos, así como
algunos casos de uso ideales para NoSQL.

Ventajas de NoSQL

Escalabilidad Horizontal

Descripción: Las bases de datos NoSQL están diseñadas para escalar

horizontalmente agregando más nodos a la infraestructura en lugar de aumentar las

capacidades de un solo servidor (escalabilidad vertical). Esto significa que se pueden añadir
más máquinas para manejar mayores volúmenes de datos y cargas de trabajo.

Beneficio: Escalar horizontalmente permite manejar un crecimiento exponencial de datos sin

incurrir en los altos costos que implicaría una mejora constante de hardware en un único
servidor.

Flexibilidad en el Esquema

Descripción: A diferencia de las bases de datos relacionales que requieren un

esquema fijo antes de insertar datos, NoSQL permite almacenar datos sin un esquema
predefinido.

Beneficio: Esto resulta en una gran flexibilidad para adaptar los datos según cambien
los requisitos de la aplicación, sin tener que realizar costosos cambios estructurales. Es
especialmente útil en aplicaciones en las que los datos pueden variar en estructura.

Rendimiento y Baja Latencia

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 16/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

Descripción: Algunas bases de datos NoSQL como Redis están optimizadas para

realizar operaciones rápidas de lectura y escritura, al ser almacenadas en memoria.

Beneficio: Proveen respuestas rápidas, lo cual es fundamental en aplicaciones en

tiempo real, como mensajería instantánea o sistemas de recomendación.

Alta Disponibilidad y Tolerancia a Fallos

Descripción: Muchas bases de datos NoSQL están diseñadas para tener una alta

disponibilidad y ser tolerantes a particiones mediante la replicación de datos en múltiples

nodos.

Beneficio: Permiten garantizar que el sistema siga operando incluso cuando algunos de
sus nodos fallen. Esto es esencial para aplicaciones que no pueden permitirse
interrupciones.

Manejo de Datos No Estructurados:

Descripción: NoSQL maneja una gran variedad de datos no estructurados y

semiestructurados, como documentos, datos de redes sociales y contenido multimedia.

Beneficio: Es ideal para aplicaciones que requieren almacenar y procesar grandes

cantidades de datos heterogéneos que no se ajustan bien a un esquema tabular.

Desventajas de NoSQL

Inconsistencia Eventual

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 17/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

Descripción: En muchos sistemas NoSQL, se prioriza la disponibilidad y la

tolerancia a fallos sobre la consistencia inmediata de los datos, siguiendo el teorema CAP.

Limitación: Esto significa que, en algunos casos, las lecturas pueden no reflejar la
última actualización realizada (inconsistencia eventual), lo cual puede ser problemático
para aplicaciones que necesitan una precisión absoluta en tiempo real.

Falta de Estándares

Descripción: A diferencia del SQL, que es un estándar ampliamente adoptado,

NoSQL no tiene un lenguaje de consulta unificado ni una estructura estándar.

Limitación: Esto conlleva una curva de aprendizaje pronunciada y dificulta la

portabilidad del conocimiento entre diferentes sistemas NoSQL.

Funcionalidad Limitada en Consultas Complejas

Descripción: Las bases de datos NoSQL, como las de clave-valor, suelen ser

limitadas en cuanto a capacidades de consulta y operaciones complejas.

Limitación: Las operaciones como join entre tablas, que son comunes en bases de
datos relacionales, no se pueden realizar fácilmente, lo cual puede ser un problema
para sistemas que necesitan realizar consultas relacionales complejas.

Madurez Relativa

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 18/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

Descripción: En comparación con las bases de datos relacionales, que llevan

décadas de desarrollo, las bases de datos NoSQL son relativamente jóvenes.

Limitación: Esto implica que algunas bases de datos NoSQL pueden no tener el mismo
nivel de madurez en términos de características avanzadas, herramientas de monitoreo
y soporte técnico.

Transacciones ACID Limitadas

Descripción: Las bases de datos relacionales aseguran transacciones ACID

(Atomicidad, Consistencia, Aislamiento, Durabilidad), lo cual es crucial para operaciones

bancarias y financieras.

Limitación: La mayoría de las bases de datos NoSQL ofrecen una versión más laxa de
las propiedades ACID, lo cual limita su aplicabilidad en sistemas donde la integridad de
los datos es crítica.

Casos de Uso Ideales para NoSQL

Aplicaciones Web y Redes Sociales

Descripción: Sitios como Facebook, Twitter y LinkedIn generan grandes cantidades de datos
no estructurados y requieren respuestas rápidas para proporcionar una buena experiencia al
usuario.

NoSQL Aplicable: Bases de datos de documentos como MongoDB son ideales para
almacenar perfiles de usuario y sus interacciones.

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 19/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

Caché y Almacenamiento en Memoria

Descripción: En aplicaciones que necesitan almacenar en memoria datos frecuentemente

consultados para reducir el tiempo de acceso, una base de datos clave-valor es una excelente
opción.

NoSQL Aplicable: Redis se usa comúnmente para almacenar sesiones de usuario,

caché de páginas y datos de configuración.

Sistemas de Comercio Electrónico

Descripción: Las tiendas en línea necesitan flexibilidad para almacenar datos de productos
que pueden tener atributos diferentes y cambiar frecuentemente.

NoSQL Aplicable: MongoDB se utiliza para gestionar catálogos de productos con

descripciones que cambian constantemente.

Sistemas de Análisis en Tiempo Real

Descripción: Las aplicaciones que procesan grandes volúmenes de datos generados

continuamente, como los registros de sensores o el análisis de comportamiento de usuarios,
necesitan una solución escalable.

NoSQL Aplicable: Apache Cassandra permite el análisis en tiempo real de grandes

volúmenes de datos distribuidos.

Motores de Recomendación

Descripción: Los motores de recomendación necesitan analizar las relaciones entre usuarios
y elementos (productos, películas, etc.) para hacer sugerencias personalizadas.

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 20/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

NoSQL Aplicable: Neo4j (una base de datos de grafos) permite modelar y analizar
relaciones complejas para sugerir elementos con base en patrones de comportamiento.

Las bases de datos NoSQL ofrecen ventajas clave como la escalabilidad horizontal, la flexibilidad
en el manejo de datos no estructurados y la alta disponibilidad, que las hacen ideales para
aplicaciones de gran escala, con múltiples usuarios y tipos de datos cambiantes. Sin embargo, tienen
desventajas en términos de inconsistencia, limitaciones en las consultas y una madurez relativa
comparada con las bases de datos relacionales. Los casos de uso de NoSQL son especialmente
adecuados para aplicaciones como redes sociales, caché, sistemas de comercio electrónico,
análisis en tiempo real, y motores de recomendación. La elección de la tecnología depende de la
naturaleza del problema a resolver y de los requisitos de consistencia, rendimiento y flexibilidad.

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 21/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

3.2 MongoDB

Introducción a MongoDB: MongoDB es una de las bases de datos NoSQL más

populares y ampliamente adoptadas en la industria. Es una base de datos de
documentos que almacena los datos en un formato similar a JSON llamado
BSON, lo que permite una gran flexibilidad en el modelado de datos. MongoDB
está diseñada para escalar horizontalmente, lo que la hace ideal para
aplicaciones que requieren manejar grandes volúmenes de datos distribuidos. Su
capacidad para manejar datos semiestructurados y su facilidad de uso la han convertido en una
elección popular para desarrolladores que necesitan una solución de almacenamiento ágil y escalable.
MongoDB se utiliza comúnmente en aplicaciones web, sistemas de gestión de contenido (CMS),
catálogos de productos y cualquier entorno donde los datos cambien con frecuencia y necesiten
representarse de forma jerárquica.

Videos de apoyo

[Link]

Redes Plus. Curso Completo de MogoDB. 21 abr 2020

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 22/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

3.2.1 Introducción a MongoDB:

MongoDB es un sistema de gestión de bases de datos NoSQL orientado a

documentos, diseñado para gestionar volúmenes masivos de datos sin las limitaciones
de los esquemas rígidos de las bases de datos relacionales. MongoDB se destaca por
su flexibilidad, escalabilidad horizontal y alta disponibilidad, convirtiéndolo en una
opción popular para aplicaciones modernas que necesitan trabajar con datos no estructurados o
semiestructurados.

Características principales de MongoDB

Modelo de Datos Flexible (Orientado a

Documentos)

MongoDB almacena datos en documentos BSON (Binary JSON),

un formato similar a JSON que permite almacenar información
compleja con una estructura flexible.
A diferencia de las bases de datos relacionales, no requiere un
esquema fijo. Los desarrolladores pueden agregar, eliminar o
modificar campos fácilmente, lo cual acelera el desarrollo de
aplicaciones.

Escalabilidad Horizontal

MongoDB ofrece sharding, una técnica de particionado horizontal

de la base de datos, para distribuir datos a través de múltiples
servidores. Esto permite el crecimiento prácticamente ilimitado al
añadir más nodos al clúster.
Cada shard contiene un subconjunto de los datos, y Mongos actúa
como el controlador para coordinar la distribución de las consultas y
los datos.

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 23/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

Replica Sets

MongoDB ofrece alta disponibilidad mediante el uso de replica

sets, donde cada conjunto tiene un nodo primario y múltiples nodos
secundarios.
El nodo primario maneja las operaciones de escritura, mientras que
los secundarios mantienen copias sincronizadas de los datos y
pueden tomar el rol del primario en caso de fallo, garantizando
tolerancia a fallos.

Consultas Potentes

MongoDB permite realizar consultas avanzadas con características

similares a las de las bases de datos SQL, como filtrado,
ordenación, agregación, y búsqueda de texto.
Además, tiene un marco de agregación robusto que permite
transformaciones y agregaciones de datos complejas sin necesidad
de escribir código adicional.

Índices

Al igual que en una base de datos relacional, MongoDB permite

definir índices para mejorar la eficiencia de las consultas.
Soporta índices compuestos, índices geoespaciales, índices de
texto, entre otros.

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 24/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

Alta Compatibilidad y Facilidad de

Integración

MongoDB está diseñado para trabajar fácilmente con una variedad

de lenguajes de programación como JavaScript, Python, Java,
C++, entre otros.
Además, MongoDB tiene un soporte robusto para API RESTful,
facilitando su uso en aplicaciones web.

Agregación y Pipeline de Datos

MongoDB posee un framework de agregación similar a las

operaciones de procesamiento por etapas en una tubería de datos
(pipeline), permitiendo manipular y transformar documentos con
facilidad.
Esta funcionalidad es muy útil para realizar análisis de datos sin
necesidad de escribir procesos complejos fuera de la base de
datos.

Arquitectura basada en documentos de MongoDB

MongoDB se diferencia de las bases de datos relacionales tradicionales por su enfoque orientado a
documentos. Esta arquitectura se basa en los siguientes conceptos:

Documentos BSON:

MongoDB almacena datos en documentos BSON, una extensión binaria del formato
JSON que facilita la representación de datos complejos y anidados. BSON es más
eficiente en términos de almacenamiento y velocidad de consulta, ya que permite una
representación directa en memoria.

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 25/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

Colecciones:

En MongoDB, los documentos se agrupan en colecciones, que funcionan de manera

similar a las tablas en las bases de datos relacionales.
Cada colección puede tener documentos con diferentes estructuras, lo que proporciona
una gran flexibilidad para manejar tipos de datos variados.

Modelo Jerárquico

Los documentos de MongoDB permiten estructuras anidadas, lo que significa que los
datos relacionados pueden almacenarse juntos en el mismo documento.
Esto permite que el modelo de datos sea autoexplicativo, lo que elimina la necesidad
de relaciones entre tablas como en un modelo relacional.

Sharding y Replicación:

La arquitectura de MongoDB permite dividir colecciones en múltiples shards para

mejorar la escalabilidad.
A su vez, la replicación asegura que la información sea segura y esté disponible,
incluso en caso de que uno o más nodos del sistema fallen.

Tipos de datos admitidos en MongoDB

MongoDB es muy versátil en cuanto a los tipos de datos que admite, gracias a su formato BSON.
Estos son algunos de los principales tipos de datos:

Cadenas de texto (String):

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 26/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

Uno de los tipos más comunes, utilizado para almacenar datos de texto. Las cadenas
son tratadas como UTF-8.

Números enteros (Integer):

MongoDB admite números enteros de 32 bits y enteros de 64 bits, dependiendo de

los requisitos de almacenamiento.

Números de punto flotante (Double):

Se utilizan para almacenar números que requieren decimales.

Booleanos (Boolean):

Representa los valores true o false.

Fechas (Date):

MongoDB puede almacenar información de fechas utilizando un objeto Date, que es

almacenado como milisegundos desde la época de Unix.

Arreglos (Array):

Los arreglos permiten almacenar múltiples valores en un solo campo, siendo uno de los
aspectos más flexibles del modelo de datos, ideal para representar relaciones de uno a
muchos dentro del mismo documento.

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 27/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

Documentos anidados (Object):

Los documentos pueden contener otros documentos, permitiendo anidar información

dentro de un documento más grande, facilitando la organización de datos jerárquicos.

Objeto ID (ObjectId):

Cada documento tiene un campo _id que contiene un identificador único para
diferenciar cada documento en la colección. Este identificador se crea automáticamente
cuando se inserta un documento y es esencial para las consultas.

Nulos (Null):

MongoDB admite valores null como un tipo de datos, lo que permite definir campos
vacíos explícitamente.

Datos binarios (Binary Data):

MongoDB puede almacenar datos binarios, como imágenes o archivos.

Coordenadas geoespaciales:

Soporta tipos de datos para almacenar coordenadas geoespaciales, lo que permite

ejecutar consultas geográficas y construir aplicaciones basadas en la ubicación.

Decimales (Decimal128):

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 28/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

Es útil para operaciones que requieren alta precisión, como cálculos financieros.

MongoDB es una base de datos NoSQL orientada a documentos, diseñada para manejar grandes
volúmenes de datos de manera flexible. Sus principales características incluyen escalabilidad
horizontal, replicación, y la capacidad de manejar datos no estructurados. MongoDB utiliza una
arquitectura basada en documentos donde la información se organiza en documentos BSON que
se almacenan en colecciones. Además, MongoDB admite una amplia variedad de tipos de datos,
como cadenas, números, fechas, arreglos, documentos anidados, y datos geoespaciales, entre
otros.

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 29/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

3.2.2 Modelado de Datos en MongoDB:

El modelado de datos en MongoDB se basa en la flexibilidad y capacidad para representar datos

no estructurados o semiestructurados. En lugar de trabajar con tablas y relaciones como en las bases
de datos relacionales, MongoDB utiliza documentos BSON dentro de colecciones, lo que
proporciona una estructura similar a los objetos JSON. Esta flexibilidad permite modelar de forma
natural estructuras complejas y relaciones jerárquicas.

Conceptos básicos del modelado de datos en MongoDB:

Documentos y Colecciones:

Un documento en MongoDB es una unidad de datos, equivalente a una fila en una

base de datos relacional, pero con una estructura JSON que puede ser jerárquica.
Las colecciones agrupan documentos, similares a las tablas en un esquema relacional,
aunque sin la necesidad de una estructura estricta y uniforme.

Embebido vs Referencias:

En MongoDB, los datos se pueden embeber (es decir, anidar documentos dentro de
otros documentos) o utilizar referencias para crear relaciones entre documentos,
similar a las llaves foráneas en bases de datos relacionales.
La elección entre embeber o referenciar depende del acceso a los datos y de la
frecuencia de las consultas.

Datos Denormalizados:

A diferencia del modelo relacional, donde se busca la normalización de datos,

MongoDB promueve la denormalización para evitar múltiples consultas y mejorar el

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 30/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

rendimiento.
Esto implica duplicar ciertos datos para evitar la necesidad de realizar múltiples uniones
complejas, logrando así una lectura rápida a costa de aumentar el espacio de
almacenamiento.

Buenas Prácticas para el Modelado de Datos en MongoDB

El modelado de datos en MongoDB se beneficia de una serie de buenas prácticas que garantizan la
eficiencia, escalabilidad y facilidad de mantenimiento:

Diseño Centrado en el Acceso a los Datos

El patrón de acceso es uno de los aspectos más importantes en

MongoDB. Se debe modelar pensando en cómo se van a consultar
y modificar los datos.
Por ejemplo, si se espera consultar información de un usuario y sus
comentarios en una sola operación, es conveniente embeber los
comentarios dentro del documento del usuario.

Uso de Documentos Embebidos para

Relaciones 1

Para relaciones de uno a uno (1:1) o uno a muchos (1) que

se consulten frecuentemente en conjunto, es mejor embeber
los datos. Esto reduce el número de consultas necesarias y
simplifica el acceso.

Ejemplo: Los detalles de contacto de un cliente pueden

estar embebidos dentro del documento del cliente.

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 31/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

Uso de Referencias para Relaciones N

Para relaciones de muchos a muchos (N) o cuando se

espera que los datos crezcan de forma considerable, es
preferible usar referencias. Esto es similar a crear una tabla
de unión en una base de datos relacional.

Ejemplo: Un documento de productos puede contener una

referencia a categorías que están almacenadas en otra
colección.

Evitar la Sobre desnormalización

Aunque la denormalización es común, no se debe exagerar. El

duplicado excesivo de datos puede dificultar las actualizaciones,
por lo que es importante buscar un balance entre duplicación y
accesibilidad.
Es recomendable evitar duplicar datos que se actualizan con
frecuencia.

Capacidad de Escalabilidad y Sharding

Cuando se modela, es importante considerar la futura

escalabilidad. MongoDB permite sharding (particionamiento
horizontal), por lo que el diseño de la colección debe permitir una
distribución adecuada de los datos entre múltiples nodos.
Un buen diseño de las claves shard es crucial para lograr una
distribución uniforme de los datos.

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 32/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

Uso del Patrón de Discriminación

Para colecciones con diferentes tipos de documentos, se puede

usar un campo discriminador para identificar el tipo de documento
dentro de la colección.
Ejemplo: Una colección de Vehículos podría tener un campo tipo
que indique si el documento es un Auto, Moto o Camión.

Optimizar las Consultas Usando Índices

Definir índices adecuados para los campos que se usan en

consultas frecuentes puede mejorar significativamente el
rendimiento.
MongoDB soporta índices compuestos y índices de texto que
permiten una búsqueda eficiente y escalable.

Predecir los Requerimientos de Crecimiento

del Documento

MongoDB tiene limitaciones en el tamaño de un documento

individual (máximo de 16 MB). Es importante considerar cómo
crecerán los datos embebidos y asegurarse de que no superen este
límite.
En algunos casos, es preferible fragmentar documentos grandes o
almacenar partes en colecciones separadas.

Diferencias con el Modelo Relacional

Las diferencias entre el modelado de datos en MongoDB y el modelado relacional están

profundamente relacionadas con la estructura y filosofía de cada base de datos:

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 33/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

Modelo de Estructura de Datos

MongoDB: Usa una estructura flexible de documentos BSON, lo

cual permite almacenar datos semiestructurados, anidados y
dinámicos. No se necesita un esquema predefinido.
Modelo Relacional: Utiliza un modelo tabular donde los datos se
estructuran en filas y columnas. La estructura se define mediante
esquemas rígidos, y las relaciones entre los datos se definen
explícitamente.

Normalización vs Denormalización

MongoDB: Tiende hacia la denormalización, lo cual implica

almacenar información relacionada en un mismo documento para
optimizar el rendimiento de consultas.
Modelo Relacional: Tiende a normalizar los datos para evitar la
duplicación y garantizar la integridad de la información, usando
relaciones entre tablas.

Relaciones entre Datos

MongoDB: Los datos se pueden embeber o referenciar.

MongoDB no soporta join de manera nativa como en SQL, aunque
proporciona ciertas capacidades de lookup para relacionar
documentos.
Modelo Relacional: Hace uso intensivo de joins entre tablas para
relacionar los datos, garantizando la coherencia mediante claves
foráneas.

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 34/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

Flexibilidad del Esquema

MongoDB: El esquema es dinámico, y se permite que diferentes

documentos dentro de la misma colección tengan campos
diferentes o adicionales. Esto proporciona flexibilidad en los
cambios de diseño.
Modelo Relacional: Los esquemas son rígidos, lo que requiere
modificaciones a la estructura de la base de datos cuando hay
cambios en la definición de los datos.

Escalabilidad

MongoDB: Está diseñado para la escalabilidad horizontal, lo que

facilita la distribución de los datos entre múltiples nodos mediante
sharding. Es ideal para aplicaciones con grandes volúmenes de
datos que requieren ser distribuidos.
Modelo Relacional: Aunque es posible la escalabilidad vertical,
generalmente no se escala horizontalmente de manera tan sencilla
como MongoDB, debido a las complejidades de mantener la
coherencia entre las tablas.

Consultas y Rendimiento

MongoDB: Las consultas son optimizadas para lecturas rápidas,

especialmente cuando los datos se encuentran en un mismo
documento embebido. MongoDB también ofrece una potente API
de agregación.
Modelo Relacional: Los joins y la normalización suelen ser
operaciones costosas en términos de rendimiento cuando se
trabaja con grandes volúmenes de datos distribuidos.

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 35/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

Transacciones

MongoDB: Originalmente, MongoDB no soportaba transacciones

ACID multi-documento. Sin embargo, desde la versión 4.0,
MongoDB incluye soporte para transacciones que abarcan
múltiples documentos.
Modelo Relacional: Las transacciones ACID son parte esencial
del modelo, lo que garantiza la integridad y coherencia de los datos
en todas las operaciones.

El modelado de datos en MongoDB se centra en la flexibilidad, el acceso eficiente y la

simplicidad del diseño para adaptarse a los patrones de uso de las aplicaciones modernas. Las
buenas prácticas para el modelado de datos en MongoDB incluyen elegir entre documentos
embebidos y referencias dependiendo del uso, aplicar la denormalización cuando sea necesario para
mejorar la eficiencia, y asegurarse de optimizar el rendimiento mediante índices.

Las diferencias con el modelo relacional resaltan cómo MongoDB favorece la escalabilidad, la
flexibilidad del esquema, y el enfoque denormalizado para las relaciones de datos, mientras que los
modelos relacionales se enfocan en la integridad y coherencia mediante esquemas rígidos y el uso
de transacciones.
Videos de apoyo

[Link]

HolaMundo. como se modelan las bases de datos no relacionales. 19 mar 2021

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 36/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

3.2.3 Operaciones CRUD

El término CRUD se refiere a las cuatro operaciones fundamentales que

se pueden realizar sobre cualquier sistema de almacenamiento de
datos: Creación (Create), Lectura (Read), Actualización (Update) y
Eliminación (Delete). En MongoDB, estas operaciones se realizan
sobre colecciones y documentos que se organizan en un formato
flexible de BSON (similar a JSON).

A continuación, se explican cada una de estas operaciones y cómo se implementan con comandos
básicos en MongoDB.

Creación (Create)

La creación en MongoDB implica insertar nuevos documentos en una

colección. Los documentos se representan como objetos BSON, lo cual
permite almacenar datos estructurados y anidados.

Comando Básico: insertOne() y insertMany()

[Link](document): Se usa para insertar un
solo documento en una colección.

Este comando inserta un documento con datos del usuario Carlos en la

colección usuarios.

[Link]([document1, document2, ...]): Se

usa para insertar varios documentos de una sola vez.

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 37/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

Este comando inserta múltiples documentos en la colección usuarios.

Lectura (Read)

La lectura implica consultar y recuperar datos almacenados en una base

de datos. En MongoDB, se utilizan diversos métodos para buscar
documentos en una colección.

Comando Básico: find(), findOne()

[Link](query, projection): Devuelve todos los
documentos que coinciden con la consulta (query). También
se puede especificar una proyección para limitar los campos
que se devuelven.

Este comando devuelve todos los usuarios cuya edad sea mayor a 30.

[Link](query): Devuelve el primer

documento que coincide con la consulta.

Este comando devuelve el primer documento donde el campo nombre es

igual a "Carlos".

Uso de Proyección:

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 38/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

Este comando devuelve los nombres de los usuarios mayores de 30

años, omitiendo el campo _id.

Actualización (Update)

La actualización permite modificar uno o más documentos ya existentes.

MongoDB proporciona varios métodos para actualizar documentos, ya
sea de manera parcial o total.

Comandos Básicos: updateOne(), updateMany(), replaceOne()

[Link](filter, update, options): Actualiza
un solo documento que cumpla con el filtro.

Este comando encuentra el primer documento donde el nombre sea

"Carlos" y actualiza su edad a 36.

[Link](filter, update, options):

Actualiza todos los documentos que coincidan con el filtro.

Este comando añade el campo ciudad con el valor "San Salvador" a

todos los usuarios cuya ocupación sea "Consultor".

[Link](filter, replacement): Reemplaza

completamente un documento que coincida con el filtro.

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 39/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

Este comando reemplaza completamente el documento de Pedro con

una nueva versión del documento.

Operadores de Actualización Comunes:

$set: Se usa para establecer un valor a un campo.
$inc: Incrementa el valor de un campo numérico.

Incrementa la edad de Ana en 1.

Eliminación (Delete)

La eliminación de documentos permite remover uno o más documentos

de una colección. MongoDB proporciona métodos para eliminar
documentos basados en criterios específicos.

Comandos Básicos: deleteOne(), deleteMany()

[Link](filter): Elimina el primer documento
que cumpla con el filtro.

Este comando elimina el primer documento donde el nombre sea

"Pedro".

[Link](filter): Elimina todos los

documentos que cumplan con el filtro.

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 40/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

Este comando elimina todos los usuarios cuya ocupación sea "Consultor".

Resumen de Operaciones CRUD en MongoDB

Operación Método Descripción Ejemplo

Crear insertOne(), insertMany() Insertar uno o varios documentos [Link]({nombr

en una colección.

Leer find(), findOne() Consultar documentos con [Link]({edad: {$gt: 3

condiciones opcionales.

Actualizar updateOne(), updateMany(), Modificar uno o más documentos [Link]({nomb

replaceOne() según un criterio. {$set: {edad: 36}})

Eliminar deleteOne(), deleteMany() Remover uno o más documentos [Link]({ocup

según un criterio. "Consultor"})

Conclusiones

Las operaciones CRUD en MongoDB son la base fundamental para la gestión de colecciones y documentos en
una base de datos. Mediante los métodos insertOne(), find(), updateOne() y deleteOne(), se pueden manipular
los datos de forma eficiente y flexible.

MongoDB proporciona una API sencilla y poderosa para realizar todas estas operaciones, lo que facilita el
desarrollo de aplicaciones que requieren almacenar y manejar grandes cantidades de datos. La posibilidad de
utilizar documentos embebidos y referencias brinda una flexibilidad que se ajusta a los patrones de acceso y
escalabilidad que requiere cada aplicación.
Videos de apoyo

[Link]

MitoCode MongoDB CRUD 7 abr 2021

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 41/42
13/11/24, 11:05 UD3 Bases de Datos NoSQL S1

Licencia: licencia propietaria intelectual

localhost:51235/temp_print_dirs/eXeTempPrintDir_4fcprs/UD3_Bases_de_Datos_NoSQL_S1/ 42/42