¿Por qué las bases de datos noSQL son más escalables que SQL?

100

Recientemente leí mucho sobre los DBMS noSQL. Entiendo el teorema CAP , las reglas ACID , las reglas BASE y la teoría básica. ¿Pero no encontró ningún recurso sobre por qué noSQL es escalable más fácilmente que RDBMS (por ejemplo, en el caso de un sistema que requiere muchos servidores DB)?

Supongo que mantener las restricciones y las claves externas cuestan recursos y cuando se distribuye un DBMS, es mucho más complicado. Pero espero que haya mucho más que esto.

¿Alguien puede explicar cómo noSQL / SQL afecta la escalabilidad?

ducin
fuente
77
"Supongo que mantener las restricciones y las claves externas cuestan recursos y cuando se distribuye un DBMS, es mucho más complicado. Pero espero que haya mucho más que esto". - En realidad, eso es. Más exactamente, esa es la característica común que hace que la mayoría de las soluciones NoSQL sean más escalables que sus primos SQL (para ciertos modelos de datos). Pero NoSQL es un término extremadamente vago, las diferentes familias de bases de datos NoSQL tienen diferentes características que las hacen más escalables.
Yannis
8
Por supuesto, las bases de datos SQL se adaptan perfectamente a billones de registros, solo necesitan algo de experiencia para diseñarlas y configurarlas que los desarrolladores de aplicaciones no tienen. Y, en general, un conjunto bastante costoso de hardware y licencias.
HLGEM
66
En mi opinión, esta pregunta no es un duplicado de ninguno de esos. La pregunta mongodb es (además de un mal título que lo hace parecer más específico) preguntar algo más que, de hecho, es más general. Votado para volver a abrir.
Joeri Sebrechts

Respuestas:

79

Las bases de datos noSQL ofrecen una gran cantidad de funcionalidades que una base de datos SQL le brinda por su propia naturaleza.

Cosas como la aplicación automática de integridad referencial, transacciones, etc. Estas son todas las cosas que son muy útiles para algunos problemas, y que requieren algunas técnicas interesantes para escalar fuera de un solo servidor (piense en lo que sucede si necesita bloquear dos tablas para una transacción atómica, ¡y están en diferentes servidores!).

Las bases de datos noSQL no tienen todo eso. Si necesita esas cosas, debe hacerlo usted mismo, pero si NO las necesita (y hay muchas aplicaciones que no las necesitan), entonces qué suerte tiene. La base de datos no tiene que hacer todas estas operaciones complejas y bloquear gran parte del conjunto de datos, por lo que es realmente fácil particionarlo en muchos servidores / discos / lo que sea y hacer que funcione realmente rápido.

Michael Kohne
fuente
2
No sabía que era así de simple
Abdul el
77
esta respuesta aceptada no menciona la capacidad de fragmentación de NoSQL que falta en SQL. Sharding es lo que hace que NoSQL sea escalable horizontalmente.
hyankov
8
@HristoYankov Y funciona porque el sistema NoSQL no hace todas las cosas que no funcionan bien con el fragmentación.
Immibis
1
@HristoYankov: la base de datos SQL se puede fragmentar horizontalmente, y no todas las bases de datos NoSQL se pueden fragmentar horizontalmente fácilmente. Sharding no es realmente la razón por la que quieres usar NoSQL.
Mentira Ryan
@HristoYankov La respuesta aceptada va un nivel más profundo que su nota de "no mencionar por completo la capacidad de fragmentación NoSQL que falta en SQL". La respuesta aceptada, con razón, habla de POR QUÉ el fragmentación horizontal es más difícil con las bases de datos SQL. De hecho, pasé unos buenos 20 minutos buscando la respuesta a esto y casi todos simplemente lanzan los "fragmentos de NoSQL mejor", sin mencionar ninguna razón. Respuesta totalmente inútil. Las respuestas aceptadas aquí responden la pregunta perfectamente, aunque muy brevemente. Sería bueno tener más razones enumeradas también.
Phoeniyx
176

No se trata de NoSQL vs SQL, se trata de BASE vs ACID.

Escalable tiene que desglosarse en sus componentes:

  • Escalado de lectura = manejar mayores volúmenes de operaciones de lectura
  • Escala de escritura = manejar mayores volúmenes de operaciones de escritura

Las bases de datos compatibles con ACID (como los RDBMS tradicionales) pueden escalar las lecturas. No son inherentemente menos eficientes que las bases de datos NoSQL porque los (posibles) cuellos de botella de rendimiento son introducidos por cosas que NoSQL (a veces) carece (como uniones y restricciones) que puede optar por no usar. SQL RDBMS en clúster puede escalar las lecturas mediante la introducción de nodos adicionales en el clúster. Existen restricciones sobre hasta qué punto se pueden escalar las operaciones de lectura, pero éstas están impuestas por la dificultad de ampliar las escrituras a medida que introduce más nodos en el clúster.

