Matheus Barbosa Silva; Vinicius Santos Andrade

DOI: 10.22167/2675-6528-202601234

Artículo elaborado por la herramienta ResumeAI, solución de inteligencia artificial desarrollada por el Instituto Pecege orientada a la síntesis y redacción.

Resumen

Se investigó la optimización de consultas en bases de datos MongoDB, considerando la relevancia del procesamiento de datos a gran escala en el contexto NoSQL. El estudio tuvo como objetivo evaluar, mediante experimentos prácticos, cómo la estructura y la configuración de los índices influyen en el rendimiento de lectura y el costo operativo de escritura. La metodología empleó investigación bibliográfica exploratoria e investigación experimental cuantitativa, que incluyó diez experimentos controlados utilizando bases de datos públicas, como NYC 311 Service Requests. Los resultados demostraron que los índices de campo único redujeron el tiempo medio de ejecución en casi un 100% para atributos de alta cardinalidad, pero tuvieron una eficacia limitada en campos de baja cardinalidad debido a la selectividad. Se verificó el impacto determinante de la regla del prefijo en índices compuestos y se identificó el punto de inflexión donde el costo de búsqueda individual de documentos superó el escaneo secuencial. Adicionalmente, se observó que la acumulación excesiva de índices elevó la latencia de escritura y la contención de recursos en el motor de almacenamiento. Se concluyó que, si bien los índices son fundamentales para la escalabilidad, exigen una planificación criteriosa de la distribución de los datos para prevenir que el mecanismo de selección de planes de MongoDB adopte estrategias subóptimas.

Palabras clave: Rendimiento; Índices; NoSQL; Planes de Ejecución; Selectividad.

1. Introducción

Las bases de datos no relacionales, a menudo denominadas NoSQL, se han convertido en pilares esenciales en las arquitecturas de aplicaciones modernas, especialmente aquellas que se ocupan del almacenamiento y procesamiento de datos a gran escala. Escenarios como las redes sociales, las aplicaciones de Internet de las Cosas (IoT) y las plataformas de consumo de medios generan volúmenes masivos de datos que requieren sistemas capaces de gestionar y consultar información con alta demanda y volumen. En este contexto, la eficiencia en la inserción y consulta de datos es crucial, ya que impacta directamente la experiencia del usuario y la economía de recursos computacionales. MongoDB, un popular sistema de gestión de bases de datos (SGBD) no relacional, destaca por su capacidad de escalabilidad horizontal y soporte para diversos tipos de índices, lo que lo convierte en un objeto de estudio relevante para la optimización de consultas en entornos de Big Data (Chopade & Pachghare, 2020).

Una de las principales estrategias para optimizar el rendimiento de consultas en bases de datos no relacionales, como MongoDB, es la construcción y el uso eficiente de índices. Los índices son estructuras de datos que organizan lógicamente uno o más atributos de una colección, permitiendo que el sistema localice rápidamente los documentos deseados sin la necesidad de escanear exhaustivamente todos los registros. Esta capacidad de definir un alcance de búsqueda más restringido es fundamental para agilizar las operaciones de lectura, especialmente en atributos con alta cardinalidad y que se utilizan frecuentemente como filtros. La optimización de índices es un proceso continuo que tiene como objetivo maximizar la eficiencia en el uso de recursos computacionales, como memoria y poder de procesamiento, como señalan Marat et al. (2024).

A pesar de los beneficios evidentes en la aceleración de consultas, la implementación y el mantenimiento de índices no son operaciones exentas de costos y complejidades. La literatura técnica advierte sobre un trade-off significativo entre el rendimiento de lectura y el costo operativo de escritura. Cada índice añadido a una colección impone un esfuerzo adicional al motor de almacenamiento, exigiendo el mantenimiento síncrono de la estructura de árbol B+ ante cada alteración en los datos (Chopade & Pachghare, 2020). En entornos con alta concurrencia de escritura, la acumulación excesiva de índices puede llevar al aumento de la latencia de escritura y a la contención de bloqueos por recursos, impactando el rendimiento global del sistema (Tao et al., 2024). Además, el mecanismo de selección de planes de consulta del MongoDB, basado en un enfoque empírico conocido como First Past The Post (FPTP), puede presentar un sesgo que favorece planes de índice rápidos para los primeros resultados, pero subóptimos para consultas que devuelven grandes volúmenes de datos, lo que puede anular las ganancias de optimización esperadas.

Para mitigar estos desafíos y garantizar una optimización eficaz, es crucial comprender conceptos teóricos como la selectividad de consultas y el punto de inflexión (tipping point). La selectividad se refiere a la proporción de documentos devueltos por una consulta en relación con el total de la colección, y su baja incidencia puede hacer que el uso de índices sea menos ventajoso que un escaneo secuencial completo (Tao et al., 2024). El punto de inflexión marca el umbral donde el costo de recorrer el índice y buscar individualmente cada documento supera el beneficio de la indexación. Adicionalmente, la regla del prefijo en índices compuestos es determinante, ya que MongoDB utiliza estos índices solo cuando los campos del filtro forman un prefijo continuo a partir del primer campo del índice (Chopade & Pachghare, 2020). La máxima eficiencia se alcanza con consultas cubiertas (covered queries), donde todos los campos de filtro y proyección están contenidos en el índice, eliminando la necesidad de acceso a los documentos originales en disco y minimizando el costo computacional (Chopade & Pachghare, 2020; Tao et al., 2024).

Dada la complejidad y los múltiples factores que influyen en la optimización de consultas en bases de datos NoSQL como MongoDB, se hace imperativo un estudio en profundidad sobre el impacto de diferentes tipos y configuraciones de índices. La comprensión de estos mecanismos internos y la cuantificación de sus efectos permiten estructurar buenas prácticas y extender los beneficios de la optimización a diversos contextos de aplicación. Así, este estudio se propone analizar la influencia positiva y negativa en la optimización de consultas de diversos tipos de índices disponibles en bases de datos MongoDB, con el objetivo general de evaluar, mediante experimentos prácticos, cómo la estructura y la configuración de índices influyen en el rendimiento de lectura y el costo operativo de escritura.

2. Material y Métodos

La presente investigación se desarrolló a través de un enfoque metodológico mixto, que integró una investigación bibliográfica exploratoria con una investigación experimental de naturaleza cuantitativa. La etapa exploratoria tuvo como propósito describir y analizar el funcionamiento y las particularidades de los diversos tipos de índices disponibles en el sistema gestor de bases de datos MongoDB. Este análisis teórico proporcionó la base para la formulación de los experimentos prácticos, permitiendo la verificación de las características observadas en un entorno controlado.

