See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/323184317

MongoDB: alternativas de implementar y consultar documentos

Conference Paper · October 2017

CITATIONS READS

3 5,211

4 authors:

Kenneth Calvo Johan stiff Duran

University of Costa Rica University of Costa Rica
1 PUBLICATION 3 CITATIONS 1 PUBLICATION 3 CITATIONS

SEE PROFILE SEE PROFILE

Esteban Quirós Elzbieta Malinowski

University of Costa Rica University of Costa Rica
1 PUBLICATION 3 CITATIONS 53 PUBLICATIONS 991 CITATIONS

SEE PROFILE SEE PROFILE

All content following this page was uploaded by Elzbieta Malinowski on 27 May 2018.

The user has requested enhancement of the downloaded file.

 MongoDB: alternativas de implementar y consultar documentos
Kenneth Calvo, Johan Durán, Esteban Quirós, Elzbieta Malinowski.
[email protected], [email protected], [email protected], [email protected]
Facultad de Ciencias de la Computación e Informática
Universidad de Costa Rica, Costa Rica
2060 San José.
San José - Costa Rica

Resumen: En un mundo digital, donde la cantidad de datos complejos y no estructurados crece diariamente, surge la
necesidad de contar con bases de datos capaces de manejarlos. En respuesta a dicha necesidad emergen los sistemas
conocidos como NoSQL, dentro de las cuáles se encuentra MongoDB – un sistema de manejo de documentos. La
popularización de MongoDB lleva a investigadores a comparar su eficiencia y rendimiento con respecto a diferentes
sistemas relacionales. Sin embargo, existen otros aspectos importantes de examinar dentro del mismo sistema
MongoDB cuando se crea su estructura y ejecuta las consultas. El presente trabajo introduce un caso de estudio
referente a películas y sus valoraciones mostrando diferentes opciones de su implementación y consultas. Se compara
el desempeño de consultas considerando diferentes opciones, por ejemplo, la utilización del atributo de enlace entre
documentos (similar a llave foránea en bases de datos relacionales), manejo de documentos anidados e inclusión de
índices.
Abstract: In a digital world, where the volume of complex and unstructured data grows each day, there is a need for
systems capable of handling them. In response to this need, systems as NoSQL arise; an example is MongoDB - a
document management system. The popularization of MongoDB leads researchers to compare its efficiency and
performance with respect to different relational systems. Nevertheless, there are other important aspects to examine
within MongoDB itself, such as its capabilities to create different structures and queries. The present work introduces a
case study related to movies and their scores showing different options of implementation and queries. The query
performance is compared regarding different options, for example, nested documents, referenced documents (similar to
foreign keys in relational databases) and indexes. In addition, some recommendations in using the aggregation
pipelines are given.
Palabras claves: MongoDB, lookup, índice, anidado.

1 Introducción formato BSON (Binary JSON). La creación de la base de

