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

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?

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.

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).

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.

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.