La investigación experimental se diseñó para validar y cuantificar el potencial de optimización de diferentes tipos y configuraciones de índices sobre el rendimiento de lectura y el costo operativo de escritura en instancias de MongoDB. Para ello, se llevaron a cabo diez experimentos controlados, cada uno diseñado para aislar un concepto específico, como la selectividad de consultas, la cobertura de consultas o el impacto en el costo de escritura. Esta estructura permitió la comparación directa entre escenarios con y sin la característica de indexación bajo investigación.

Los experimentos se llevaron a cabo en un entorno local de instancia única de MongoDB, configurado sin sharding ni replica sets, con el fin de aislar el comportamiento de los índices de las variables inherentes a las topologías distribuidas. El entorno computacional consistió en un Subsistema de Windows para Linux (WSL2) con la distribución Debian 10, operando sobre el sistema operativo Windows 11 de 64 bits. Se utilizó la versión 8.0 de MongoDB, la más estable en ese momento.

El equipo empleado para la ejecución de los experimentos poseía un procesador AMD Ryzen 7 3700U (2,30GHz, 8 núcleos) y 20 GB de memoria RAM, de los cuales 17,9 GB estaban disponibles para el sistema operativo. La elección de este entorno visó replicar un escenario de desarrollo y prueba común, garantizando la reproducibilidad de los resultados obtenidos.

Para la realización de los experimentos, se emplearon dos bases de datos públicas. La principal fue el conjunto NYC 311 Service Requests, obtenido del portal NYC Open Data (data.cityofnewyork.us). Este dataset, con más de 20 millones de registros de solicitudes de servicios públicos desde 2020, presentaba campos de diversas naturalezas, incluyendo fechas, coordenadas geográficas y categorías de alta y baja cardinalidad.

Adicionalmente, para los experimentos que involucraban campos del tipo array, se utilizó el conjunto sample_mflix, un dataset de muestra distribuido oficialmente por MongoDB. Este conjunto contiene documentos de películas con campos de lista, como géneros y elenco. La importación de ambos datasets a colecciones MongoDB locales se realizó por medio de la herramienta `mongoimport`.

El protocolo de medición fue uniforme en todos los experimentos. Cada consulta u operación se ejecutó cincuenta veces consecutivas en condiciones idénticas, a excepción de los experimentos de escritura, para los cuales el número de repeticiones fue de treinta, debido a la mayor duración de estas operaciones. La métrica principal recopilada fue el tiempo de ejecución en milisegundos, obtenida a través del método `explain` de MongoDB, que reporta el tiempo real de ejecución del motor de consultas, excluyendo la latencia de red.

Métricas secundarias, como el número de documentos y claves examinadas, se registraron para ayudar en la interpretación del mecanismo interno de cada plan de ejecución. La elección de cincuenta repeticiones por condición se determinó por la necesidad de estabilizar la estimación de la media, considerando la variabilidad natural de ejecuciones en un entorno local, donde factores como el estado de la caché del sistema operativo y la concurrencia de procesos pueden introducir fluctuaciones.

Con este volumen de observaciones, fue posible construir intervalos de confianza del 95% para la media, utilizando la distribución t de Student con n-1 grados de libertad. Este enfoque es adecuado para muestras de tamaño finito sin la presunción de normalidad de la población. El control explícito del estado de la caché de planes se implementó en cada experimento para distinguir rigurosamente entre lecturas frías y lecturas calientes.

El mecanismo de selección de planes de MongoDB, conocido como First Past The Post (FPTP), ha sido un punto central de investigación, como se describe en Tao et al. (2024). Este mecanismo adopta un enfoque empírico, donde se prueban simultáneamente múltiples planes de ejecución, y el “ganador” es aquel que devuelve los primeros resultados más rápidamente, lo que puede introducir un sesgo de preferencia por los escaneos de índice.

La comprensión de la estructura de árbol B+ utilizada por los índices de MongoDB, que exige un mantenimiento continuo y síncrono con cada cambio en los datos, fue fundamental para el análisis del costo operativo de escritura (Chopade & Pachghare, 2020). Cada nuevo índice añadido a una colección impone un esfuerzo adicional al motor de almacenamiento, impactando la latencia de escritura y la contención de bloqueos en escenarios de alta concurrencia.

El proceso de ejecución y recopilación de datos de los experimentos siguió un esquema que implicó la importación de datos externos a través de `mongoimport` y `mongorestore` a una instancia local de MongoDB 8.0. Se emplearon scripts de Python 3.11, utilizando las bibliotecas `pymongo` y `scipy`, para ejecutar las consultas, recopilar las métricas de `executionTimeMillis` y calcular los intervalos de confianza del 95%.

Los datos recolectados fueron organizados en archivos CSV, y los resultados fueron visualizados por medio de gráficos generados con la biblioteca `matplotlib`. En total, se llevaron a cabo diez experimentos. Los experimentos del 1 al 8 investigaron el impacto de diferentes tipos de índices en el rendimiento de lectura, abarcando índices de campo único, compuestos, de texto, geoespaciales y multiclave, así como los conceptos de selectividad, consultas cubiertas y el comportamiento de la caché de planes.

Los experimentos 9 y 10 se centraron en los costos asociados con el mantenimiento de índices, midiendo el impacto en las operaciones de escritura y evaluando el ahorro de almacenamiento proporcionado por índices parciales. El análisis de los datos se realizó basándose en las métricas de tiempo de ejecución y el número de documentos y claves examinadas, sin presentar hallazgos empíricos ni interpretaciones de resultados en esta sección.

3. Resultados y Discusión

La optimización de consultas en bases de datos MongoDB es un tema central para aplicaciones que manejan el procesamiento y almacenamiento de datos a gran escala, como se observa en redes sociales y plataformas de IoT. En este contexto, la eficiencia en la lectura y escritura de datos es crucial, impactando directamente la experiencia del usuario y la economía de recursos computacionales. La utilización de índices surge como una estrategia fundamental para agilizar las operaciones de lectura, organizando lógicamente atributos de una colección para permitir la localización rápida de documentos, según lo destacado por Chopade y Pachghare (2020).