datos no requiere de previa definición de su esquema
Gran parte de los datos producidos por redes sociales, IoT contrario a bases relacionales. Esta característica permite
(Internet of Things, Internet de las Cosas), sensores, a los desarrolladores crear un sistema más flexible a
transacciones, entre otros, crece diariamente de manera futuras modificaciones de la estructura de documentos en
significativa. Los sistemas relacionales usados comparación con bases de datos relacionales [5].
comúnmente para almacenar y manipular dichos datos
empezaron a demostrar limitaciones; esto motivó a MongoDB es uno de los sistemas de bases de datos
empresas, como Google, Facebook, Amazon y otras NoSQL más conocidos y debido a esto en muchas
entidades, a la búsqueda de nuevas tecnologías para ocasiones es contrastado con sistemas relacionales [6], [7]
atender aplicaciones particulares de los usuarios en y no relacionales [8], [9]. Sin embargo, MongoDB por si
muchos casos relacionados con Big Data. Se condujeron solo ofrece diferentes opciones de implementación, como,
numerosas investigaciones que dieron como resultado por ejemplo, la posibilidad de definir documentos
nuevos sistemas, los que actualmente se conocen como anidados o referenciados, el uso del operador lookup para
bases de datos NoSQL. contrarrestar la necesidad de realizar la operación join
entre documentos, la aplicación de índice para diferentes
La palabra NoSQL se refiere a bases de datos que no usan tipos de consultas, para mencionar solo algunas
SQL como lenguaje de manipulación y en otras alternativas. Esta variedad de opciones puede favorecer a
ocasiones, se refiere a Not only SQL (no solo SQL) e los desarrolladores si se les ofrece una comparación de
indica que se usa SQL y también existe expansión hacia desempeño de consultas entre diferentes posibilidades de
otros lenguajes. La idea atrás de este tipo de software es implementación. Desafortunadamente, durante esta
proveer nuevas formas de almacenamiento y consultas de investigación no se ha encontrado evidencias de este tipo
datos, más allá de columnas y filas como se almacenan en de comparaciones. Debido a esta situación, el presente
bases de datos relacionales. Algunos ejemplos de estas trabajo se refiere a un caso de estudio que incluye las
bases de datos son: Hbase [1] y Cassandra [2] de Apache, películas y sus valoraciones para ejemplificar diferentes
Neo4j [3] de Neo Technology, Inc. y MongoDB [4] de formas de creación de documentos y expresión de
MongoDB, Inc. consultas con el objetivo de comparar su desempeño.
MongoDB es un software que permite a los usuarios crear Este artículo está organizado de la siguiente manera. En la
y manipular bases de datos presentados en forma de así sección 2, se presentan los trabajos relacionados con el
llamados documentos, los cuales son almacenados en un tema, mientras que la sección 3 describe la estructura de
MongoDB y sus operaciones. La sección 4 presenta el “ObjectId”, valor del cual se puede ver en la línea 2 de la
caso de estudio y algunos ejemplos de consultas. En la Figura 1.
sección 5, se presentan e interpretan los resultados de
Las llaves en la definición del documento se refieren a la
desempeño de las consultas en los diferentes casos de
estructura del documento y tienen asociados valores que
prueba. Por último, en la sección 6, se presentan las
pueden ser de diferentes tipos, por ejemplo, hileras,
conclusiones de este artículo.
números, fechas, valores booleanos o arreglos, entre
2 Trabajos Relacionados otros. El valor también puede ser el identificador del otro
objeto (documento), jugando el rol de llave foránea usada
Existen varios trabajos que realizan una comparación de en bases de datos relacionales, u otro documento, creando
las operaciones CRUD (create, read, update y delete, la estructura de documentos anidados [17].
crear, leer, modificar y borrar) y de otras funcionalidades
básicas de diferentes sistemas de bases de datos Los documentos son almacenados en una colección que es
relacionales como MySQL [6], Oracle [7] o SQL Server similar a una tabla en bases de datos relacionales. Los
[10] con sus equivalentes en MongoDB. Con respecto a documentos que forman la colección no tienen que tener
MongoDB se destaca la facilidad de uso, simplicidad y el mismo conjunto de llaves, es decir, pueden tener
esquema definido con las instancias como factores que estructuras diferentes. De esta forma los diseñadores de
podrían promover el uso de MongoDB con respecto a las bases de datos en MongoDB tienen la flexibilidad para
bases de datos relacionales anteriormente mencionadas. crear en forma dinámica estructuras más adecuadas para
la aplicación [17].
Además, existen trabajos que comparan MongoDB con
otras bases de datos NoSQL [8], [9], [11]. Esta 3.2 Operaciones en MongoDB
comparación permite entender características de MongoDB ofrece un conjunto de operaciones que permite
diferentes modelos de datos usados en bases de datos al usuario realizar múltiples transformaciones y consultas
NoSQL y presentar opciones de selección de modelo sobre los documentos. Además, otras facilidades de
adecuado de acuerdo a los diferentes casos de estudio. manipulación de documentos se refieren a “agregación”
Otros trabajos se refieren a diferentes aspectos del propio de documentos por medio de la tubería de agregación
MongoDB, por ejemplo, patrones de diseño [12], (aggregation pipeline) y el mapeo-reducción (map-
modelado y consultas [13], [14], mejoramientos del reduce).
algoritmo de auto sharding [15], estructura de La tubería de agregación es un marco de referencia que
documentos anidados [16], entre otros. permite a un documento de entrada pasar por una serie de
3 Estructura y manejo de datos en etapas para generar una colección o retornar un cursor. Un
cursor es un puntero al conjunto de resultados de la
MongoDB consulta [18]. Las etapas indican distintas operaciones
MongoDB es una base de datos orientada a documentos ejecutadas por MongoDB, por ejemplo:
agrupados en colecciones y permite expresar las consultas  match: Seleccionar los documentos que cumplen
en diferentes lenguajes, por ejemplo, PHP, Node.js, con un criterio de búsqueda.
Python, Ruby o Java.  project: Transformar la estructura del documento
3.1 Estructura de MongoDB intermedio seleccionando, modificando o
eliminando campos existentes.
Los documentos en MongoDB corresponden a registros  lookup: Ejecutar un left outer join.
en bases de datos relacionales con la diferencia que cada  unwind: Separar y crear un nuevo documento
documento incluye la descripción de la estructura e para cada entrada del arreglo existente en el
instancias por medio de un conjunto de pares llave-valor, documento.
como se puede ver en la Figura 1. Llave corresponde al  group: Agrupar los documentos por un campo
nombre del atributo y valor a instancia en el modelo llave.
relacional.  out: Especificar punto de almacenamiento de los
resultados.
A pesar de que la tubería de agregación permite realizar
distintas operaciones sobre un mismo documento de
entrada, existen limitaciones asociadas. En primera
instancia, el documento resultado debe ajustarse a las
normas BSON, las cuales indican que un documento no
puede superar los 16MB. Además, MongoDB permite un
alojamiento máximo de 100MB de memoria para la
Figura 1: Ejemplo de un documento en MongoDB consulta en tiempo de ejecución; por lo tanto, en caso de
excederse alguna de estas restricciones el sistema
Cada documento tiene un identificador “_id” que lo responde con error.
distinga de los demás documentos. Este identificador
puede ser suministrado por el programador y puede ser de Otra forma de transformaciones tipo agregación que se
cualquier tipo. Si el usuario no lo provee, MongoDB lo puede aplicar a los documentos en MongoDB es el
asigna en forma automática como un campo tipo mapeo-reducción. Esta funciona bajo la metodología de
asociación llave-valor y para su funcionamiento necesita
(como mínimo) tres elementos:
 Función de mapeo: Emite un arreglo de valores
