Diferencia entre escalar horizontal y verticalmente para bases de datos [cerrado]

Me he encontrado con muchas bases de datos NoSQL y bases de datos SQL. Existen diversos parámetros para medir la fortaleza y las debilidades de estas bases de datos y la escalabilidad es una de ellas. ¿Cuál es la diferencia entre escalar horizontal y verticalmente estas bases de datos?

El escalado horizontal significa que usted escala agregando más máquinas a su grupo de recursos, mientras que el escalado vertical significa que escala agregando más potencia (CPU, RAM) a una máquina existente .

Una manera fácil de recordar esto es pensar en una máquina en un rack de servidores, agregamos más máquinas en la dirección horizontal y agregamos más recursos a una máquina en la dirección vertical .

En una base de datos, el escalado horizontal a menudo se basa en la partición de los datos, es decir, cada nodo contiene solo una parte de los datos, en el escalado vertical los datos residen en un solo nodo y el escalado se realiza a través de múltiples núcleos, es decir, distribuyendo la carga entre los recursos de CPU y RAM de esa máquina.

Con el escalado horizontal, a menudo es más fácil escalar dinámicamente al agregar más máquinas al grupo existente: el escalado vertical a menudo se limita a la capacidad de una sola máquina, escalar más allá de esa capacidad a menudo implica tiempo de inactividad y viene con un límite superior.

Buenos ejemplos de escala horizontal son Cassandra, MongoDB, Google Cloud Spanner ... y un buen ejemplo de escala vertical es MySQL - Amazon RDS (la versión en la nube de MySQL). Proporciona una manera fácil de escalar verticalmente al cambiar de máquinas pequeñas a máquinas más grandes. Este proceso a menudo implica tiempo de inactividad.

Las cuadrículas de datos en memoria, como GigaSpaces XAP , Coherence , etc., a menudo se optimizan para el escalado horizontal y vertical simplemente porque no están vinculadas al disco. Escalado horizontal mediante particionamiento y escala vertical mediante soporte multinúcleo.

Puede leer más sobre este tema en mis mensajes anteriores: Escala de salida vs ampliación progresiva y los principios comunes detrás de la NOSQL Alternativas

Escalando horizontalmente ===> Miles de secuaces harán el trabajo juntos por usted.

Escalando verticalmente ===> Un gran hulk hará todo el trabajo por usted.

Comencemos con la necesidad de escalar que aumenta los recursos para que su sistema ahora pueda manejar más solicitudes que antes.

Cuando se da cuenta de que su sistema se está ralentizando y no puede manejar el número actual de solicitudes, debe escalar el sistema.

Esto le brinda dos opciones. O aumenta los recursos en el servidor que está utilizando actualmente, es decir, aumenta la cantidad de RAM, CPU, GPU y otros recursos. Esto se conoce como escala vertical.

La escala vertical suele ser costosa. No hace que el sistema sea tolerante a fallas, es decir, si está escalando una aplicación que se ejecuta con un solo servidor, si ese servidor se cae, su sistema se caerá. Además, la cantidad de hilos permanece igual en la escala vertical. El escalado vertical puede requerir que su sistema se caiga por un momento cuando se lleva a cabo el proceso. El aumento de recursos en un servidor requiere un reinicio y apagar su sistema.

Otra solución a este problema es aumentar la cantidad de servidores presentes en el sistema. Esta solución es muy utilizada en la industria tecnológica. Esto eventualmente disminuirá la tasa de solicitud por segundo en cada servidor. Si necesita escalar el sistema, simplemente agregue otro servidor y listo. No sería necesario reiniciar el sistema. El número de subprocesos en cada sistema disminuye, lo que lleva a un alto rendimiento. Para segregar las solicitudes, por igual a cada uno de los servidores de aplicaciones, debe agregar un equilibrador de carga que actuaría como proxy inverso para los servidores web. Todo este sistema se puede llamar como un solo clúster. Su sistema puede contener una gran cantidad de solicitudes que requerirían una mayor cantidad de clústeres como este.

Espero que entiendas el concepto completo de introducir escala en el sistema.

Hay una arquitectura adicional que no se mencionó: servicios de bases de datos basados ​​en SQL que permiten el escalado horizontal sin la complejidad del fragmentación manual. Estos servicios realizan el fragmentación en segundo plano, por lo que le permiten ejecutar una base de datos SQL tradicional y escalar como lo haría con motores NoSQL como MongoDB o CouchDB. Dos servicios con los que estoy familiarizado son EnterpriseDB para PostgreSQL y Xeround para MySQL. Vi una publicación en profundidad de Xeround que explica por qué el escalado horizontal en las bases de datos SQL es difícil y cómo lo hacen de manera diferente: trate esto con un grano de sal, ya que es una publicación del proveedor. Consulte también la entrada de la base de datos en la nube de Wikipedia, hay una buena explicación de SQL vs NoSQL y servicio vs autohospedado, una lista de proveedores y opciones de escala para cada combinación. ;)