Sin embargo, la implementación de índices no está exenta de costos y complejidades. Existe una compensación significativa entre el rendimiento de lectura y el costo operativo de escritura, ya que cada índice agregado requiere el mantenimiento síncrono de la estructura del árbol B+ con cada cambio en los datos (Chopade & Pachghare, 2020). En entornos con alta concurrencia de escritura, la acumulación excesiva de índices puede aumentar la latencia y la contención de recursos, afectando el rendimiento general del sistema (Tao et al., 2024). El mecanismo de selección de planes de consulta de MongoDB, basado en el enfoque empírico First Past The Post (FPTP), aún puede favorecer planes rápidos para los primeros resultados, pero subóptimos para consultas que devuelven grandes volúmenes de datos, lo que anula las ganancias esperadas.

Para mitigar estos desafíos, es esencial comprender conceptos como la selectividad de consultas y el punto de inflexión. La selectividad indica la proporción de documentos devueltos por una consulta en relación con el total de la colección, y una baja selectividad puede hacer que el uso de índices sea menos ventajoso que un escaneo secuencial (Tao et al., 2024). El punto de inflexión demarca el umbral donde el costo de recorrer el índice y buscar individualmente cada documento supera el beneficio de la indexación. La regla del prefijo en índices compuestos también es determinante, ya que MongoDB los utiliza solo cuando los campos del filtro forman un prefijo continuo a partir del primer campo del índice (Chopade & Pachghare, 2020).

La máxima eficiencia se logra con consultas cubiertas (covered queries), en las cuales todos los campos de filtro y proyección están contenidos en el índice, eliminando la necesidad de acceder a los documentos originales en el disco y minimizando el costo computacional (Chopade & Pachghare, 2020; Tao et al., 2024). Por lo tanto, este estudio analizó la influencia de diversos tipos y configuraciones de índices en bases de datos MongoDB, evaluando cómo la estructura y la configuración de los índices impactan el rendimiento de lectura y el costo operativo de escritura a través de experimentos prácticos.

Clases de índices

Para optimizar el rendimiento de las consultas, la elección del tipo de índice adecuado es fundamental, considerando la estructura de los datos y los patrones de búsqueda de la aplicación. MongoDB ofrece una variedad de índices que utilizan la estructura de un árbol B+ para localizar documentos de manera eficiente, evitando escaneos completos de la colección (collection scans), como describen Chopade y Pachghare (2020). Entre los tipos principales, el Índice de Campo Único es la forma más básica, aplicada a un solo campo, siendo esencial para búsquedas directas y creado automáticamente para el identificador único de la colección (_id).

El Índice Compuesto abarca múltiples campos en una única estructura para cubrir consultas con múltiples filtros. El orden de los campos es crucial, ya que MongoDB utiliza el índice solo cuando los campos del filtro forman un prefijo continuo a partir del primer campo del índice. Por otro lado, el Índice Multiclave está diseñado para indexar campos que contienen arrays, creando entradas de índice separadas para cada elemento del array, lo que mejora la eficiencia de las búsquedas de elementos dentro de listas (Chopade & Pachghare, 2020).

Para aplicaciones que dependen de coordenadas geográficas, el Índice Geoespacial (tipos 2d y 2dsphere) optimiza las consultas de proximidad y la verificación de inclusión en áreas específicas. El Índice de Texto permite buscar términos dentro de cadenas de texto considerando aspectos lingüísticos, como las raíces de las palabras, y es siempre disperso, aplicándose solo a documentos con valores para los campos indexados. Por último, el Índice Hashed, aplicado a un único campo, almacena el hash del valor indexado y se utiliza frecuentemente en entornos de sharding para garantizar una distribución uniforme de los documentos entre los nodos de un clúster.

Además de estos, MongoDB ofrece Índices de Propiedades Especiales. Los Índices TTL (Time-To-Live) eliminan documentos más antiguos que un tiempo especificado. Los Índices Únicos garantizan la unicidad de los valores de los campos, impidiendo la inserción de duplicados. Los Índices Parciales restringen la aplicación de un índice a documentos que cumplen criterios específicos, siendo útiles para colecciones grandes o filtros específicos, ya que ocupan menos espacio de almacenamiento.

Mecanismo de selección de planes e índices

MongoDB adopta un enfoque empírico para la selección de planes de ejecución, a diferencia de los sistemas relacionales que utilizan estimaciones de costo estadísticas. Este mecanismo, descrito por Tao et al. (2024) como First Past The Post (FPTP), funciona como una “carrera” entre diferentes estrategias de búsqueda. Cuando se envía una consulta y no hay un plan válido en caché, el optimizador genera múltiples planes candidatos, como el uso de diferentes índices o un escaneo de colección (collection scan).

Estos planes se ejecutan simultáneamente en un sistema de escalonamiento round-robin. MongoDB declara como “ganador” al plan que devuelve una cantidad predefinida de resultados (generalmente los primeros 101 documentos) con el menor “trabajo” computacional, medido por unidades de esfuerzo interno como lecturas de disco o entradas de índice recorridas. Una vez seleccionado, el plan se almacena en una caché de planes de consulta (Query Plan Cache) para optimizar ejecuciones futuras de consultas con estructura lógica idéntica, evitando el costo de la fase de prueba.

Sin embargo, la caché de planes se invalida en escenarios específicos, como cambios significativos en el volumen de datos, creación o eliminación de índices, o reinicio del servidor. Tao et al. (2024) identificaron un “sesgo de preferencia” del optimizador: como el criterio de victoria se basa en los primeros resultados, MongoDB tiende a favorecer escaneos de índice (index scans) que encuentran los primeros registros rápidamente. En consultas con baja selectividad, el tiempo total para recorrer un índice y buscar cada documento individualmente puede superar el tiempo de un escaneo secuencial, demostrando que la mera existencia de un índice no garantiza la optimización global.

Análisis del Trade-off entre rendimiento de lectura y costo de escritura

La implementación de índices en MongoDB no es una operación sin costos. Si bien el enfoque principal es la reducción de la latencia en las consultas, la literatura técnica advierte sobre el impacto colateral en las operaciones de modificación de datos. La eficiencia de las consultas se logra a través de una estructura de árbol B+ que requiere mantenimiento continuo y síncrono con cada cambio en el conjunto de datos, según lo detallado por Chopade y Pachghare (2020).

Cada nuevo índice añadido a una colección impone un esfuerzo adicional al motor de almacenamiento, como WiredTiger. Al insertar, eliminar o actualizar un documento, MongoDB no solo modifica los datos brutos, sino que también necesita actualizar de forma síncrona todas las entradas correspondientes en los índices asociados. En escenarios de alta concurrencia de escritura, la acumulación de índices conduce a dos efectos secundarios principales: el aumento de la latencia de escritura y la contención de bloqueos (lock contention).