asociado a una misma llave.
 Función de reducción: Recibe como parámetro la
llave y un arreglo de valores asociado y retorna
un único valor asociado a dicha llave.
 Salida de datos: Retorna el resultado usando una
de las dos opciones: guardando los resultados en
una colección o devolviendo el documento.
MongoDB permite mejorar el rendimiento de las
consultas por medio del uso de índices. Sin definir un
índice, se tendría que hacer una búsqueda exhaustiva por
toda la colección para encontrar los datos que cumplen la
condición dada. Por defecto MongoDB indexa sobre el Figura 3: Representación conceptual de documentos
campo “_id”; sin embargo, se pueden definir índices anidados de películas y sus valoraciones.
sobre otras llaves para mejorar el desempeño de las
consultas más frecuentes [19]. El documento de películas representado conceptualmente
en la
4 Caso de estudio Figura 2 se implementa en MongoDB usando el código
Los datos usados en el proyecto, disponibles en el presente en la Figura 1. Por otro lado, la Figura 4 muestra
conjunto de datos MovieLens 10M DataSet1 se refieren a el código en MongoDB para definir un documento de la
las películas (movies) y su valoración (rating). Una colección de valoraciones correspondiente a cada
valoración es el puntaje asignado por un usuario a una película.
determinada película. Dicha valoración pertenece a la
escala de uno a diez donde uno es la puntuación más baja
y diez la más alta. Cada película puede tener múltiples
valoraciones. Se cuentan con diez mil películas y diez
millones de valoraciones.
4.1 Modelaje de datos
Considerando los datos disponibles, se desarrollaron dos
esquemas usando la representación conceptual propuesta
por [14]. El primer esquema, mostrado en la Figura 4: Documento de valoraciones en MongoDB.