Sí, escalar horizontalmente significa agregar más máquinas, pero también implica que las máquinas son iguales en el clúster. MySQL puede escalar horizontalmente en términos de lectura de datos, mediante el uso de réplicas, pero una vez que alcanza la capacidad del servidor / memoria del servidor, debe comenzar a compartir datos entre servidores. Esto se vuelve cada vez más complejo. A menudo, mantener los datos consistentes entre las réplicas es un problema, ya que las tasas de replicación suelen ser demasiado lentas para mantenerse al día con las tasas de cambio de datos.

Couchbase también es una fantástica base de datos de escalamiento horizontal NoSQL, utilizada en muchas aplicaciones y juegos comerciales de alta disponibilidad y posiblemente el de mejor desempeño en la categoría. Divide los datos automáticamente en el clúster, agregar nodos es simple y puede usar hardware básico, instancias de VM más económicas (por ejemplo, usando máquinas grandes en lugar de High Mem, High Disk en AWS). Está construido a partir de Membase (Memcached) pero agrega persistencia. Además, en el caso de Couchbase, cada nodo puede hacer lecturas y escrituras, y son iguales en el clúster, con solo replicación de conmutación por error (no replicación completa del conjunto de datos en todos los servidores como en mySQL).

En cuanto al rendimiento, puede ver un excelente punto de referencia de Cisco: http://blog.couchbase.com/understanding-performance-benchmark-published-cisco-and-solarflare-using-couchbase-server

Aquí hay una gran publicación de blog sobre Arquitectura Couchbase: http://horicky.blogspot.com/2012/07/couchbase-architecture.html

Las bases de datos relacionales tradicionales se diseñaron como sistemas de bases de datos cliente / servidor. Se pueden escalar horizontalmente, pero el proceso para hacerlo tiende a ser complejo y propenso a errores. Las bases de datos NewSQL como NuoDB son sistemas de bases de datos distribuidos centrados en la memoria diseñados para escalar horizontalmente mientras se mantienen las propiedades SQL / ACID de los RDBMS tradicionales.

Para obtener más información sobre NuoDB, lea su documento técnico .

Las bases de datos SQL como Oracle, db2 también admiten el escalado horizontal a través del clúster de disco compartido. Por ejemplo, Oracle RAC, IBM DB2 purescale o Sybase ASE Cluster edition. Se puede agregar un nuevo nodo al sistema Oracle RAC o al sistema DB2 purescale para lograr el escalado horizontal.

Pero el enfoque es diferente de las bases de datos noSQL (como mongodb, CouchDB o IBM Cloudant) es que el fragmentación de datos no es parte del escalado horizontal. En las bases de datos noSQL, los datos se ocultan durante el escalado horizontal.

Tienes una empresa y solo hay 1 trabajador, pero tienes 1 proyecto nuevo en ese momento que contratas a un nuevo candidato, esto es escala horizontal. donde el nuevo candidato es nuevas máquinas y el proyecto es nuevo tráfico / llamadas a su API.

Donde como 1 proyecto con un chico IIT / NIT manejando todas las solicitudes a su api / tráfico. Si en algún momento solicitas más a tu API, despídelo y reemplázalo con un tipo IQ NIT / IIT alto: esto es escala vertical.

Agregar muchos equilibradores de carga crea una sobrecarga y latencia adicionales y ese es el inconveniente de escalar horizontalmente en bases de datos nosql. Es como la pregunta de por qué la gente dice que no se recomienda RPC ya que no es robusto.

Creo que en un sistema real deberíamos usar bases de datos sql y nosql para utilizar las capacidades de cómputo multinúcleo y en la nube de los sistemas actuales.

Por otro lado, las consultas transaccionales complejas tienen un alto rendimiento si se utilizan bases de datos SQL como Oracle. NoSql podría usarse para bigdata y escalabilidad horizontal mediante fragmentación.

La respuesta aceptada es puntual en la definición básica de escala horizontal versus vertical. Pero a diferencia de la creencia común de que el escalado horizontal de las bases de datos solo es posible con Cassandra, MongoDB, etc. Me gustaría agregar que el escalado horizontal también es muy posible con cualquier RDMS tradicional; eso también sin usar soluciones de terceros.

Sé de muchas empresas, especialmente las empresas basadas en SaaS que hacen esto. Esto se hace usando una lógica de aplicación simple. Básicamente, toma un conjunto de usuarios y los divide en varios servidores de bases de datos. Entonces, por ejemplo, normalmente tendría una base de datos / tabla "meta" que almacenaría clientes, servidor DB / cadenas de conexión, etc. y una tabla que almacena la asignación de cliente / servidor.

Luego, simplemente dirija las solicitudes de cada cliente al servidor de base de datos al que están asignadas.

Ahora, algunos pueden decir que esto es similar a la partición horizontal y no al escalamiento horizontal "verdadero", y tendrán razón de alguna manera. Pero el resultado final es que ha escalado su base de datos en varios servidores Db.

La única diferencia entre los dos enfoques para el escalado horizontal es que con un enfoque (MongoDB, etc.), el escalado lo realiza el propio software DB. En ese sentido, está "comprando" la escala. En el otro enfoque (para el escalado horizontal RDBMS), el escalado se construye mediante código / lógica de aplicación.