El aumento de la latencia de escritura se debe a que el tiempo necesario para completar una operación de escritura tiene una relación de proporcionalidad directa con la cantidad de índices definidos en la colección (Chopade & Pachghare, 2020). El motor de almacenamiento replica las actualizaciones en cada estructura e índice individualmente, lo que resulta en un mayor tiempo de respuesta para las operaciones de escritura. La contención de bloqueos, por su parte, ocurre cuando el motor de búsqueda intenta actualizar simultáneamente varias páginas de índices en la caché de memoria, generando una disputa por recursos entre diferentes hilos de ejecución (Tao et al., 2024).

Incluso con mecanismos modernos de gestión de concurrencia, esta sobrecarga reduce la eficiencia del procesamiento en paralelo, pudiendo transformar el índice en un cuello de botella de rendimiento sistémico en entornos de escritura intensiva. Otro factor crítico es que, para máxima eficiencia, los índices deben residir en la memoria RAM, formando el conjunto residente. Índices voluminosos o en exceso pueden exceder la capacidad de la caché, forzando al sistema a realizar operaciones de lectura y escritura directamente en el disco (swapping), lo que degrada drásticamente el rendimiento global (Tao et al., 2024).

El impacto del almacenamiento físico también es relevante, ya que índices complejos, como los de clave múltiple o de texto, pueden ocupar más espacio en disco que los propios documentos originales. La optimización en MongoDB, por lo tanto, debe verse como un equilibrio de recursos, ponderando la ganancia de velocidad en la lectura contra el costo de infraestructura y la agilidad de las operaciones de escritura. El análisis de Chopade y Pachghare (2020) sugiere que es preferible consolidar un índice compuesto que atienda a múltiples patrones de consulta, respetando la regla del prefijo, en lugar de mantener diversos índices individuales superpuestos, minimizando el impacto en las escrituras y optimizando el uso de la caché de memoria.

Mantenimiento de índices

La naturaleza dinámica de los índices en bases de datos MongoDB, que crecen y se alteran con la cantidad de datos almacenados, hace que su mantenimiento sea una tarea continua. Es esencial analizarlos y actualizarlos recurrentemente para que permanezcan relevantes ante las actualizaciones de esquemas y el crecimiento de la escala de la base de datos. Además, se debe considerar el espacio de almacenamiento ocupado por los índices, ya que los índices grandes no solo impactan el almacenamiento, sino también la velocidad de las operaciones de escritura, puesto que las actualizaciones de datos implican modificaciones en las estructuras indexadas (Marat et al., 2024).

El tamaño de los índices mantenidos por una base de datos es un factor crítico para el rendimiento de las operaciones, especialmente en contextos de gran escala, donde las bases de datos orientadas a documentos se aplican comúnmente. Así, la definición de los índices debe acompañar las actualizaciones del esquema de datos de la base, garantizando que los beneficios proporcionados por estas estructuras no se pierdan. Es deseable que el tamaño ocupado por los índices esté justificado por sus casos de uso, de modo que la pérdida de rendimiento en operaciones de escritura sea razonable y justificable dentro del contexto de la aplicación.

Punto de inflexión de la selectividad de índices (Tipping point)

Uno de los conceptos más críticos en la optimización de bases de datos no relacionales es la selectividad de las consultas, que define la proporción de documentos devueltos en relación con el total de la colección. Como discuten Tao et al. (2024), existe un umbral teórico, denominado “punto de inflexión” (tipping point), a partir del cual la utilización de un índice deja de ser ventajosa y se vuelve más costosa que un escaneo completo de la colección (collection scan).

La ineficiencia de un índice en escenarios de baja selectividad, donde se devuelve un gran volumen de datos, se justifica por el costo operativo de la fase de recuperación. Cuando MongoDB utiliza un índice, primero recorre el árbol B+ para localizar las referencias de los documentos y luego busca cada documento individualmente en el disco o en la caché de memoria. Si la consulta devuelve una porción considerable de la colección (por encima del 30% o 40%), el esfuerzo de alternar repetidamente entre el índice y la capa de almacenamiento supera el tiempo de una lectura secuencial completa.

En esta etapa, el índice deja de ser un atajo y se convierte en un intermediario oneroso e innecesario, consumiendo ciclos de CPU y operaciones de I/O adicionales. Tao et al. (2024) destacan un desafío adicional en la optimización de consultas en MongoDB debido al criterio First Past The Post (FPTP), que tiene un sesgo inherente a favor de planes basados en índices. Dado que la “carrera” de planes termina tan pronto como se encuentran los primeros resultados, un plan de índice generalmente gana la competencia por ser ágil en la localización de los registros iniciales en su estructura de árbol B+.

Sin embargo, este mecanismo de victoria temprana no tiene en cuenta el trabajo total necesario para completar la ejecución de una consulta. De esta manera, el optimizador puede fijar en la caché un plan que es excelente para devolver los primeros 100 documentos, pero que se vuelve drásticamente subóptimo al procesar una masa de datos voluminosa. Para esta investigación, el punto de inflexión sirvió como la principal variable de prueba en el experimento práctico, permitiendo identificar situaciones donde la optimización puede requerir la eliminación o el descarte de un índice en favor de un escaneo natural, con el objetivo de disminuir el tiempo de ejecución global.

Influencia de la caché de planes en la ejecución de consultas

El análisis de rendimiento de consultas en MongoDB no puede disociarse del funcionamiento de su sistema de persistencia de decisiones, el Query Plan Cache. Según Tao et al. (2024), una vez que el mecanismo FPTP elige un plan ganador, este se almacena en caché para optimizar futuras ejecuciones de consultas con estructura idéntica, es decir, con el mismo formato de filtros, sin tener en cuenta los valores a filtrar. El beneficio inmediato de la caché es la eliminación de la fase de “carrera” de planes en cada nueva consulta.

Sin embargo, Tao et al. (2024) resaltan que esta estabilidad puede ocultar una desventaja: si el plan almacenado en la caché fue elegido bajo condiciones específicas de volumen de datos que cambiaron drásticamente, el MongoDB continuará usando una estrategia potencialmente subóptima hasta que ocurra una invalidación de la caché. Para la metodología de esta investigación, esta característica demandó la distinción rigurosa entre lecturas frías (cold reads), cuando la caché está vacía y el motor es forzado a reevaluar los índices, y lecturas calientes (warm reads), cuando el plan ya está consolidado y guardado en caché, reflejando el rendimiento real del sistema estable.