Figura 2 se refiere a documentos de películas y Por último, para representar un documento anidado en
valoraciones incluyendo la relación existente entre MongoDB, como el mostrado a nivel conceptual en la
ambos. Por otro lado, se puede apreciar en la Figura 3 Figura 3, solo se necesita una colección. En la Figura 5 se
que en lugar de crear un documento separado para las presenta un ejemplo de la definición de documentos
valoraciones, se propone la inclusión de un arreglo de anidados. Este, además de atributos del identificador de
documentos de valoraciones dentro del documento de MongoDB, del identificador de la película, título y
películas, formando una estructura de documentos géneros, contiene valoraciones (líneas 6-14) como un
anidados. arreglo de documentos (con el identificador del usuario,
valoración y estampilla de tiempo).

Figura 2: Representación conceptual de documentos de

películas y valoraciones.

1
https://grouplens.org/datasets/movielens/
 Figura 5: Documento película con documentos de de aprovechar mejor el almacenamiento. La opción de
valoraciones anidados en MongoDB. allowDiskUse (línea 8) es necesaria porque al ejecutarse
la agrupación se sobrepasan los 100MB permitidos por
4.2 Consultas en MongoDB MongoDB por lo tanto es necesario autorizar la creación
A la base de datos desarrollada se le pueden aplicar varias de archivos temporales para que se pueda llevar a cabo la
consultas analíticas. En el caso de esta investigación se operación. Parte de los resultados de la consulta se pueden
optó utilizar Javascript, aunque no existen restricciones de ver en la Figura 9, donde se muestras los identificadores
usar otros lenguajes. de las películas con la valoración de 0.5.

Si se desea facilitar la búsqueda de películas por medio de

géneros sería conveniente almacenar los nombres de
géneros en un arreglo en lugar de una sola hilera como se
encuentra actualmente. La primera consulta, mostrada en
la Figura 6, toma el campo de géneros, originalmente en
forma de una sola hilera, y lo transforma a un arreglo con
los diferentes valores presentados por separado. Como se
desea que la consulta se ejecute para todos los
documentos es necesario usar la función forEach (linea
Figura 8: Consulta de agrupación de películas por puntaje.
1). Para separar la hilera original en múltiples valores se
utiliza la función split de Javascript, como se observa en
la línea 3. Estos valores luego son almacenados en un
arreglo. Por último, se ejecuta un update para cambiar la
hilera por el arreglo generado (líneas 4-7). Un ejemplo de
los resultados obtenidos de esta consulta se puede
observar en la Figura 7.

Figura 9: Resultados de consulta de agrupación por

