Arquitectura MongoDB: estructura, terminologías, requisitos y beneficios
Publicado: 2020-12-28Tabla de contenido
Visión de conjunto
No hay duda de que Internet es la columna vertebral de la economía mundial moderna. Hoy en día, casi 4700 millones de personas en el mundo usan la plataforma virtual todos los días, utilizando aplicaciones impulsadas por Internet para noticias, comprar ropa, pedir comida, escuchar música, ir y venir de la oficina y más.
Con una cantidad tan grande de usuarios que hacen contribuciones digitales todos los días, no es de extrañar que cada día se generen enormes cantidades de datos no estructurados en el ciberespacio. Obtenga más información sobre el alcance futuro de MongoDB.
Esto dio lugar a una necesidad urgente de un nuevo paradigma de base de datos que pueda almacenar, servir y admitir aplicaciones de 'Big Data' (como se las conoció) las 24 horas del día, los 7 días de la semana, sin descomponerse.
Introduzca NoSQL.
El auge de las bases de datos NoSQL
NoSQL, conocido vagamente como "No solo SQL", es una alternativa a las bases de datos SQL limitadas por sus esquemas de tablas fijas. Al ser altamente flexible, NoSQL supera este inconveniente estructural de las bases de datos SQL y está equipado para escalar horizontalmente. Las bases de datos NoSQL se diseñaron para aumentar la productividad de los desarrolladores, equipándolos con un modelo de datos simple y elegante para operaciones complejas de procesamiento y administración de datos.
En términos generales, estos modelos de almacenamiento de datos vienen en 4 tipos: documento, valor clave, columna ancha y gráfico. Nos centraremos en las bases de datos de documentos y la arquitectura MongoDB en este blog (la principal base de datos NoSQL)

La estructura MongoDB
Fuente: documentación de MongoDB
La arquitectura MongoDB sigue un modelo de datos flexible. A diferencia de RDBMS, que exige una declaración de esquema antes de insertar datos, MongoDB no impone una estructura de documento fija.
Terminologías
Campos
Un par clave-valor en un documento, es la contraparte de una columna en bases de datos relacionales
Documento
Este es el equivalente de un registro en RDBMS
Colecciones
Un grupo de documentos se denomina colección. Esto es análogo a una tabla RDBMS
Diferencias entre la arquitectura RDBMS y MongoDB
Uniones
En RDBMS, los datos pueden distribuirse entre varias tablas y unirse para acceder a ellos en una sola vista. Tal operación JOIN no es posible en MongoDB. En cambio, todos los datos se almacenan en una sola colección, pero se pueden separar mediante anidamiento o documentos incrustados.
Normalización
RDBMS garantiza la normalización de datos para evitar duplicados y registros huérfanos. La flexibilidad de MongoDB elimina la necesidad de normalización
Estructura
RDBS se usa principalmente en el sector bancario, donde la estructura exacta de la base de datos se conoce a priori. MongoDB admite grandes volúmenes de datos no estructurados y es extensible a aplicaciones en la nube, móviles, web y Big Data.
La necesidad y los beneficios de la arquitectura MongoDB
La arquitectura MongoDB puede manejar cambios estructurales sobre la marcha, que es la necesidad del momento. Esto es perfecto para escenarios en los que no tiene visibilidad de la estructura de su base de datos de antemano.
Los siguientes son algunos de sus beneficios clave.
Basado en documentos
Puede adaptarse a los cambios de flujo de datos de forma dinámica, adaptándose a los cambiantes requisitos comerciales en tiempo real

