ventajas relacionales funciona desventajas como sql mongodb performance nosql

relacionales - ¿Alguna razón detallada y específica de por qué MongoDB es mucho más rápido que SQL DB?



mongodb vs sql server (3)

En general, MySQL y MongoDB son bastante similares en el rendimiento de escritura "duradera" en una sola máquina. Las búsquedas simples de clave / valor son casi las mismas ... si desea usar MySQL de esa manera. El soporte de documentos es, obviamente, un gran beneficio de productividad y una gran ganancia para el rendimiento.

Con sharding automático ... MongoDB es más rápido de manera indescriptible. Fuera de la caja, con un diseño adecuado, puede escalar casi linealmente sin crear ninguna lógica en su código en absoluto.

La división de lectura / escritura también está integrada en casi todos los controladores ... que, en su mayoría, son patrocinados o desarrollados por 10gen.

He escalado aplicaciones antes y he escrito código de división de lectura / escritura, hashes distribuidos para fragmentación, reequilibrio de trabajos que se ejecutan continuamente y he agregado gzip a las tiendas de "documentos" de mysql. ugh.

Es más rápido porque es simple y enfocado. Está diseñado con todo esto en mente. La escala en el hardware básico es una prioridad. Las prioridades de un RDBMS son bastante diferentes.

Ok, hay preguntas sobre por qué es tan rápido MongoDB

Aprecio esas respuestas, sin embargo, son bastante generales. Sí, lo sé:

  • MongoDB está basado en documentos, entonces ¿por qué estar basado en documentos puede conducir a una velocidad mucho mayor?
  • MongoDB no es SQL, pero ¿por qué noSQL significa un mayor rendimiento?
  • SQL hace mucho más que MongoDB por coherencia, ACID, etc., pero creo que MongoDB también está haciendo algo similar para mantener la seguridad de los datos, mantener la indexación, etc., ¿verdad?

Ok, escribo esta pregunta solo para descubrir

  1. ¿Cuáles son las razones detalladas y específicas para el alto rendimiento de MongoDB?
  2. ¿Qué es exactamente SQL, pero MongoDB no funciona, por lo que gana un rendimiento muy alto?
  3. Si un entrevistador (un experto en MongoDB y SQL) le pregunta "Why MongoDB is so fast" , ¿Cómo respondería? Obviamente solo responder: "because MongoDB is noSQL" no es suficiente.

Gracias


Primero, comparemos manzanas con manzanas: las lecturas y escrituras con MongoDB son como lecturas únicas y escrituras por clave principal en una tabla sin índices no agrupados en un RDBMS.

Así que comparemos exactamente eso: http://mysqlha.blogspot.de/2010/09/mysql-versus-mongodb-yet-another-silly.html

Y resulta que la diferencia de velocidad en una comparación justa de exactamente la misma operación primitiva no es grande. De hecho, MySQL es un poco más rápido. Yo diría que son equivalentes.

¿Por qué? Porque en realidad, ambos sistemas están haciendo cosas similares en este punto de referencia particular. Devolver una sola fila, buscada por clave principal, en realidad no es tanto trabajo. Es una operación muy rápida. Sospecho que los gastos generales de comunicación entre procesos son una gran parte de eso.

Mi suposición es que el código más ajustado en MySQL supera los gastos generales ligeramente menos sistemáticos de MongoDB (sin bloqueos lógicos y probablemente algunas otras cosas pequeñas).

Esto lleva a una conclusión interesante: puede usar MySQL como una base de datos de documentos y obtener un excelente rendimiento de ella.

Si el entrevistador dijo: "No nos importan los documentos o los estilos, solo necesitamos una base de datos mucho más rápida, ¿cree que deberíamos usar MySQL o MongoDB?", ¿Qué respondería?

Recomiendo ignorar el rendimiento por un momento y ver la fortaleza relativa de los dos sistemas. Cosas como escalamiento (ascendente) y replicación vienen a la mente para MongoDB. Para MySQL, hay muchas más funciones, como consultas enriquecidas, modelos de concurrencia, mejores herramientas y madurez, y mucho más.

Básicamente, puede intercambiar funciones por rendimiento. ¿Estás dispuesto a hacer eso? Esa es una elección que no se puede hacer en general. Si opta por el rendimiento a cualquier costo, considere ajustar MySQL primero antes de agregar otra tecnología.

Esto es lo que sucede cuando un cliente recupera una sola fila / documento por clave principal. Anotaré las diferencias entre ambos sistemas:

  1. El cliente crea un comando binario (lo mismo)
  2. El cliente lo envía a través de TCP (lo mismo)
  3. El servidor analiza el comando (mismo)
  4. El servidor accede al plan de consulta desde la memoria caché (solo SQL, no MongoDB, no HandlerSocket)
  5. El servidor le pide al componente B-Tree que acceda a la fila (mismo)
  6. El servidor toma un bloqueo de solo lectura físico en la ruta B-Tree que lleva a la fila (mismo)
  7. El servidor toma un bloqueo lógico en la fila (solo SQL, no MongoDB, no HandlerSocket)
  8. El servidor serializa la fila y la envía a través de TCP (lo mismo)
  9. El cliente lo deserializa (lo mismo)

Solo hay dos pasos adicionales para RDBMS''es de bases de SQL típicas. Es por eso que no hay realmente una diferencia.


por defecto, mongo no hace ninguna indexación; tampoco hay transacciones sin embargo, si configura una tabla mysql para que no esté indexada y activa el compromiso automático, no verá una gran diferencia de velocidad. escribir bits en el disco solo lleva una cierta cantidad de tiempo.

sin embargo, mongo está diseñado para escalar fácilmente. utilizando fragmentos, puede escalar horizontalmente sus escrituras y obtener un rendimiento mucho mejor sin la complejidad de la replicación maestro-maestro. utilizando conjuntos de réplicas, puede escalar sus lecturas horizontalmente. entonces, diría que hay una mejora sistémica en el rendimiento, pero cada consulta no es necesariamente más rápida.