Como detallado por Chopade y Pachghare (2020), la caché de planes no es permanente, siendo invalidada automáticamente por eventos como la creación o eliminación de índices, el reinicio del servidor, o cuando el volumen de documentos alterados en la colección alcanza un umbral que sugiere que las estadísticas de distribución de los datos están obsoletas. Por lo tanto, para que los resultados y discusiones de este trabajo fueran fidedignos, los experimentos prácticos consideraron el estado de la caché. Ignorar la existencia del plan almacenado en caché podría llevar a conclusiones erróneas, atribuyendo la rapidez de una consulta solo a la eficiencia del índice, cuando, en realidad, estaría siendo beneficiada por la ausencia de la fase de competencia de planes en lecturas calientes. Esta comprensión permitió aislar la ganancia real de rendimiento proporcionada por la indexación en relación con el comportamiento adaptativo propio del optimizador de planes de consulta del MongoDB.

Optimización máxima mediante consultas cubiertas

En el límite superior de la eficiencia de indexación se encuentra el concepto de consultas cubiertas (covered queries). Según Chopade y Pachghare (2020), una consulta se considera “cubierta” cuando todos los campos solicitados en la proyección de la búsqueda, así como los criterios de filtro, forman parte del mismo índice compuesto. La relevancia técnica de este tipo de consulta reside en la eliminación completa de la fase de fetch, que es la búsqueda del documento original en el disco o caché de datos, lo que la hace más rápida. Como el índice que reside en la RAM ya contiene toda la información necesaria para devolver una respuesta al cliente, el motor de búsqueda puede evitar el acceso al almacenamiento de datos brutos.

Como discutido por Tao et al. (2024) al analizar las unidades de trabajo, el costo de una consulta cubierta es drásticamente menor, ya que reduce la utilización de E/S y minimiza la latencia de red y procesamiento. Para el experimento práctico de este trabajo, la identificación de consultas cubiertas se realizó mediante la métrica “totalDocsExamined: 0” en la explicación de la ejecución de una consulta. Encontrar y señalar escenarios de consultas cubiertas permitió demostrar que la optimización de índices no solo busca localizar documentos más rápidamente, sino también eliminar integralmente la necesidad de acceder a ellos, en un escenario ideal que permite alcanzar el mayor nivel de optimización posible proporcionado por un índice en bases de datos MongoDB.

Ambiente y configuración de los experimentos

La etapa experimental de esta investigación tuvo como objetivo medir el impacto de diferentes tipos de índices y configuraciones sobre el rendimiento de lectura y escritura en bases de datos MongoDB. Para garantizar la reproducibilidad de los resultados y la validez estadística de los intervalos de confianza, se describieron con precisión el entorno computacional, la base de datos y el protocolo de medición. Los experimentos se llevaron a cabo en un entorno local de instancia única de MongoDB, versión 8.0, ejecutado en el Subsistema de Windows para Linux (WSL2) con distribución Debian 10, sobre un sistema operativo Windows 11 de 64 bits.

El equipo utilizado contaba con un procesador AMD Ryzen 7 3700U (2,30GHz, 8 núcleos) y 20 GB de memoria RAM, con 17,9 GB disponibles para el sistema operativo. La base de datos principal fue el conjunto NYC 311 Service Requests, del portal NYC Open Data (data.cityofnewyork.us), que contiene más de 20 millones de registros de solicitudes de servicios públicos desde 2020. Este conjunto, con campos de diversas naturalezas (fechas, coordenadas, categorías de alta y baja cardinalidad, texto libre), fue adecuado para la aplicación de una amplia gama de tipos de índices.

Para experimentos que demandaban campos del tipo array, se utilizó el conjunto sample_mflix, un dataset de muestra distribuido oficialmente por MongoDB, que contiene documentos de películas con campos de lista como géneros y elenco. En ambos casos, los datos se importaron a colecciones MongoDB locales utilizando la herramienta mongoimport. El protocolo de medición adoptado en todos los experimentos fue uniforme: cada consulta u operación se ejecutó cincuenta veces consecutivas bajo las mismas condiciones, excepto para experimentos de escritura, que tuvieron treinta repeticiones debido a la mayor duración.

El tiempo medio de ejecución se registró en milisegundos, obtenido a través de la métrica `executionTimeMillis` del método `explain` de MongoDB. Este volumen de repeticiones permitió la construcción de intervalos de confianza del 95% para cada medición, según lo establecido en la Metodología. Adicionalmente, el estado de la caché de planes se controló explícitamente en cada experimento para garantizar la distinción rigurosa entre lecturas frías y calientes, donde esta distinción era relevante. Se llevaron a cabo diez experimentos, investigando el impacto de índices de campo único, compuestos, de texto, geoespaciales y multiclave, además de los conceptos de selectividad, consultas cubiertas, comportamiento de la caché de planes y costos de mantenimiento de índices.

Experimento 1: Escaneo de colección vs. índice de campo único

El primer experimento estableció el impacto fundamental de la indexación, midiendo el tiempo promedio de ejecución de 50 consultas idénticas sobre la colección NYC 311. Se compararon dos condiciones: con y sin índice de campo único, aplicadas a campos de cardinalidades distintas: `borough` (baja cardinalidad, con 5 valores) y `created_date` (alta cardinalidad). La caché de planes se limpió antes de cada serie para aislar el efecto del índice de la influencia de la caché.

Para el campo `created_date`, la ganancia de rendimiento fue expresiva: el tiempo medio de ejecución cayó de 6.658 ± 90 ms (COLLSCAN) a 0,1 ms con el índice, representando una reducción de casi el 100%. Este resultado demuestra el comportamiento esperado de un índice sobre un campo de alta cardinalidad, donde la organización de las entradas en una estructura de árbol B+ permite al MongoDB localizar el documento objetivo directamente, eliminando la necesidad de escanear los más de 5 millones de registros de la colección.

Para el campo `borough`, de baja cardinalidad, el escenario fue diferente. El índice redujo el tiempo promedio de 10.280 ± 1.110 ms a 5.677 ± 107 ms, una reducción del 44,8%. Sin embargo, la ganancia fue sustancialmente menor que en el campo de alta cardinalidad. Como discutido por Chopade y Pachghare (2020), la eficacia de un índice está directamente asociada a la cardinalidad del campo indexado: campos con pocos valores distintos poseen baja selectividad, lo que significa que cada entrada del índice aún apunta a un gran número de documentos de la colección. En el conjunto de datos examinado, uno de los valores posibles para el campo `borough` está asociado a más de 1 millón de documentos, lo que impone un costo elevado de recuperación individual de cada registro. Este comportamiento anticipa el concepto de punto de inflexión, explorado en detalle en el experimento 3.