La escala de escritura es donde las cosas se ponen difíciles. Hay varias restricciones impuestas por el principio ACID que no se ven en arquitecturas eventualmente consistentes (BASE):

  • Atomicidad significa que las transacciones deben completarse o fallar en su conjunto, por lo que se debe hacer una gran cantidad de contabilidad detrás de escena para garantizar esto.
  • Las restricciones de consistencia significan que todos los nodos en el clúster deben ser idénticos. Si escribe en un nodo, esta escritura debe copiarse en todos los demás nodos antes de devolver una respuesta al cliente. Esto hace que un clúster RDBMS tradicional sea difícil de escalar.
  • Las restricciones de durabilidad significan que para nunca perder una escritura, debe asegurarse de que antes de devolver una respuesta al cliente, la escritura se haya vaciado al disco.

Para ampliar las operaciones de escritura o el número de nodos en un clúster más allá de cierto punto, debe poder relajar algunos de los requisitos de ACID:

  • Soltar Atomicity le permite acortar la duración durante la cual las tablas (conjuntos de datos) están bloqueadas. Ejemplo: MongoDB, CouchDB.
  • La reducción de la consistencia le permite escalar las escrituras en los nodos del clúster. Ejemplos: riak, cassandra.
  • Dropping Durability le permite responder a los comandos de escritura sin vaciar el disco. Ejemplos: memcache, redis.

Las bases de datos NoSQL suelen seguir el modelo BASE en lugar del modelo ACID. Renuncian a los requisitos A, C y / o D y, a cambio, mejoran la escalabilidad. Algunos, como Cassandra, le permiten optar por las garantías de ACID cuando las necesita. Sin embargo, no todas las bases de datos NoSQL son más escalables todo el tiempo.

La API SQL carece de un mecanismo para describir consultas donde los requisitos de ACID se relajan. Es por eso que las bases de datos BASE son todas NoSQL.

Nota personal: un punto final que me gustaría destacar es que la mayoría de los casos en los que NoSQL se está utilizando actualmente para mejorar el rendimiento, una solución sería posible en un RDBMS adecuado mediante el uso de un esquema correctamente normalizado con índices adecuados. Como lo demuestra este mismo sitio (impulsado por MS SQL Server), los RDBMS pueden escalar a altas cargas de trabajo, si los usa adecuadamente. Las personas que no entienden cómo optimizar los RDBMS deben mantenerse alejados de NoSQL, porque no entienden qué riesgos están tomando con sus datos.

Actualización (2019-09-17):

El panorama de las bases de datos ha evolucionado desde la publicación de esta respuesta. Si bien aún existe la dicotomía entre el mundo RDBMS ACID y el mundo NoSQL BASE, la línea se ha vuelto más difusa. Las bases de datos NoSQL han estado agregando características del mundo RDBMS como API de SQL y soporte de transacciones. Ahora incluso hay bases de datos que prometen SQL, ACID y escalado de escritura, como Google Cloud Spanner, YugabyteDB o CockroachDB. Por lo general, el diablo está en los detalles, pero para la mayoría de los propósitos estos son "suficientemente ACID". Para una inmersión más profunda en la tecnología de bases de datos y cómo ha evolucionado, puede echar un vistazo a esta presentación de diapositivas (las notas de la diapositiva tienen la explicación que la acompaña).

Joeri Sebrechts
fuente
Si bien estoy de acuerdo en que algunas tiendas NoSQL reemplazan ACID con BASE, eso todavía no es una característica común para todas las tiendas que caen en la "categoría" NoSQL, que está mal definida en primer lugar. Después de un tiempo, la interpretación del término cambió de "No SQL" a "No solo SQL", pero como muchas de estas bases de datos todavía se unen o han comenzado a implementar dialectos SQLesque, Mark Madsen ha vuelto a acuñar el término para que signifique algo más en su historial de bases de datos en no-tation : "No, SQL" ;-)
Lukas Eder
2
Para evitar uniones, tendremos datos des-normalizados en NoSQL que conducen a la repetición y más almacenamiento. Pero entonces se puede lograr lo mismo en RDBMS si estamos de acuerdo con la desnormalización. Entonces "Unirse" o "no unirse" depende del DBA y no del tipo de base de datos. Correcto?
Kaushik Lele
2
@dynamic Esos sitios usan el almacenamiento en caché pesado o se fragmentan. Esos diseños colocan la complejidad de escalar los datos fuera de la base de datos. También podría usar nosql en tal caso, porque esa es exactamente la compensación que hace nosql.
Joeri Sebrechts
1
"La API SQL carece de un mecanismo para describir consultas donde los requisitos de ACID se relajan". Técnicamente cierto, pero el servidor SQL ha dado un paso tímido en esa dirección. SQL 2014 presenta la durabilidad retardada, relajando la D en ACID, a cambio de reducir la presión del registro de escritura.
EBarr
3
Esta debería ser la respuesta aceptada de la OMI. Es muy claro con ejemplos, pero logra ser conciso.
Olshansk
4

Es cierto que las bases de datos NoSQL (MongoDB, Redis, Riak, Memcached, etc.) no mantienen restricciones de clave externa, y las operaciones atómicas deben especificarse más explícitamente. También es cierto que las bases de datos SQL (SQL Server, Oracle, PostgreSQL, etc.) pueden escalarse para manejar requisitos de rendimiento muy grandes por parte de DBA experimentados.

