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

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 la integridad referencial, las transacciones, etc. Todas estas son cosas que es muy útil tener para algunos problemas y que requieren algunas técnicas interesantes para escalar fuera de un único servidor (piense qué sucede si necesita para bloquear dos tablas para una transacción atómica, ¡y están en servidores diferentes!).

las bases de datos noSQL no tienen todo eso. Si necesitas eso, debes hacerlo tú mismo, pero si NO lo necesitas (y hay muchas aplicaciones que no lo hacen), entonces tienes suerte. La base de datos no tiene que hacer todas estas operaciones complejas y bloquear la mayor parte del conjunto de datos, por lo que es realmente fácil dividir la cosa 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 debe dividirse 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 las RDBMS tradicionales) pueden escalar las lecturas. No son intrínsecamente menos eficientes que las bases de datos NoSQL porque los (posibles) cuellos de botella de rendimiento son introducidos por las carencias de NoSQL (a veces) (como las uniones y dónde las restricciones) que puede optar por no usar. SQL RDBMS agrupados pueden escalar las lecturas introduciendo nodos adicionales en el clúster. Hay restricciones en cuanto a la manera en que se pueden escalar las operaciones de lectura, pero éstas se deben a la dificultad de escalar las escrituras a medida que introduce más nodos en el clúster.

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

• La atomicidad significa que las transacciones deben completarse o fallar en su totalidad, por lo que se debe realizar mucha contabilidad detrás de la escena para garantizar esto.
• Las restricciones de coherencia significan que todos los nodos del clúster deben ser idénticos. Si escribe en un nodo, esta escritura debe copiarse a 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 no perder nunca una escritura, debe asegurarse de que, antes de devolver una respuesta al cliente, la escritura se haya vaciado en el disco.

Para escalar las operaciones de escritura o la cantidad de nodos en un clúster más allá de cierto punto, debe poder relajarse algunos de los requisitos de ACID:

• La caída de la atomicidad le permite acortar la duración de las tablas (conjuntos de datos) que están bloqueadas. Ejemplo: MongoDB, CouchDB.
• Eliminar consistencia le permite escalar las escrituras en los nodos del clúster. Ejemplos: riak, cassandra.
• La caída de la durabilidad le permite responder a los comandos de escritura sin vaciarlos en el disco. Ejemplos: memcache, redis.

Las bases de datos NoSQL generalmente siguen el modelo BASE en lugar del modelo ACID. Renuncian a los requisitos A, C y / o D, y a cambio mejoran la escalabilidad. Algunas, 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 de SQL carece de un mecanismo para describir consultas donde los requisitos de ACID se relajan. Es por esto que las bases de datos BASE son todas NoSQL.

Nota personal: un último punto que me gustaría resaltar es que en 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 utilizando un esquema correctamente normalizado con índices adecuados. Como lo demuestra este 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 asumiendo con sus datos.

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

Escalabilidad es el sistema que debería ser compatible con bases de datos muy grandes con tasas de solicitud muy altas y con una latencia muy baja.

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 SQL vinculante).
• Compatibilidad con modelos de consistencia más débiles que las transacciones ACID en RDBMS más tradicionales.
• Uso eficiente de índices distribuidos y RAM para el almacenamiento de datos.
• La capacidad de definir dinámicamente nuevos atributos o esquemas de datos.

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

En general, los sistemas de administració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 gran éxito un gran mercado y soluciones en diferentes dominios de negocios.

La creciente necesidad de escalabilidad y los nuevos requisitos de las aplicaciones han creado nuevos desafíos para los RDBMS tradicionales, que incluyen cierta insatisfacción con este enfoque de talla única en algunas aplicaciones de 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 base 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 consistencia rígida de los datos.

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 se pueden comprometer. Para estas aplicaciones, incluso la más mínima interrupción puede tener importantes consecuencias financieras e impacto en la confianza del cliente.

Sobre DBA.SE: ¿Qué significa escala horizontal?

El escalado horizontal se está construyendo esencialmente en lugar de hacia arriba. No vas a comprar un servidor más grande y robusto y mueves toda tu carga a él, en lugar de eso, compras 1+ servidores adicionales y distribuyes tu carga a través de ellos.

La escala 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 de 2 a 5, 10, 50, etc.

Una vez que haya abordado los problemas de la ejecución de instancias paralelas, puede aprovechar los entornos como Amazon EC2, el Servicio en la nube de Rackspace, GoGrid, etc., ya que puede subir y bajar instancias según la demanda, lo que reduce la necesidad de pagar. para la potencia del servidor no está utilizando solo para cubrir esas cargas pico.

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

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.) se pueden escalar para manejar requisitos de rendimiento muy grandes por DBA experimentados.

Las bases de datos NoSQL permiten a los programadores experimentados, que conocen las condiciones de las carreras 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 se pueden obtener en las 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 más rápido en general con la mayor probabilidad de corrupción de datos por parte de programadores no sazonados.

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