Experimento 2: Regla del prefijo en índices compuestos

El experimento 2 midió el impacto del orden de los campos de un índice compuesto en el rendimiento de las consultas con diferentes combinaciones de filtros. Se crearon dos índices: BCD ({borough, complaint_type, created_date}) y DCB ({created_date, complaint_type, borough}). Se ejecutaron 50 consultas por escenario con variaciones de los campos presentes en el filtro de búsqueda en relación con el prefijo de cada índice.

Los resultados confirmaron la regla del prefijo descrita por Chopade y Pachghare (2020): MongoDB utiliza un índice compuesto solo cuando los campos del filtro forman un prefijo continuo a partir del primer campo del índice. Las consultas que respetaron el prefijo del índice BCD obtuvieron tiempos progresivamente menores a medida que se agregaban más campos al filtro. Por ejemplo, la consulta con solo `borough` tomó 43.890 ms, mientras que con un filtro adicional de `complaint_type` el tiempo se redujo a 0,3 ms, debido al menor número de documentos devueltos.

Consultas que violaron la regla del prefijo, como filtrar solo por `complaint_type` sin incluir `borough`, resultaron en COLLSCAN con 6912 ms, confirmando que el índice fue completamente ignorado por el optimizador. Un resultado que merece atención es el tiempo de 43.890 ms para la consulta con prefijo `borough`. Aunque el índice BCD fue correctamente utilizado (IXSCAN), el filtro `borough` tiene baja selectividad, lo que obligó al motor de búsqueda a recorrer más de 1 millón de entradas del índice y, a continuación, buscar cada uno de los documentos correspondientes individualmente en el disco en la etapa de fetch. Este costo acumulado hizo que la operación con el índice fuera 4.3 veces más lenta que un escaneo secuencial directo.

Este fenómeno es precisamente el sesgo descrito por Tao et al. (2024) en el mecanismo FPTP: el optimizador eligió el IXSCAN porque este devolvió los primeros 101 documentos rápidamente durante la fase de ejecución de planes, sin tener en cuenta el coste total de la ejecución completa. Este resultado refuerza que la existencia de un índice y el respeto a la regla del prefijo no siempre son suficientes para garantizar la eficiencia; la selectividad del campo es determinante. Por último, el índice DCB ignoró completamente la consulta por `borough` (COLLSCAN, 8.312 ms), pero la atendió en 0.0 ms cuando se proporcionaron los tres campos con el prefijo correcto. Esto demuestra que el orden de los campos en el índice debe reflejar los patrones reales de consulta de la aplicación, y que un índice mal ordenado puede ser completamente inútil para los casos de uso más frecuentes.

Experimento 3: Punto de inflexión de la selectividad

El experimento 3 investigó el punto de inflexión (tipping point) descrito por Tao et al. (2024), que es el umbral de selectividad a partir del cual el uso de un índice deja de ser ventajoso en relación con un escaneo secuencial de la colección. Para ello, se seleccionaron ocho tipos de reclamación de la base NYC 311 con selectividades que varían del 0,25% al 15,38% de la colección. Para cada uno, se realizaron 50 ejecuciones en tres condiciones: decisión libre del optimizador, IXSCAN forzado (mediante hint) y COLLSCAN forzado (mediante $natural).

En bajas selectividades, el IXSCAN fue expresivamente superior: para 0,25% de selectividad, el IXSCAN completó la consulta en 40 ± 2 ms, contra 7.206 ± 244 ms del COLLSCAN, una diferencia de 180 veces. A medida que la selectividad aumentó, la ventaja del IXSCAN disminuyó progresivamente. A partir de aproximadamente 2% de selectividad, los tiempos del IXSCAN y del COLLSCAN pasaron a converger, pero aún con ventaja para la ejecución con el índice.

El mecanismo subyacente reveló que el número de documentos examinados por IXSCAN crece linealmente con la selectividad, mientras que COLLSCAN siempre examina el total de la colección (más de 5 millones de documentos), independientemente del filtro. El cruce de las dos curvas de tiempo ocurre precisamente en el intervalo en que el costo acumulado de recorrer el árbol B+ y buscar individualmente cada documento en el disco supera el costo de una lectura secuencial. Este hallazgo refuerza la importancia de considerar la selectividad para la decisión de indexación.

Experimento 4: Consultas cubiertas

El experimento 4 evaluó el impacto de la eliminación de la etapa de fetch mediante consultas cubiertas (covered queries). Tras garantizar el estado limpio de la colección (sin índices), se midieron 50 ejecuciones en tres condiciones para la consulta {borough: “MANHATTAN”, complaint_type: “Noise – Residential”}: sin índice (COLLSCAN), con índice compuesto {borough, complaint_type, created_date} y proyección no cubierta (IXSCAN + FETCH), y con el mismo índice y proyección cubierta (campos retornados restringidos a los presentes en el índice).

La condición COLLSCAN completó la consulta en 9.968 ms, escaneando los 5 millones de documentos de la colección. Con un índice y una proyección no cubierta, el tiempo se redujo a 3.338 ms, lo que representa una reducción significativa, aunque el motor de búsqueda aún necesitaba acceder individualmente a los documentos que satisfacían el filtro en la etapa de recuperación para obtener los valores de los campos no cubiertos. La consulta cubierta, por su parte, completó la ejecución en solo 119 ms, lo que representa una reducción del 96% en comparación con el IXSCAN con recuperación.

El mecanismo responsable de esta diferencia fue confirmado por la métrica `totalDocsExamined`, que fue cero para la consulta cubierta, mientras que en la consulta con IXSCAN y campos no cubiertos en el índice fue necesario examinar 88.627 documentos para obtener los valores de los campos no cubiertos. Como exponen Chopade y Pachghare (2020), una consulta cubierta es aquella cuyos campos de filtro y de proyección están integralmente presentes en el mismo índice compuesto, permitiendo al motor de búsqueda responder directamente a la búsqueda sin necesidad de acceso adicional al almacenamiento de documentos. Tao et al. (2024) identifican este escenario como el de menor costo posible en términos de unidades de trabajo, eliminando completamente las operaciones de I/O asociadas a la recuperación de los datos brutos. Por lo tanto, la identificación de escenarios propicios a consultas cubiertas constituye la forma más eficiente de optimización por indexación disponible en MongoDB.

Experimento 5: Caché de planes – lecturas frías vs. calientes

