¿Por qué NoSQL es más rápido que SQL?

48

Recientemente me preguntaron:

¿Por qué NoSQL es más rápido que SQL?

No estaba de acuerdo con la premisa de la pregunta ... es una tontería para mí personalmente. No puedo ver ningún aumento en el rendimiento al usar NoSQL en lugar de SQL. Tal vez SQL sobre NoSQL, sí, pero no de esa manera.

¿Me estoy perdiendo algo sobre NoSQL?

performance nosql

— cnd
fuente

3

Si no puede ver un aumento en el rendimiento, eso es lo que dice. El hecho es que la mayoría de las soluciones NoSQL renuncian a una (o más) de las propiedades ACID de una base de datos relacional, por lo que hacen menos.

— Oded

1

Hay algunos flujos de trabajo (y estructuras de datos) que no pueden asignarse fácilmente a una base de datos relacional tradicional habilitada para ACID. Para aquellos, puede ver grandes aumentos de rendimiento al usar una base de datos NoSQL. Sin embargo, si simplemente toma una base de datos SQL existente (bien diseñada) y la coloca en una base de datos NoSQL, su rendimiento seguramente se verá afectado .

— Joachim Sauer

1

La respuesta es: ¿Se ha establecido como más rápido? ¿Y más rápido en qué? ¿Tiempo de desarrollo? ¿Tiempo de lectura? Escribir tiempo? ¿Qué tipo de escritura? ¿Con qué lo estamos comparando? Consultas de varias mesas? ¿Uniones?

— Rolf

65

Existen muchas soluciones NoSQL, cada una con sus propias fortalezas y debilidades, por lo que las siguientes deben tomarse con un grano de sal.

Pero, esencialmente, lo que hacen muchas bases de datos NoSQL es confiar en la desnormalización e intentar optimizar para el caso desnormalizado. Por ejemplo, supongamos que está leyendo una publicación de blog junto con sus comentarios en una base de datos orientada a documentos. A menudo, los comentarios se guardarán junto con la publicación misma. Esto significa que será más rápido recuperarlos todos juntos, ya que están almacenados en el mismo lugar y no tiene que realizar una unión.

Por supuesto, puede hacer lo mismo en SQL, y la desnormalización es una práctica común cuando se necesita rendimiento. Es solo que muchas soluciones NoSQL están diseñadas desde el principio para usarse siempre de esta manera. Luego obtienes las compensaciones habituales: por ejemplo, agregar un comentario en el ejemplo anterior será más lento porque tienes que guardar todo el documento con él. Y una vez que se haya desnormalizado, debe cuidar la integridad de los datos en su aplicación.

Además, en muchas soluciones NoSQL, es imposible hacer uniones arbitrarias, por lo tanto, consultas arbitrarias. Algunas bases de datos, como CouchDB, requieren que piense antes de las consultas que necesitará y que las prepare dentro de la base de datos.

Con todo, todo se reduce a esperar un esquema desnormalizado y optimizar las lecturas para esa situación, y esto funciona bien para datos que no son altamente relacionales y que requieren muchas más lecturas que escrituras.

— Andrea
fuente

44

Esto, por cierto, se puede realizar con una vista materializada simple o una capa de caché, mientras se beneficia de toda la bondad de SQL. Todo lo que se modela correctamente es relacional, y la duplicación lógica de datos no es una solución (la vista mat. Es una duplicación pero no una duplicación lógica porque es simplemente una imagen de otra cosa).

— Morg

Como he dicho en la respuesta, uno puede hacer lo mismo en SQL; es solo que cuando esto se convierte en la regla en lugar de la excepción, las bases de datos NoSQL suelen ser más rápidas y más naturales de usar. En teoría, SQL es el mejor modelo que uno puede usar, pero cuando los datos crecen más de un cierto tamaño, simplemente no puede acomodar algunos modelos, y la duplicación de datos se vuelve más rápida y fácil de razonar.

— Andrea

3

Eso es toro El modelo relacional cubre todo lo que puede hacer en NoSQL y mucho más. La única ventaja de NoSQL es que un enfoque simple e inconsistente para el escalado está integrado y es fácil de usar. No tiene nada que ver con SQL, y todo lo que tiene que ver con no preocuparse por las propiedades ACID. Puede tener trabajos de sincronización entre nodos SQL independientes que tendrán exactamente las mismas (muy malas) propiedades de escala y consistencia que tienen las tiendas NoSQL. La diferencia es que los nodos SQL TAMBIÉN pueden tener coherencia si así lo desea.

— Morg

1

¿Qué sucede si tiene 5,000,000 millones de filas de datos y desea obtener el comentario de todos ellos por alguna condición? ¿No sería más rápido si tuviera un índice en el campo de comentarios de la tabla con SQL? La indexación de texto completo mejoraría aún más esto.

— jwize

@morg - "El modelo relacional cubre todo lo que puedes hacer en NoSQL y mucho más". No, realmente no. Hay muchos ejemplos de tipos de datos que se ajustan tan mal al modelo relacional que obligar a los datos a generar una ineficiencia masiva. Ejemplo: un juego en línea tiene una facilidad para almacenar el inventario de los jugadores. Los jugadores tienen un conjunto finito de ranuras numeradas, cada una de las cuales puede almacenar uno o más elementos de un tipo específico. Hay alrededor de 50 tipos diferentes de elementos, cada uno de los cuales tiene 4-6 atributos asociados, con cierta superposición, por lo que hay alrededor de 80 atributos posibles ...

— Jules

27

Lo que falta de NoSQL es que NoSQl no se puede comparar con SQL de ninguna manera. NoSQL es el nombre de todas las tecnologías de persistencia que no son SQL. Las bases de datos de documentos, las bases de datos de valores clave y las bases de datos de eventos son todas NoSQL. Todos son diferentes en casi todos los aspectos, ya sea la estructura de los datos guardados, las consultas, el rendimiento y las herramientas disponibles.