puntaje.
La siguiente consulta pertenece al paradigma de
Figura 6: Consulta de separación de géneros. procesamiento de datos mapeo-reducción (map-reduce) y
permite obtener la valoración promedio que recibió cada
película. Como se explicó en la sección 3.2 este
paradigma requiere tres elementos: la función de mapeo,
la de reducción y la salida de datos. Como se puede
observar en la Figura 10, inicialmente se emite el par de
llave-valor (líneas 3-6), donde llave es el identificador de
la película (movieId) y el valor es la valoración obtenida.
Por lo tanto, la función de reducción recibe para cada
identificador de película, un arreglo con todas las
valoraciones asociadas y retorna promedio de estas
valoraciones (líneas 9-12). Los resultados se guardan en
la colección con nombre PromedioPelicula. En la Figura
11 se presenta uno ejemplo del resultado de la consulta de
cálculo de promedio de valoraciones.
Figura 7: Resultados de consulta de separación de
géneros.
Otro ejemplo de consultas en MongoDB se refiere a la
tubería de agregación simple y se muestra en la Figura 8.
Este ejemplo agrupa las películas (sus identificadores) en
base con las valoraciones que cada una recibió, es decir,
en base con rating (línea 3) como se puede ver en la
figura. Como el documento resultante debe guardar los
identificadores de las películas, se crea un nuevo campo
Movies (líneas 4-7). El operador push permite la inserción
de un valor del identificador en el arreglo de películas
(línea 5). Además, se utiliza substr para transformar el
identificador de la película en una hilera con el propósito
Figura 10: Consulta del promedio de puntaje por película. observar en la primera y segunda columna de la Tabla 1.
Aunque se cuenta con la colección de alrededor de 7.500
películas, se tomó la decisión de utilizar hasta 5.000
películas debido a muy altos tiempos de ejecución en
consultas sin índice.
Tabla 1: Tiempos de ejecución de lookup con índice y sin
índice en segundos.
Películas Valoraciones Con Índice Sin Índice
1.000 3.081.755 9,0 3302,0
2.000 5.255.829 17,0 6542,0
Figura 11: Resultados de consulta del promedio de
3.000 6.856.385 22,0 9866,0
puntaje por película. 4.000 7.841.885 25,0 13189,0
5.000 8.461.625 27,0 16599,0
5 Desempeño de Consultas
Las pruebas miden el tiempo de ejecución de la operación
MongoDB permite varias maneras de estructurar los
lookup sobre la colección de películas con la de
datos. Esta estructuración puede tener un efecto en el
valoraciones usando el atributo común que existe entre
tiempo de ejecución y en la eficiencia de las diferentes
ambas (movieId), como se puede ver en la Figura 13. Esta
consultas. Para ejemplificar los cambios de desempeño de
operación permite generar una especie de join de las
consultas dependiendo de diferentes estructuras usadas, se
películas con sus valoraciones respectivas (líneas 3-7).
realizaron pruebas en una computadora de desarrollo que
Las pruebas se realizan con la ausencia y presencia del
cuenta con un procesador Intel i7 de dos núcleos y 16GB
índice sobre el campo de movieId en la colección de
de RAM.
documentos de valoraciones. En la Tabla 1 se pueden
5.1 Impacto de índice en el operador observar los resultados de las pruebas expresados en
lookup segundos, mientras que la Figura 14 muestra estos
resultados en forma gráfica. Esta última presentación
Los índices pueden tener un efecto positivo en la rapidez permite observar una clara y consistente diferencia entre
con la que se ejecuta una consulta. Por dicha razón, se los tiempos de ejecución de la consulta con y sin índice,
analizará la diferencia de tiempo de ejecución del en favor de la utilización del índice.
operador lookup cuando se utiliza el índice o en su
ausencia en el campo foreign field.
La operación lookup es parte de las funciones de
agregación de MongoDB. Esta operación simula un left
outer join entre dos colecciones de documentos, como se
puede ver el código en forma genérica en la Figura 12; se
realiza la operación entre la colección 1 invocada en la
función (línea 1) y la colección 2 presente en el campo
from (línea 3) sobre los campos indicados en localField Figura 13: Consulta de lookup sobre moviId.
(línea 4) y foreignField (línea 5). El resultado es un
documento conformado por un arreglo que contiene los
datos de los documentos relacionados [20]. Al documento
resultante se puede asignar el nombre por medio en la
cláusula as (linea 6 en la figura).

Figura 12: Consulta básica lookup.