El experimento 5 aisló el impacto de la caché de planes en el tiempo de ejecución de consultas, diferenciando tres series de 50 ejecuciones: lecturas en frío (caché limpia antes de cada ejecución), lecturas en caliente (caché limpia una vez antes de la serie completa) y una serie post-invalidación (caché calentada deliberadamente invalidada por la creación de un nuevo índice). La curva de las lecturas en frío evidenció un pico expresivo en las primeras ejecuciones: la primera consulta tomó 7.476 ms, el doble del valor estabilizado, seguida de una caída abrupta hasta el nivel de aproximadamente 3.600 ms a partir de la tercera ejecución.

Este pico inicial corresponde a la fase de “carrera” de planes del mecanismo FPTP descrito por Tao et al. (2024): sin un plan válido en caché, el optimizador ejecuta múltiples candidatos en paralelo para elegir al ganador, lo que impone un coste adicional en comparación con las ejecuciones siguientes, dado que en las próximas consultas el plan ya está almacenado. Tras el efecto de calentamiento de la caché, las distribuciones de las tres series fueron estadísticamente similares, con superposición de los intervalos de confianza, lo que indica que, una vez estabilizada la caché, su estado no altera materialmente el tiempo de ejecución medio para esta consulta específica.

El resultado relevante es el comportamiento transitorio, donde las aplicaciones que realizan consultas poco frecuentes sobre una colección dada, o que invalidan la caché constantemente, se ven afectadas por el costo de la fase de selección de planes. Esto subraya la importancia de considerar el ciclo de vida de la caché y la frecuencia de las consultas al diseñar estrategias de indexación, especialmente en entornos de producción con cargas de trabajo variables.

Experimento 6: Índice de texto vs. expresión regular

El experimento 6 comparó dos enfoques para búsquedas textuales en la colección NYC 311: el operador `$regex` con escaneo secuencial y el operador `$text` con índice de texto. Se realizaron 50 ejecuciones por condición sobre el campo `resolution_description`, que contiene descripciones textuales. Los resultados demostraron una diferencia de rendimiento expresiva. La búsqueda con `$regex` realizó un COLLSCAN en todos los más de 5 millones de documentos y completó cada ejecución en 15.590 ± 185 ms.

En contraste, la búsqueda con `$text` utilizó el índice y completó la misma búsqueda en 730 ± 30 ms, siendo 21 veces más rápida. La búsqueda con exclusión de términos, que demanda una evaluación adicional del motor textual para filtrar los resultados, llevó 1.791 ms ± 47 ms con el índice, aún así 8,7 veces más rápida que el `$regex`. Estos resultados evidencian la superioridad del índice de texto para búsquedas textuales complejas.

Sin embargo, esta optimización tiene un costo de almacenamiento significativo: el índice de texto ocupó 656.3MB en disco, lo que es aproximadamente 12 veces mayor que el tamaño del índice predeterminado (_id). Este costo de almacenamiento puede, en algunos casos, superar incluso el tamaño de los propios documentos y debe ser considerado en la decisión de creación del índice. Para este experimento, el índice de texto para un solo campo ocupó alrededor del 13% del espacio total consumido por la colección, con más de 5 millones de documentos.

Ensayo 7: Índice geoespacial

El experimento 7 evaluó el rendimiento de consultas geoespaciales con el índice 2dsphere de MongoDB. Para ello, se creó el campo `location_geo` en los documentos de la colección NYC 311 en formato GeoJSON. Se realizaron 50 ejecuciones por condición con el operador `$near` para búsquedas con radios que varían entre 500m y 10km, además de una serie con el operador `$geoWithin` aplicado a un polígono correspondiente a la isla de Manhattan.

El resultado más inmediato fue que la operación `$near` ejecutó todas las búsquedas para diferentes radios en tiempos medios estadísticamente equivalentes, variando de 17,5 ± 4,1 ms para 500 m a 15,9 ± 0,7 ms para 10 km, sin un crecimiento perceptible en función del aumento del radio. Este comportamiento se explica por el límite de 1000 documentos devueltos configurado en el experimento: independientemente del radio, el índice devuelve los 1000 documentos más cercanos al punto de referencia buscado, de modo que el costo permaneció constante, demostrando la eficiencia del índice 2dsphere para consultas de proximidad con retorno limitado.

En contraste, el operador `$geoWithin` con el polígono de Manhattan presentó un comportamiento opuesto: sin limitación de documentos devueltos, el motor de búsqueda necesitó examinar todos los 1.206.246 registros con coordenadas dentro del polígono, resultando en un tiempo promedio de 51.797 ± 377 ms. Este contraste evidencia que la utilización de `$geoWithin` debe ser acompañada de filtros adicionales o límites explícitos de retorno en aplicaciones que exigen baja latencia, ya que la búsqueda en grandes áreas, incluso con un índice, puede ser onerosa.

Experimento 8: Índice multiclave

El experimento 8 evaluó la eficacia del índice multikey para búsquedas en campos de tipo array. Se utilizó la colección `sample_mflix.movies` con el campo `genres`, que almacena un array con de uno a cinco géneros por película. Se realizaron 50 ejecuciones para cada género con y sin índice, además de consultas con el operador `$all` buscando múltiples elementos simultáneamente.

La ganancia proporcionada por el índice de claves múltiples dependió en gran medida de la selectividad del género buscado. Para “Western” (1,1% de la colección, 242 películas), el índice redujo el tiempo de 20 ms a 3 ms. Para “Romance” (15,5% de la colección, 3318 películas), la operación pasó de 19,4 ms a 6,3 ms. Este patrón confirma que el índice de claves múltiples opera bajo los mismos principios que el índice de campo único: crea entradas individuales para cada campo del array, de modo que cuanto menor sea la proporción de documentos cubiertos, mayor será el beneficio proporcionado por el índice en relación con el escaneo secuencial.

El límite del índice de claves múltiples se manifestó en géneros de alta selectividad. Para “Drama” (58% de la colección, 12.385 películas), el índice resultó en un tiempo promedio de 20,5 ms, ligeramente superior a los 18,6 ms sin índice. Este resultado refuerza el concepto de punto de inflexión observado en el experimento 3, ahora a escala reducida: para devolver muchos documentos, un COLLSCAN puede ser más ventajoso que un IXSCAN + fetch en algunos escenarios, lo que indica que la selectividad es un factor crítico incluso para índices de claves múltiples.

Experimento 9: Impacto de los índices en el rendimiento de escritura

