over - ¿Por qué NoSQL es mejor en "escalamiento" que RDBMS?

when to use relational database over nosql

Question

He leído el siguiente texto en un blog técnico que analiza las ventajas y desventajas de NoSQL

" Durante años, para mejorar el rendimiento de los servidores de base de datos, los administradores de la base de datos han tenido que comprar servidores más grandes a medida que aumenta la carga de la base de datos (escalada) en lugar de distribuir la base de datos entre múltiples" hosts "a medida que aumenta la carga (escalada). RDBMS por lo general, no se puede escalar fácilmente, pero las bases de datos NoSQL más nuevas están diseñadas para expandirse fácilmente para aprovechar los nuevos nodos y, por lo general, están diseñadas teniendo en cuenta el hardware básico de bajo costo " .

Me confundí acerca de 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 servidores más baratos.
2. ¿Por qué NoSQL es más capaz de escalar?

Answer 1

Así que he estado tratando de averiguar la verdadera línea de fondo en lo que respecta a NoSQL vs RDBMS, y siempre termino con una respuesta que no acaba de cortarla. En mi búsqueda hay realmente 2 diferencias principales entre NoSQL y SQL, con solo 1 es una verdadera ventaja.

1. ACID vs BASE : NoSQL por lo general deja de lado algunas de las características de ACID de SQL, como "hacer trampa", es una forma de obtener un mayor rendimiento al dejar esta capa de abstracción al programador. Esto ya ha sido cubierto por carteles anteriores.

2. Escala horizontal : la verdadera ventaja 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 "autocontenido", los objetos pueden estar en diferentes servidores sin preocuparse de unir filas de múltiples servidores, como es el caso del modelo relacional.

Digamos que queremos devolver un objeto como este:

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, ese objeto se almacenaría básicamente como está y, por lo tanto, puede residir en un solo servidor como una especie de objeto independiente, sin necesidad de unirse con datos de otras tablas que podrían residir en otros servidores de base de datos.

Sin embargo, con las bases de datos relacionales, la publicación debería unirse con los comentarios de la tabla de comments , así como las vistas desde la tabla de views . Esto no sería un problema en SQL ~ HASTA ~ la base de datos se divide en fragmentos, en cuyo caso el ''comentario 1'' podría estar en un servidor de base de datos, mientras que el ''comentario 2'' en otro servidor de base 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 una base de datos NoSQL.

¿Alguno de los expertos en DB confirma o discute estos puntos?

Answer 2

Los RDBMS típicos ofrecen fuertes garantías sobre la consistencia. Esto requiere cierta 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 diferentes compensaciones. Por ejemplo, no garantizan que una segunda sesión verá los datos inmediatamente 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". Por lo tanto, una sola transacción no necesita esperar ninguna comunicación entre nodos (o mucho menos). Por lo tanto, son capaces de utilizar una gran cantidad de nodos mucho más fácilmente.

Answer 3

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

2. No hay ningún 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 cantidad de sobrecarga de escala en NO-SQL.

Answer 4

RDBMS tiene ACID ( http://en.wikipedia.org/wiki/ACID ) y admite transacciones. Es más difícil de implementar la "salida" con RDBMS debido a estos conceptos.

Las soluciones NoSQL generalmente ofrecen una atomicidad de nivel récord, pero no pueden garantizar que una serie de operaciones tengan éxito (transacción).

Todo se reduce a: para mantener la integridad de los datos y las transacciones de soporte, un RDBMS multiservidor necesitaría tener un canal de comunicación backend rápido para sincronizar todas las transacciones y escrituras posibles, al mismo tiempo que evita / maneja el interbloqueo.

Es por eso que normalmente solo ves 1 maestro (escritor) y esclavos múltiples (lectores).