Para realizar las pruebas, se utiliza una base de datos con
documentos y valoraciones relacionados como se pusdo
ver en la Figura 2. Se considera creciente número de Figura 14: Gráfica de tiempos de ejecución de lookup con
documentos de películas desde 1.000 hasta 5.000 con el y sin índice (escala logarítmica).
intervalo de 1.000. Además, para cada diferente intervalo
Con estos resultados son notorios dos hechos particulares.
de documentos de películas, se incluye valoraciones en
El primero es que ambos tiempos de ejecución, sin índice
siguientes cantidades 3.081.755, 5.255.829, 6.856.385,
y con índice en el campo movieId de la colección
7.841.885 y 8.461.625, respectivamente, como se puede
valoraciones, crecen de manera casi lineal. El segundo es
que la diferencia entre los tiempos de ejecución con y sin Cabe rescatar que existe un factor a considerar para el
índices es notable, llegando a casi trescientas veces más caso de documentos anidados, el cual es bien conocido en
para la consulta sin índice. base de datos como el “trade-off” entre velocidad de
ejecución y espacio en disco. Esto debido a que al tener
5.2 Lookup con índice vs documentos documentos anidados puede darse el caso en donde se
anidados dupliquen documentos o datos dentro de ellos. Estos
factores se deben plantear a la hora de hacer el diseño de
El uso del operador lookup y de índice sobre lo que
la base de datos y tomar una decisión dependiendo de las
corresponde a llave foránea en bases de datos relacionales
características de la aplicación.
(atributo movieID), demostró un mejor rendimiento de las
consultas como se pudo ver en la sección 5.1. Además de
ofrecer este operador, MongoDB también provee otras
posibilidades de representar y manipular documentos; una
de ellas es el uso de documentos anidados.
En el siguiente caso de estudio se utiliza las colecciones
de películas y valoraciones como se presentó en la Figura
3 de la sección 4.1 para determinar si el rendimiento en
consultas sobre documentos anidados es superior o
inferior que el brindado por el operador lookup con
índice.
Como se puede apreciar en la Tabla 2, se considera 1.000,
2.500, 4.000, 5.500 y 7.000 películas y 3.081.755,
6.081.110, 7.841.885, 8.682.809 y 9.177.819
valoraciones, respectivamente. En este caso se decidió
hacer el corte en 7.000 documentos de películas debido a
que los tiempos de ejecución con índice y documentos
anidados son más bajos que en caso presentado en la Figura 16: Gráfica de tiempos de ejecución documentos
sección 5.1. anidados y operador lookup.
Tabla 2: Tiempos de ejecución de documentos anidados y 5.3 Problemas asociados a la unión de más
operador lookup.
de dos colecciones
Películas Valoraciones Lookup Documentos
indexado anidados En MongoDB la estructura de los documentos y de las
1.000 3.081.755 9,0 1,1 colecciones debe estar intrínsecamente relacionada con
2.500 6.081.110 20.0 2,4 las consultas que se esperan realizar [21]. Una mala
4.000 7.841.885 25,0 2,8 estructuración puede incrementar tiempos de ejecución de
5.500 8.682.809 29,0 3,0 las consultas. Por dicha razón, en esta sección se presenta
7.000 9.177.819 32,0 3,2 un caso en el cual no existe una estructura acorde a la
consulta.
Para las pruebas con el operador lookup, se implementó la
consulta presentada en la Figura 13 realizada en la Para las pruebas realizadas se amplió el esquema
sección 5.1. La Figura 15 presenta el código de la propuesta en la Figura 2 y se agregó una tercera colección
consulta sobre documentos anidados. Esta consulta denominada usuarios. El esquema resultante se puede
permite decidir cuales valores de la colección se desean observar en la Figura 17.
mostrar en el resultado (líneas 3-5).

Figura 15: Consulta sobre documentos anidados.

Figura 17: Representación conceptual de documentos de
La Tabla 2 muestra los resultados obtenidos en las películas, valoraciones, usuarios y sus relaciones.
pruebas. La tercera y cuarta columna representan la
cantidad de segundos que se necesitaron para finalizar la El resultado que se desea obtener es una colección en la
consulta sobre la colección; la Figura 16 presenta los cual cada documento contiene los datos sobre la película
mismos resultados en forma gráfica. Con estos resultados con todas sus valoraciones asociadas. Además, cada
se pueden notar que es recomendable utilizar el modelo valoración contiene datos sobre la persona que la realizó.
de documentos anidados de MongoDB debido a que Por lo tanto, se obtiene un segundo grado de anidación tal
ofrece un menor tiempo de ejecución, reduciendo hasta en como se presenta en la Figura 18. En la Figura 19 se
10 veces el tiempo comparado con el operador lookup. puede observar un ejemplo simplificado del documento
resultado que se espera obtener en formato de MongoDB.
 La colección base es la de películas (línea 1). El proceso