El experimento 9 midió la relación entre el número de índices mantenidos por una colección y la latencia de las operaciones de escritura. Para aislar este efecto, se utilizó una colección temporal con documentos sintéticos en el formato de NYC 311. Se probaron escenarios con 0 a 5 índices adicionales al `_id` predeterminado, y para cada escenario se realizaron 30 inserciones en lote de 1000 documentos (insertMany) y 30 operaciones de actualización masiva (updateMany).

Los resultados confirmaron la relación de proporcionalidad directa entre el número de índices y la latencia de escritura descrita por Chopade y Pachghare (2020). Para operaciones de inserción, el tiempo promedio aumentó de 19,4 ± 1 ms (solo con el índice `_id`) a 32,3 ± 2,9 ms con 5 índices adicionales, un overhead acumulado del 66%. La tendencia lineal fue visible a lo largo de toda la curva. Para actualizaciones masivas, el patrón fue similar: de 135,7 ± 20,3 ms sin índices adicionales a 207,6 ± 50,1 ms con cinco índices, un overhead del 53%.

La tendencia observada justifica la recomendación de Chopade y Pachghare (2020) de consolidar índices compuestos que cumplan con múltiples patrones de consulta en lugar de mantener índices individuales superpuestos. Este enfoque tiene como objetivo minimizar el impacto en las operaciones de escritura sin comprometer el rendimiento de lectura, optimizando el uso de los recursos del servidor y garantizando la escalabilidad del sistema.

Experimento 10: Índice incompleto

El experimento 10 evaluó el índice parcial, que restringe su cobertura a un subconjunto de documentos de la colección de acuerdo con una expresión de filtro. Se comparó un índice completo en `complaint_type` y un índice parcial en el mismo campo con un filtro para abarcar solo documentos con estado “Open”, midiendo tanto el rendimiento de las consultas como el espacio de almacenamiento ocupado por cada índice.

El tamaño del índice parcial ocupó solo 0,42 MB frente a los 26,46 MB del índice completo, lo que representa un ahorro del 98,4%. Esta proporción refleja directamente la fracción de documentos que cumplen el filtro de estado en la colección (solo el 1,4% del total), ya que el índice parcial crea entradas solo para los documentos que satisfacen el filtro. En el panel de rendimiento, el comportamiento del índice parcial demostró ser preciso en la cobertura de su alcance. Para la consulta de estado “Open” con un filtro que no debe devolver ningún documento, el índice parcial completó la ejecución en aproximadamente 0 ms con ningún documento examinado.

La misma búsqueda sin un índice (COLLSCAN) necesitó 11.461 ± 1.329 ms para llegar a la misma conclusión después de escanear más de 5 millones de documentos. Para una consulta no cubierta por el índice, es decir, una búsqueda por estado “Closed”, los resultados con y sin índice fueron equivalentes, como se esperaba, dado que el índice no se aplicó por no cumplir el filtro. Este conjunto de resultados demuestra que el índice parcial es una herramienta de optimización altamente específica: proporciona una ganancia máxima para el subconjunto de documentos cubiertos, no crea costo de mantenimiento de operaciones de escritura fuera del filtro y ocupa una fracción menor del almacenamiento en comparación con el índice completo.

En resumen, los experimentos demostraron que la eficacia de la indexación en MongoDB está intrínsecamente ligada a la cardinalidad de los atributos, a la correcta aplicación de la regla del prefijo en índices compuestos y a la selectividad de las consultas, que define el punto de inflexión donde el beneficio del índice puede ser superado por el costo de escaneo secuencial. Las consultas cubiertas representan el ápice de la optimización, eliminando el acceso al disco, mientras que la caché de planes influye en el rendimiento transitorio. Sin embargo, la acumulación de índices eleva la latencia de escritura y la contención de recursos, y índices específicos como los de texto y geoespaciales, aunque potentes, demandan consideración de sus costos de almacenamiento y límites de aplicación. La planificación criteriosa de la distribución de los datos y de la configuración de los índices es, por lo tanto, fundamental para prevenir estrategias subóptimas del mecanismo de selección de planes de MongoDB y garantizar la escalabilidad.

4. Conclusión

Este estudio evaluó la influencia de la estructura y configuración de índices en el rendimiento de lectura y el costo operativo de escritura en bases de datos MongoDB. Se observó que los índices de campo único proporcionaron reducciones de tiempo de ejecución de casi el 100% para atributos de alta cardinalidad, aunque su eficacia se vio limitada en campos de baja cardinalidad debido a la selectividad. La regla del prefijo en índices compuestos demostró ser determinante, y se identificó un punto de inflexión donde el costo de búsqueda individual de documentos superaba el escaneo secuencial. Adicionalmente, se observó que las consultas cubiertas representan la cúspide de la optimización, eliminando la necesidad de acceso al disco. Los experimentos también revelaron el sesgo del mecanismo First Past The Post (FPTP) de MongoDB, que, al priorizar los primeros resultados, puede fijar planes subóptimos para consultas que devuelven grandes volúmenes de datos.

Por otro lado, la acumulación excesiva de índices elevó la latencia de escritura y la contención de recursos en el motor de almacenamiento, evidenciando un trade-off crucial. Índices específicos, como los de texto y geoespaciales, demostraron ser poderosos para sus propósitos, pero con costos de almacenamiento significativos, mientras que los índices parciales ofrecieron optimización dirigida y ahorro de espacio. La principal contribución de este trabajo reside en proporcionar una base sólida para la toma de decisiones en arquitecturas de datos de alto volumen, donde la optimización de consultas es estratégica. Se recomienda, por lo tanto, una planificación criteriosa de la distribución de los datos y de la configuración de los índices para mitigar los riesgos de estrategias subóptimas y garantizar la escalabilidad del sistema.

Referencias Bibliográficas

Chopade, R.; Pachghare, V. 2020. MongoDB Indexing for Performance Improvement. In: ICT Systems and Sustainability, 2020, Goa, Índia. Anais… p. 529-539.

data.cityofnewyork.us [Referência completa não encontrada no documento original]

Marat et al., 2024 [Referência completa não encontrada no documento original]

Tao, D.; Enqi, L.; Kadupitige, S. R.; Cahill, M.; Fekete, A.; Röhm, U. 2024. First past the post: evaluating query optimization in MongoDB. In: Australian Database Conference, 2024, Gold Coast, Australia. Anais… p. 99-113.

Artículo originario del Trabajo de Conclusión de Curso de la Especialización en Ingeniería de Software del MBA USP/Esalq

Para saber más sobre el curso, haga clic aquí y acceda a la plataforma MBX Academy