A Comparative Performance Evaluation of SQL and NoSQL Databases Under Different Indexing and Cache Conditions
Este estudio evalúa comparativamente MySQL 8.0.46 y MongoDB 8.0.32 a través de diversos tamaños de conjuntos de datos, estrategias de indexación y condiciones de caché, revelando que MongoDB sobresale en escrituras masivas mientras que ambos sistemas se benefician significativamente de la indexación para las búsquedas, demostrando finalmente que el rendimiento de la base de datos depende altamente del contexto en lugar de ser universalmente superior para cualquiera de los dos modelos.
Artículo original bajo licencia CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo
En el mundo digital, casi cada acción deja un rastro. Una compra, un inicio de sesión, un mensaje enviado—cada evento se almacena en una base de datos, un vasto archivador electrónico que contiene la memoria de la vida moderna. Para mantener estos sistemas funcionando sin problemas, los ingenieros deben elegir entre dos tipos principales de sistemas de archivo. Un tipo, conocido como relacional, organiza los datos en tablas rígidas con filas y columnas estrictas, muy parecido a una hoja de cálculo tradicional. El otro, llamado NoSQL, almacena la información como documentos flexibles y autónomos que pueden variar en forma y tamaño. Durante años, un debate ha fermentado sobre qué sistema es más rápido o mejor. La respuesta, sin embargo, rara vez es sencilla, porque la velocidad depende enteramente de lo que se le pida al sistema y de cuántos datos deba buscar.
Un estudio reciente se propuso resolver esta cuestión no con teoría, sino con un experimento controlado. Los investigadores Amir Khan, Sawaira Gull y Arooj Shahzadi construyeron un campo de pruebas en una sola computadora para ver cómo se desempeñaban dos sistemas populares, MySQL y MongoDB, bajo condiciones idénticas. No solo preguntaron cuál era más rápido; preguntaron cómo cambiaba la velocidad cuando la cantidad de datos crecía de un pequeño montón a una montaña masiva, y cómo el uso de índices—atajos especializados que ayudan al sistema a encontrar información rápidamente—alteraba los resultados. Probaron tres tareas específicas: volcar una gran cantidad de datos nuevos en el sistema, encontrar un único registro basado en un nombre específico y agrupar muchos registros para calcular un total.
Los investigadores comenzaron generando registros de transacciones sintéticas, creando tres conjuntos de datos separados que contenían diez mil, cien mil y un millón de entradas. Cargaron estos registros en ambos sistemas de bases de datos y midieron cuánto tiempo tomaba completar cada tarea. En la primera prueba, que consistía en escribir todos los datos en el sistema a la vez, el sistema basado en documentos, MongoDB, resultó ser consistentemente más rápido. Al manejar un millón de registros, terminó la tarea en aproximadamente doce segundos y medio, mientras que el sistema relacional, MySQL, tardó casi treinta segundos. Esta diferencia se mantuvo constante independientemente de si el conjunto de datos era pequeño o grande, lo que sugiere que para la pura ingestión de datos, el enfoque basado en documentos tenía una clara ventaja en esta configuración específica.
La segunda prueba se centró en encontrar un único registro, similar a buscar a un cliente específico por su número de ID. Aquí, los investigadores midieron el tiempo que tomaba encontrar un registro tanto sin ayuda como con la ayuda de un índice. Sin un índice, el sistema tenía que escanear cada uno de los registros para encontrar la coincidencia. A medida que los datos crecían a un millón de entradas, esta búsqueda se volvía dolorosamente lenta, tomando más de medio segundo en ambos sistemas. Sin embargo, una vez que los investigadores añadieron un índice de un solo campo—una lista simple que apunta directamente a la ubicación de cada ID—los resultados cambiaron drásticamente. El tiempo para encontrar el registro cayó a poco más de un milisegundo para ambos sistemas. Esta reducción, que superó el noventa y nueve por ciento, mostró que para búsquedas simples, el tipo de base de datos importaba mucho menos que la presencia de un buen mapa para guiar la búsqueda.
La tercera prueba fue más compleja, involucrando una agregación filtrada. Los investigadores pidieron al sistema que encontrara todas las transacciones en una categoría específica, las agrupara por su estado y sumara los montos totales. Esta tarea es más difícil porque requiere no solo encontrar datos, sino también clasificarlos y calcularlos. En este escenario, los resultados fueron menos uniformes. Para los conjuntos de datos más pequeños, el sistema relacional era a veces más rápido, pero a medida que los datos crecían a un millón de registros, el sistema basado en documentos tomaba la delantera significativamente. El sistema de documentos completó la tarea en unos trescientos milisegundos, mientras que el sistema relacional tardó más de un segundo.
Quizás el hallazgo más sorprendente surgió durante esta tercera prueba con el conjunto de datos más grande. Cuando los investigadores usaron un índice en el campo de categoría para acelerar el sistema relacional, la tarea se volvió en realidad más lenta que cuando no tenían ningún índice. El sistema tomó más de un segundo con el índice, comparado con aproximadamente setecientos milisegundos sin él. Este resultado contraintuitivo no fue un error; los investigadores repitieron la prueba de forma independiente y confirmaron que el índice efectivamente estaba causando un retraso en esta configuración específica. Parece que para este tipo particular de cálculo complejo, la carga adicional de usar el índice superaba sus beneficios, un matiz que una conclusión simple de "uno es más rápido que el otro" pasaría por alto.
El estudio también examinó cómo se comportaban los sistemas cuando ya estaban "calientes", lo que significa que habían procesado solicitudes similares recientemente y tenían datos listos en su memoria. En estas condiciones, ambos sistemas se volvieron más rápidos, pero el grado de mejora varió. El sistema de documentos experimentó un aumento significativo en su velocidad de agregación cuando estaba caliente, mientras que el sistema relacional mostró una ganancia más modesta. Estos hallazgos refuerzan que el rendimiento no es una propiedad fija del software en sí, sino un resultado fluido de la interacción entre el tamaño de los datos, el tipo de consulta, la presencia de índices y el estado actual de la memoria del sistema.
En última instancia, la investigación concluye que no hay un ganador universal. La elección entre estos dos modelos de base de datos no puede hacerse basándose en una sola prueba de velocidad. Si el objetivo es ingerir rápidamente cantidades masivas de datos nuevos, el sistema basado en documentos mostró una ventaja distintiva. Si el objetivo es recuperar un único registro, ambos sistemas funcionan igual de bien siempre que haya un índice adecuado en su lugar. Sin embargo, para cálculos complejos que involucran grandes volúmenes de datos, el rendimiento puede oscilar dependiendo de cómo se estructuren e indexen los datos. El estudio sirve como un recordatorio de que en el mundo de los datos, la herramienta adecuada depende enteramente del trabajo específico que se deba realizar, y que el camino más eficiente a menudo se encuentra no eligiendo una marca, sino comprendiendo la forma única del trabajo a realizar.
¿Ahogado en artículos de tu campo?
Recibe resúmenes diarios de los artículos más novedosos que coincidan con tus palabras clave de investigación — con resúmenes técnicos, en tu idioma.