Las bases de datos NoSQL permiten a los programadores experimentados, que conocen bien las condiciones de carrera y las operaciones atómicas, renunciar a una gran cantidad de procesamiento que solo se requiere en un pequeño porcentaje del código de la aplicación web actual. Las bases de datos NoSQL ciertamente tienen operaciones atómicas y la mayoría de los requisitos transaccionales presentes en las bases de datos SQL también pueden obtenerse bases de datos NoSQL. La diferencia es el nivel de abstracción. Las bases de datos NoSQL eliminan los niveles más altos de abstracción y entregan esa capacidad al programador de la aplicación, lo que resulta en un código general más rápido con la mayor probabilidad de corrupción de datos por parte de programadores no experimentados.

Como resultado, es mucho más probable que veamos que las bases de datos NoSQL se usan cada vez más en el espacio de aplicaciones web, donde el tiempo de desarrollo y el rendimiento son muy importantes. Es probable que el software financiero y corporativo conserve su herencia SQL porque el rendimiento del hardware es relativamente barato, tienen DBA experimentados disponibles y el mayor riesgo causado por programadores no experimentados no es aceptable.

RandomProgrammer
fuente
2
No estoy seguro de estar de acuerdo con la parte sobre transacciones atómicas, en el sentido ACID (aunque es difícil comentar sobre "NoSQL", ya que está en debate lo que queremos decir exactamente). La mayoría de las ganancias de rendimiento en las bases de datos NoSQL "típicas" se logran mediante el aflojamiento de las garantías de consistencia (ver: consistencia eventual , ACID vs. BASE). Si la consistencia eventual es lo suficientemente buena para una aplicación (y a menudo lo es), entonces esto permite una escala horizontal mucho más eficiente.
Daniel B
4

De IBM developerWorks: Suministre escalabilidad de datos a nivel de la nube con bases de datos NoSQL

La escalabilidad es el sistema que debería ser capaz de soportar bases de datos muy grandes con tasas de solicitud muy altas a muy baja latencia.

Los sistemas NoSQL tienen una serie de características de diseño en común:

  • La capacidad de escalar horizontalmente el rendimiento en muchos servidores.
  • Una interfaz o protocolo de nivel de llamada simple (en contraste con un enlace SQL).
  • Soporte para modelos de consistencia más débil que las transacciones ACID en la mayoría de los RDBMS tradicionales.
  • Uso eficiente de índices distribuidos y RAM para almacenamiento de datos.
  • La capacidad de definir dinámicamente nuevos atributos o esquema de datos.

Por qué las bases de datos relacionales pueden no ser óptimas para Scaling

En general, los sistemas de gestión de bases de datos relacionales se han considerado como una "solución única para la persistencia y recuperación de datos" durante décadas. Han madurado después de extensos esfuerzos de investigación y desarrollo y han creado con éxito un gran mercado y soluciones en diferentes dominios comerciales.

La necesidad cada vez mayor de escalabilidad y los nuevos requisitos de aplicación han creado nuevos desafíos para el RDBMS tradicional, incluida cierta insatisfacción con este enfoque único para todas las aplicaciones a escala web. La respuesta a esto ha sido una nueva generación de software de base de datos de bajo costo y alto rendimiento diseñado para desafiar el dominio de los sistemas de gestión de bases de datos relacionales. Una gran razón para el movimiento NoSQL es que las diferentes implementaciones de aplicaciones web, empresariales y de computación en la nube tienen diferentes requisitos de sus bases de datos; por ejemplo, no todas las aplicaciones requieren una coherencia de datos rígida.

Otro ejemplo: para sitios web de gran volumen como eBay, Amazon, Twitter o Facebook, la escalabilidad y la alta disponibilidad son requisitos esenciales que no pueden verse comprometidos. Para estas aplicaciones, incluso la más mínima interrupción puede tener importantes consecuencias financieras e impactar la confianza del cliente.

En DBA.SE: ¿Qué significa la escala horizontal?

La escala horizontal se está construyendo esencialmente en lugar de hacia arriba. No va y compra un servidor más grande y robusto y mueve toda su carga sobre él, en su lugar, compra 1+ servidores adicionales y distribuye su carga entre ellos.

El escalado horizontal se usa cuando tiene la capacidad de ejecutar varias instancias en servidores simultáneamente. Por lo general, es mucho más difícil pasar de 1 servidor a 2 servidores que pasar de 2 a 5, 10, 50, etc.

Una vez que haya abordado los problemas de ejecución de instancias paralelas, puede aprovechar las ventajas de entornos como Amazon EC2, Rackspace's Cloud Service, GoGrid, etc., ya que puede aumentar y disminuir las instancias según la demanda, lo que reduce la necesidad de pagar por la potencia del servidor no estás usando solo para cubrir esas cargas máximas.

Las bases de datos relacionales son uno de los elementos más difíciles de ejecutar en lectura / escritura completa en paralelo.

Md Mahbubur Rahman
fuente