Entonces, si alguien le hace esa pregunta en una entrevista, esta debería ser la respuesta.

— Eufórico
fuente

44

Si hay una característica asesina de NoSQL, diría que ES la escalabilidad. Es por eso que los usan Facebook y Google. Debido al volumen gigantesco de datos. NoSQL: cuando tienes que lidiar con enormes cantidades de datos.

— Pieter B

16

Las bases de datos 'NoSQL' (o más precisamente: no relacionales) renuncian a algunas características de las bases de datos tradicionales para la velocidad, pero más importante aún para la escalabilidad horizontal.

Las características que faltan dependen del producto concreto, en general no se admiten las propiedades completas de ACID o incluso las operaciones de unión. Ese es el precio por el mayor rendimiento.

— Karl
fuente

1

Describir NoSQL como no relacional no es más preciso. Hay otras bases de datos no relacionales antiguas que no entran en la categoría NoSQL. NoSQL significa mucho más que simplemente no relacional. Lea esto para obtener más información: martinfowler.com/bliki/NosqlDefinition.html

— eddyP23

8

Tienes razón, sería una tontería decir eso en una declaración general. Cuál es probablemente el punto completo; en lugar de una sola respuesta, el entrevistador probablemente espera que responda con preguntas para ayudarlo a descubrir cuál es el contexto del problema (qué tipo de datos, qué cantidad, en qué entorno operativo, etc.), la solución NoSQL particular . Intentarán descubrir cómo analizar los problemas y, en el camino, hacerse una idea de cuánto sabe sobre las diferentes soluciones que existen.

— Eelco
fuente

Sí, es una declaración general, y si aceptamos que es verdad, la respuesta a la pregunta es: depende.

— Rolf

5

Las bases de datos NoSQL normalmente solo tienen sentido si diseñas tus datos a su alrededor.

Si tiene la intención de usarlos simplemente como un reemplazo RDBMS, entonces podría obtener menos rendimiento en lugar de más, especialmente si no tiene el presupuesto suficiente para pagar por servidores con grandes cantidades de RAM.

Mire este artículo que compara el uso del espacio en disco MySQL con el de MongoDB: http://blog.trackerbird.com/content/mysql-vs-mongodb-disk-space-usage

— Clifford
fuente

3

¿Qué base de datos NoSQL? ¿Qué base de datos SQL? Si alguien le dice que NoSQL es más rápido que SQL, entonces debe retirarse. O mejor aún, mira este video:

http://www.youtube.com/watch?v=b2F-DItXtZs

No diré que la mitad de las cosas afirmadas sobre NoSQL están mal, pero sí diré que hay mucho fanboyism de NoSQL por parte de personas que realmente no lo entienden muy bien.

SQL tiene sus límites (por supuesto), pero también es una tecnología muy madura, que se entiende bien, y tiene un gran grupo de desarrolladores que entienden cómo usarlo bien. No puedo decir lo mismo para todas las formas de NoSQL.

— Zachary K
fuente

-2

NoSql es compatible con bases de datos orientadas a columnas donde RDBMS es una base de datos orientada a filas ... Y digamos, por ejemplo, que tenemos una tabla de Empleados con Nombre, Edad, Salery, Dirección, Id. De empleado, etc ... ponemos la misma tabla en MySql (soporte RDBMS) y HBase (Soporte NoSQL). Si un cliente / cliente escribe una consulta para obtener la edad promedio o los detalles de Salery de los registros de los empleados de 1Lakh ... ¿qué sucede?

En RDBMS recorrerá cada fila y recogerá el valor y sumará y dividirá el resultado. Cuando se trata de la base de datos Columnar, no hay que preocuparse por todas las iteraciones de una fila de lakh. Pero trate solo con una fila que sea más rápida de calcular. Así, a veces, NoSQL es más rápido que SQL. Este caso NoSQL no se preocupa por las quejas de ACID valen la pena!

— kiran teja avvaru
fuente

2

He arreglado un poco el formateo, aunque no estoy seguro de lo que intentas conseguir entre los dos. Y ACID tampoco siempre es compatible con RDBMS.

-3

Olvídese de la teoría sobre bases de datos ... el punto una vez que comprende sus consultas, puede guardar datos en bases de datos nosql de una manera exacta en la que realmente se utilizan en su aplicación ...

Por ejemplo, tome este ejemplo, tiene un modelo de cliente con muchos pedidos y muchos artículos asociados con cada pedido, entonces también tienen muchos artículos guardados para compras posteriores ... si es una gran tienda de comercio electrónico con 10 millones de clientes y 50 millones de pedidos Y ese cliente inicia sesión en su panel de control que muestra estos datos exactos, cuánto trabajo necesitará una base de datos SQL para encontrar al cliente, unir los pedidos y cada línea de pedido y artículos guardados. En una base de datos sql, todos estos datos probablemente deban unirse de alguna manera ... o puede crear una colección en su base de datos llamada usercache y guardar estos datos exactamente como los usa en la vida real. Entonces, esto puede ser realmente una sola consulta en un solo campo [id] para recuperar todos estos datos. Además de eso, la base de datos nosql no

Entonces, ¿puede un sql db consultar un solo campo Id igual de rápido si no más rápido que nosql? Sí, pero ¿puede una base de datos SQL devolver todos los datos que necesita al consultar una tabla y un campo? No, a menos que haga algo como guardar los datos en Json dentro de un campo de texto grande. Pero ahora esos datos no se pueden consultar para un posible uso futuro.

— Steffan Perry
fuente