inicia con la unión (join) por medio del operador lookup
entre la colección base con la colección de valoraciones
(líneas 3-8). Como resultado de esta operación se crea un
arreglo de valoraciones asociados a cada película. Sin
embargo, para realizar la unión con la colección usuarios
el operador lookup (línea 11) necesita que cada valoración
sea un documento independiente y no representado como
un arreglo. Por esta razón se requiere el uso del operador
unwind, el cual separa un arreglo en nuevos documentos
(línea 10). Se crean tantos nuevos documentos como
valoraciones hayan. Sin embargo, al usar el operador
unwind surge un nuevo problema: para cada nuevo
documento se asigna el mismo valor de “_id” generando
un error de ejecución. Para solucionar este problema,
Figura 18: Representación conceptual de documento con MongoDB ofrece el operador project para indicar cuales
segundo grado de anidación. campos deben conservarse para siguientes etapas de la
ejecución de la tubería. Como se puede en la Figura 20
(línea 9) se indica que el campo “_id” no debe
conservarse y los documentos generados contienen el
campo “_id” con valores distintos para cada uno de ellos
generado por MongoDB, evitando así colisiones.
Posteriormente, (línea 11 en la Figura 20) para cada par
de documento-valoración se realiza la unión (lookup) con
los usuarios para indicar los datos de las personas que
emitieron la evaluación a la película. Esto implica que el
identificador es reemplazado por los datos de la persona.
Debido a que existen tantos documentos como
Figura 19: Ejemplo del documento con segundo grado de valoraciones, se requiere aplicar el operador group para
anidación en MongoDB. agrupar las películas con respecto a identificador de
La consulta desarrollada para obtener documentos con película (línea 18) e incluir otros campos de agrupación
doble anidación, utiliza la tubería de agregación como se (líneas 19, 20). Finalmente, utilizando el operador push, el
puede observar en la Figura 20. El conjunto de datos cual crea un arreglo para el campo que recibe por
usados es: usuarios (70 mil), películas (20, 40, 80, 200, parámetro, se genera un arreglo con todas las valoraciones
400) y valoraciones (156032, 285752, 421998, 800681, asociadas a cada película. Como parámetro opcional
1634491), respectivamente para cada prueba. (línea 23), se permite al sistema hacer uso de disco ya que
la operación de agrupación consume todo el espacio de
memoria reservado por MongoDB.
En la Figura 21 se pueden apreciar los tiempos de
ejecución de la consulta descrita en la Figura 19. Se
puede observar que con 400 películas los tiempos superan
los 250 segundos, lo cual es un tiempo muy elevado para
cantidad tan pequeña de muestras.

Figura 20: Tubería de agregación para obtener películas Figura 21: Gráfica de tiempos de ejecución doble de
anidadas con sus valoraciones y usuarios. lookup.
 Una modificación estructural simple, para reducir los Atlanta, GA, USA, 2013, vol. 2324, p. 36.
