MongoDB no es mágicamente más rápido. Si almacena los mismos datos, organizados básicamente de la misma manera y accede a ellos exactamente de la misma manera, entonces no debería esperar que sus resultados sean muy diferentes. Después de todo, MySQL y MongoDB son GPL, por lo que si Mongo tuviera un código IO mágicamente mejor, entonces el equipo de MySQL podría simplemente incorporarlo a su base de código.
La gente está viendo el rendimiento real de MongoDB en gran parte porque MongoDB le permite consultar de una manera diferente que es más sensible a su carga de trabajo.
Por ejemplo, considere un diseño que conserva mucha información sobre una entidad complicada de manera normalizada. Esto podría usar fácilmente docenas de tablas en MySQL (o cualquier base de datos relacional) para almacenar los datos en forma normal, con muchos índices necesarios para garantizar la integridad relacional entre las tablas.
Ahora considere el mismo diseño con un almacén de documentos. Si todas esas tablas relacionadas están subordinadas a la tabla principal (y a menudo lo están), entonces podría modelar los datos de modo que toda la entidad se almacene en un solo documento. En MongoDB puede almacenar esto como un solo documento, en una sola colección. Aquí es donde MongoDB comienza a permitir un rendimiento superior.
En MongoDB, para recuperar la entidad completa, debe realizar:
- Una búsqueda de índice en la colección (suponiendo que la entidad se busca por id)
- Recuperar el contenido de una página de la base de datos (el documento json binario real)
Entonces, una búsqueda de árbol b y una lectura de página binaria. Log(n) + 1 E/S. Si los índices pueden residir completamente en la memoria, entonces 1 IO.
En MySQL con 20 tablas, debe realizar:
- Una búsqueda de índice en la tabla raíz (nuevamente, asumiendo que la entidad es obtenida por id)
- Con un índice agrupado, podemos suponer que los valores de la fila raíz están en el índice
- Más de 20 búsquedas de rango (con suerte en un índice) para el valor pk de la entidad
- Estos probablemente no sean índices agrupados, por lo que las mismas más de 20 búsquedas de datos una vez que averigüemos cuáles son las filas secundarias apropiadas.
Entonces, el total para mysql, incluso suponiendo que todos los índices están en la memoria (lo cual es más difícil ya que hay 20 veces más) es de aproximadamente 20 búsquedas de rango.
Es probable que estas búsquedas de rango se compongan de E/S aleatorias:las diferentes tablas residirán definitivamente en diferentes lugares del disco, y es posible que las diferentes filas en el mismo rango en la misma tabla para una entidad no sean contiguas (dependiendo de cómo se haya realizado la entidad). actualizado, etc.).
Entonces, para este ejemplo, la cuenta final es aproximadamente 20 veces más IO con MySQL por acceso lógico, en comparación con MongoDB.
Así es como MongoDB puede aumentar el rendimiento en algunos casos de uso .
