¿Por qué NoSQL es mejor para "escalar" que RDBMS?

Question

He leído el texto siguiente en un technical blog discutir las ventajas y desventajas de NoSQL

" Durante años, con el fin de mejorar el rendimiento en servidores de bases de datos, administradores de bases de datos han tenido que comprar servidores más grandes ya que la carga de base de datos aumenta (ampliación) en lugar de distribuir la base de datos en varios "hosts" a medida que aumenta la carga (ampliación). RDBMS normalmente no escala fácilmente, pero las bases de datos NoSQL más nuevas están realmente diseñadas para expandirse fácilmente para aprovechar los nuevos nodos y generalmente se diseñan teniendo en cuenta hardware básico de bajo costo. "

Me confundí sobre la escalabilidad de RDBMS y NoSQL.

Mi confusión son:

1. Por qué RDBMS son menos capaces de escalar? Y la razón de comprar servidores más grandes en lugar de comprar los más baratos.
2. ¿Por qué NoSQL es más capaz de escalar?

Answer 1

RDBMS tienen ACID (http://en.wikipedia.org/wiki/ACID) y admite transacciones. Escalar "hacia afuera" con RDBMS es más difícil de implementar debido a estos conceptos.

Las soluciones No SQL suelen ofrecer una atomicidad récord, pero no pueden garantizar que una serie de operaciones tenga éxito (transacción).

Se reduce a: para mantener la integridad de los datos y las transacciones de soporte, un RDBMS de múltiples servidores necesitaría un canal de comunicación rápido para sincronizar todas las posibles transacciones y escrituras, mientras se evita/maneja el interbloqueo.

Es por eso que solo suele ver 1 maestro (escritor) y varios esclavos (lectores).

Answer 2

Los RDBMS típicos ofrecen garantías sólidas sobre la consistencia. Esto requiere, en cierta medida, la comunicación entre nodos para cada transacción. Esto limita la capacidad de escalar, porque más nodos significa más comunicación

Los sistemas NoSql hacen intercambios diferentes. Por ejemplo, no garantizan que una segunda sesión vea inmediatamente los datos comprometidos por una primera sesión. De este modo, se desacopla la transacción de almacenar algunos datos del proceso de hacer que esos datos estén disponibles para cada usuario. Google "finalmente consistente". Entonces, una transacción única no necesita esperar ninguna (o mucho menos) comunicación entre nodos. Por lo tanto, pueden utilizar una gran cantidad de nodos mucho más fácilmente.

Answer 3

Así que he estado tratando de averiguar el verdadero resultado final cuando se trata de NoSQL vs RDBMS yo mismo, y siempre termino con una respuesta que no acaba de cortarlo. En mi búsqueda, existen realmente 2 diferencias principales entre NoSQL y SQL, y solo 1 es una verdadera ventaja.

1. ÁCIDO BASE vs - NoSQL normalmente deja fuera algunas de las características ACID de SQL, una especie de 'trampa' su camino a un mayor rendimiento al dejar esta capa de abstracción para el programador. Esto ya ha sido cubierto por carteles anteriores.

2. Escala horizontal - La ventaja real de NoSQL es la escala horizontal, también conocida como fragmentación.Teniendo en cuenta que los 'documentos' de NoSQL son una especie de objeto 'autónomo', los objetos pueden estar en diferentes servidores sin preocuparse por unir filas de varios servidores, como es el caso con el modelo relacional.

Digamos que queremos devolver un objeto como éste:

post { 
    id: 1 
    title: 'My post' 
    content: 'The content' 
    comments: { 
     comment: { 
     id: 1 
     } 
     comment: { 
     id: 2 
     } 
     ... 

    views: { 
     view: { 
     user: 1 
     } 
     view: { 
     user: 2 
     } 
     ... 
    } 
} 

En NoSQL, básicamente se almacena ese objeto como es, y por lo tanto puede residir en un único servidor como una especie de auto objeto contenido, sin necesidad de unirse a los datos de otras tablas que podrían residir en otros servidores de bases de datos.

Sin embargo, con DB relacionales, la publicación debería unirse a los comentarios de la tabla comments, así como a las vistas de la tabla views. Esto no sería un problema en SQL ~ UNTIL ~ el DB está dividido en fragmentos, en cuyo caso 'comment 1' podría estar en un servidor de bases de datos, mientras que 'comment 2' aún en otro servidor de bases de datos. Esto hace que sea mucho más difícil crear el mismo objeto en un RDBMS que se ha escalado horizontalmente que en un DB NoSQL.

¿Algún experto en DB confirmará o sostendrá estos puntos?

Answer 4

Para un NO SQL, 1.Todo el elemento secundario relacionado con una colección está en el mismo lugar y en el mismo servidor y no hay ninguna operación de combinación para buscar datos de otro servidor.

2. No hay esquema, por lo que no se necesitan bloqueos en ningún servidor y el manejo de las transacciones se deja a los clientes.

Lo anterior 2 ahorra una gran sobrecarga de escala en NO-SQL.