tiempos de ejecución, es reemplazar los identificadores de [4] K. Banker, MongoDB in action. Manning
usuarios de la colección que se encuentran en documentos Publications Co., 2011.
de valoraciones por los datos del usuario, pertenecientes a
[5] MongoDB, “NoSQL Databases Explained.” .
la colección usuarios. Con dicha modificación la
colección usuarios sería innecesaria y se puede realizar [6] C. O. Truică, A. Boicea, and I. Trifan, “CRUD
unión de dos colección no de tres, tal como se realizó en operations in MongoDB,” in Proc. 2013 int. Conf.
la sección 5.1 Figura 13. Advanced Computer Science and Electronics
Information, Ed. Atlantis Press, 2013.
6 Conclusiones [7] A. Boicea, F. Radulescu, and L. I. Agapin,
Debido al crecimiento constante de la cantidad de datos “MongoDB vs Oracle-Database Comparison.,” in
no estructurados, se buscan nuevas alternativas a las bases EIDWT, 2012, pp. 330–335.
de datos relacionales. Entre estas nuevas alternativas se [8] C. Băzăr, C. S. Iosif, and others, “The transition
encuentran sistemas como MongoDB, Cassandra, Redis, from RDBMS to NoSQL. a comparative analysis
entre otros. En este trabajo se consideró el sistema of three popular non-relational solutions:
MongoDB debido a su alta popularidad. MongoDB Cassandra, MongoDB and CouchBase,” Database
permite crear y manipular documentos que forman parte Syst J, vol. 5, no. 2, pp. 49–59, 2014.
de un conjunto de documentos, llamado colección. Los [9] A. B. M. Moniruzzaman and S. A. Hossain,
documentos se presentan como un par de llave–valor. Los “NoSQL database: New era of databases for big
documentos que pertenecen a la misma colección no data analytics-classification, characteristics and
tienen que tener las mismas características (llaves). comparison,” arXiv Prepr. arXiv1307.0191, 2013.
Además, los documentos pueden ser representados como
[10] Z. Parker, S. Poe, and S. V Vrbsky, “Comparing
estructuras más complejas añadiendo o referenciando
NoSQL MongoDB to an SQL DB,” in Proc. 51st
otros documentos. Los documentos, parecido a las bases
ACM Southeast Conf., 2013, p. 5.
de datos relacionales, pueden ser indexados.
[11] A. Nayak, A. Poriya, and D. Poojary, “Type of
Para ejemplificar el uso de MongoDB se presentó una NoSQL databases and its comparison with
serie de operaciones básicas de la tubería de agregación relational databases,” Int. J. Appl. Inf. Syst., vol.
(aggregate pipeline) y de las operaciones de mapeo- 5, no. 4, pp. 16–19, 2013.
reducción (map-reduce). Debido a las diferentes
[12] R. Copeland, MongoDB applied design patterns.
alternativas que existen en colecciones de documentos, el
“ O’Reilly Media, Inc.,” 2013.
uso de índice o forma de expresar las consultas, se
realizaron pruebas de comparación de tiempos de [13] R. Arora and R. R. Aggarwal, “Modeling and
ejecución usando estas alternativas. Como resultado se querying data in MongoDB,” Int. J. Sci. Eng.
obtuvo que para disminuir el tiempo de ejecución en Res., vol. 4, no. 7, 2013.
forma considerable es necesario contar con el índice para [14] H. Vera, M. H. Wagner Boaventura, V.
el operador lookup usado para unir dos colecciones, Guimaraes, and F. Hondo, “Data Modeling for
Además, se mostró el incremento del tiempo de ejecución NoSQL Document-Oriented Databases,” in
del mismo operador lookup cuando se utiliza índice en CEUR Workshop Proc., 2015, vol. 1478, pp. 129–
lugar de usar documentos anidados. Por último, se expuso 135.
un caso de ejemplo para mostrar la importancia de [15] Y. Liu, Y. Wang, and Y. Jin, “Research on the
estructurar los datos acordes a las consultas a realizar y improvement of MongoDB Auto-Sharding in
del efecto positivo de una buena estructuración sobre la cloud environment,” in Computer Science &
eficiencia y efectividad del sistema. Aunque en Education (ICCSE), 2012 7th Int. Conf. on, 2012,
configuraciones más potentes y en la utilización de varios pp. 851–854.
nodos podrían cambiar los resultados obtenidos en el
[16] A. Kanade, A. Gopal, and S. Kanade, “A study of
orden de magnitud, los experimentos realizados sirven
normalization and embedding in MongoDB,” in
como un medio de comparación y selección de
Advance Computing Conf. (IACC), 2014 IEEE
alternativas presentes en MongoDB.
Int., 2014, pp. 416–421.
Referencias bibliográficas [17] K. Chodorow, MongoDB: the definitive guide. “
O’Reilly Media, Inc.,” 2013.
[1] G. Lars, “HBase: the definitive guide,” Probl. [18] MongoDB, “MongoDB Documentation 3.4 -
with Relational Database Syst. First Ed. O’really, Aggregation.” .
vol. 385, 2011. [19] MongoDB, “MongoDB Documentation 3.4 -
[2] A. Lakshman and P. Malik, “Cassandra: a Indexes.” .
decentralized structured storage system,” ACM [20] MongoDB, “MongoDB Documentation 3.4 -
SIGOPS Oper. Syst. Rev., vol. 44, no. 2, pp. 35– $lookup (aggregation).” .
40, 2010. [21] MongoDB, “MongoDB Documentation 3.4 - Data
[3] J. J. Miller, “Graph database applications and Models.” .
concepts with Neo4j,” in Proc. Southern
Association for Information Systems Conf.,

View publication stats