Consultas ad hoc : lenguaje de consulta potente que puede devolver campos específicos. También permite capacidades de búsqueda altamente granulares. (en términos de campo, rango, expresiones comunes y más)
Indexación
Puede indexar cualquier campo en un documento para acelerar el proceso de recuperación de datos.
Profundicemos ahora en la arquitectura de MongoDB .
Pero antes de hacer eso, necesitamos entender el Teorema CAP.
El teorema de la PAC
CAP denota la trifecta de consistencia, disponibilidad y tolerancia de partición.
Veamos lo que significa cada término en este contexto
Consistencia
Si escribe datos en una base de datos distribuida, debería poder acceder a los mismos datos desde cualquier nodo del sistema en cualquier momento. Se trata de preservar la integridad de los datos escritos.
Disponibilidad
Se trata de minimizar el tiempo de inactividad de un sistema. Las operaciones de lectura/escritura deben ocurrir en cualquier máquina del clúster, sin falta.
Tolerancia de partición o tolerancia a fallas
indica la capacidad de un sistema para seguir funcionando sin problemas, incluso en el caso de una partición de red, es decir, las diferentes partes del clúster deberían poder comunicarse entre sí y sincronizarse de manera eficaz.
El teorema CAP establece que un sistema distribuido TIENE que ser tolerante a la partición. Las particiones de red no pueden hacer que todo el sistema se derrumbe.
En otras palabras, solo puede garantizar un parámetro de 'Coherencia' y 'Disponibilidad' en un sistema distribuido, siendo el otro Tolerancia de partición.
Esto da lugar a un triángulo como este:
Fuente: Data Science Pedia
MongoDB siempre elige la consistencia sobre la disponibilidad siempre que haya una partición en el sistema (CP). Bloquea todas las operaciones de escritura hasta que pueda garantizar la ejecución precisa de esas escrituras.
Arquitectura MongoDB
MongoDB emplea la arquitectura de maestro único, lo que significa que hay una máquina principal que se encarga de todas las operaciones de escritura del lado del cliente. Todas las demás instancias que agregue más tarde al clúster constituyen los nodos secundarios, que comúnmente manejan todas las operaciones de lectura.
Básicamente, se trata de copias de seguridad del servidor principal como una medida de seguridad contra el bloqueo principal.
Todos estos servidores están agrupados en conjuntos de réplicas. Puede tener varios conjuntos de réplicas, cada uno con sus propios servidores principal y secundario.
Fuente: Documentación de MongoDB
En caso de que el primario se caiga, el sistema elige un nuevo primario de todos los nodos secundarios. Pero esto sucede de manera arbitraria, dependiendo de dónde obtenga las respuestas de ping más rápidas de todos los sistemas. Debe tener un número impar de servidores en su clúster (mínimo 3) para que se pueda elegir una primaria con una mayoría.
Si no quiere gastar dinero en tres servidores, puede designar un nodo 'Árbitro' cuyo único trabajo es votar para elegir el principal.
fragmentación
La fragmentación en MongoDB le permite distribuir su Big Data en varias bases de datos.

Fuente: Documentación de MongoDB
Tienes una aplicación que tiene millones de usuarios. La fragmentación le permite particionar estos usuarios (en función de un índice único como una ID de usuario) en diferentes conjuntos de réplicas. Usando un proceso llamado mongoS, el servidor de aplicaciones se comunica con los servidores de configuración (precisamente 3) para comprender qué 'fragmento' contiene los datos que está buscando. mongoS ejecuta un proceso Load Balancer en segundo plano para distribuir automáticamente la carga (en este caso, la cantidad de usuarios) de manera uniforme entre todos los fragmentos.
Conclusión
Si desea obtener más información sobre MongoDB y las operaciones de la base de datos, consulte las ideas de proyectos de MongoDB. Puede explorar el Diploma PG en ciencia de datos de upGrad. Un curso de 12 meses diseñado para profesionales que trabajan, obtiene asesoramiento profesional integral y oportunidades laborales, junto con el prestigioso estado de ex alumnos de IIIT Bangalore.
Esperamos que este artículo le haya ayudado a comprender cómo funciona la arquitectura MongoDB y cómo funciona el sistema. Para saber más, por favor mira nuestros otros blogs.
Aprenda cursos de desarrollo de software en línea de las mejores universidades del mundo. Obtenga Programas PG Ejecutivos, Programas de Certificado Avanzado o Programas de Maestría para acelerar su carrera.
