Para completar los resultados de los tests anteriores hemos hecho nuevos tests y probado también a usar varias máquinas de MongoDB en Sharding. El sharding es algo muy similar al particionamiento horizontal para bases de datos tradicionales.

En este caso nos encontramos con problemas a la hora de usar Apache JMeter (teníamos como respuesta demasiados errores). Desconozco si se debió a un problema de red o de la propia herramienta, pero bueno, decidimos usar le herramienta HP LoadRunner (a mi pesar), que es la que usamos internamente para hacer tests de carga.

Lo más interesante a la hora de utilizar Sharding es configurar la repartición de los datos previamente con Tag Aware Sharding, en vez de dejar que sea MongoDB el que automáticamente distribuya los datos entre los nodos. De esta forma conseguiremos ganar también rendimiento en las operaciones de inserción.

Resultados de los tests

Un resumen de los tests mas significativos sería el siguiente

Tests simples de lectura

Tests simples de escritura (inserción de registros)

Aquí ejecutamos scripts sencillos que escriben un registro detrás de otro

Tests simples de escritura (sin y con Sharding)

MongoDB con sharding en 2 nodos

La idea es repartir las entradas repartiéndolas por ID (entre 2 y 4 máquinas). En nuestro caso se indicó a los repartidores (o “routers”) de mongo los rangos de ID’s que correspondían a cada nodo.

Si no lo hubiéramos hecho así la inserción no hubiera ido mejor que con un sólo nodo de MongoDB, ya que el reparto lo hace a posteriori, e inicialmente todos o la mayor parte de las inserciones hubieran sido almacendas en el primero de los nodos.

Para estos tests en vez de entradas de logs como en los anteriores hemos inventado documentos mucho más sencillos (id, pais y dato)

Tests de lectura multiusuario (50 usuarios)

En estos dos tests y el siguiente ejecutamos los scripts sobre una base de datos con 30 millones de entradas de log

Mostramos los totales para un dominio escogido al azar

Mostramos todas las entradas en el log para un dominio

Tests de lectura y escritura multiusuario (50 usuarios)

Aquí combinamos lecturas, buscando los datos de un dominio por id, y escrituras, añadiendo una entrada predefinida a la colección que almacena los logs.

80% de lecturas y +20% de escrituras

Conclusiones

Combinando lo obtenido en el y el resultado de los nuevos tets podemos decir:

Rendimiento en lectura

• MongoDB es más rápido en operaciones simples de lectura
• En múltiples lecturas sencillas consecutivas MongoDB es mucho más rápido que MySQL
• En concreto en búsquedas por id de un sólo documento MongoDB ha más que duplicado el rendimiento con respecto a MySQL
• Para búsquedas por una condición (lo que sería una consulta WHERE en SQL) MongoDB ha sido un 250% más rápido que MySQL (buscando todos los registros para un campo de texto con un valor concreto). Con sharding el rendimiento aumenta considerablemente

Funciones de agregación

• Para consultas de agregación MySQL supera a framework nativo de MongoDB. MySQL es mucho más rápido obteniendo datos agregados, de 3 a 6 veces más rápido en los tests que hemos realizado

Rendimiento en escritura

• El rendimiento en escritura de MongoDB ha sido superior en todos nuestros tests
• En escrituras simples consecutivas ha sido entre 2 y 4 veces más rápido
• En lecturas concurrentes MongoDB es más rápido (entre un 15% y un 40% en nuestras pruebas con 50 usuarios)
• Añadir máquinas no produce un aumento del rendimiento en escritura si no se definen reglas de reparto previamente con Tag Aware Sharding
• En caso de definir estas reglas de reparto el rendimiento se multiplica por el número de máquinas usado

Observaciones

• MongoDB es más escalable, lo que significa que cuando la carga de usuarios aumenta el tiempo de respuesta se mantiene estable
• MongoDB es muy flexible. La posibilidad de añadir máquinas (shards) de forma transparente a las aplicaciones nos da una gran flexibildiad a la hora de definir arquitecturas hardware
• El establecimiento de buenas reglas de repartición (y por tanto de conocer cuáles son los patrones de acceso de la aplicación) es fundamental. El papel del DBA y una buena comunicación con los desarrolladores es muy importante

Ver también

El resto de esta serie de artículos

• MongoDB vs MySQL: Inserción de datos
• MongoDB vs MySQL: Tests de lectura multiusuario
• MongoDB vs MySQL: Tests de escritura multiusuario
• MongoDB vs MySQL: Tests de lectura y escritura combinados
• MongoDB vs MySQL: Funciones de agregación
• Comparativa MongoDB vs MySQL: Conclusiones (primera parte)