database - example - Diferencia entre la escala horizontal y vertical para las bases de datos
nosql tutorial (10)
Agregar muchos balanceadores de carga crea sobrecarga y latencia adicionales, y ese es el inconveniente de escalar horizontalmente en las bases de datos nosql. Es como la pregunta de por qué la gente dice que RPC no se recomienda ya que no es robusto.
Creo que en un sistema real deberíamos usar bases de datos tanto sql como nosql para utilizar las capacidades de computación en nube y multinúcleo 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 ser usado para grandes datos y escalabilidad horizontal por fragmentación.
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?
Comencemos con la necesidad de escalar que está incrementando los recursos para que su sistema ahora pueda manejar más solicitudes de las que podía antes.
Cuando se da cuenta, su sistema se está ralentizando y no puede manejar la cantidad actual de solicitudes, debe escalar el sistema.
Esto le proporciona dos opciones, ya sea que aumente los recursos en el servidor que está utilizando actualmente, es decir, que aumente 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 fallos, es decir, si está escalando una aplicación que se ejecuta con un solo servidor, si ese servidor se cae, su sistema se apagará. También la cantidad de hilos sigue siendo la misma en la escala vertical. La escala vertical puede requerir que su sistema baje por un momento cuando el proceso se lleva a cabo. El aumento de recursos en un servidor requiere un reinicio y apaga 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 solicitud por segundo en cada servidor. Si necesita escalar el sistema, simplemente agregue otro servidor y listo. No es necesario reiniciar el sistema. El número de subprocesos en cada sistema disminuye lo que lleva a un alto rendimiento. Para segregar las solicitudes, igualmente a cada uno de los servidores de aplicaciones, debe agregar un equilibrador de carga que actuaría como proxy inverso a los servidores web. Todo este sistema se puede llamar como un único clúster. Su sistema puede contener una gran cantidad de solicitudes que requerirían una mayor cantidad de clústeres como este.
Espero que tengas todo el concepto de introducir escala en el sistema.
En palabras simples
escala horizontalmente ===> Todos los miles de minions juntos hacen el trabajo por ti
escala verticalmente ===> One big hulk hará todo el trabajo o usted.
Existe una arquitectura adicional que no se mencionó: los servicios de base de datos basados en SQL que permiten el escalado horizontal sin la complejidad de la fragmentación manual. Estos servicios hacen la fragmentación en segundo plano, por lo que le permiten ejecutar una base de datos SQL tradicional y escalar como lo haría con los motores NoSQL como MongoDB o CouchDB. Dos servicios con los que estoy familiarizado son EnterpriseDB for PostgreSQL y Xeround for MySQL. Vi una post detallada de Xeround que explica por qué la ampliación de escala 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 vendedor. También revise la entrada de la base de datos en la nube de Wikipedia, hay una buena explicación de SQL vs. NoSQL y servicio vs. auto hospedado, una lista de proveedores y opciones de escala para cada combinación. ;)
La escalabilidad horizontal es la capacidad de aumentar la capacidad al conectar varias entidades de hardware o software para que funcionen como una sola unidad lógica.
Cuando los servidores están agrupados, el servidor original se está ampliando horizontalmente. Si un clúster requiere más recursos para mejorar el rendimiento y proporcionar alta disponibilidad (HA), un administrador puede escalar agregando más servidores al clúster.
Una ventaja importante de la escalabilidad horizontal es que puede proporcionar a los administradores la capacidad de aumentar la capacidad sobre la marcha. Otra ventaja es que, en teoría, la escalabilidad horizontal solo está limitada por la cantidad de entidades que se pueden conectar con éxito. El sistema de almacenamiento distribuido Cassandra, por ejemplo, se ejecuta sobre cientos de nodos de productos distribuidos en diferentes centros de datos. Debido a que el hardware del producto se amplía horizontalmente, Cassandra es tolerante a fallas y no tiene un solo punto de falla (SPoF).
La escalabilidad vertical, por otro lado, aumenta la capacidad al agregar más recursos, como más memoria o una CPU adicional, a una máquina. La ampliación vertical, que también se denomina ampliación, generalmente requiere tiempo de inactividad mientras se agregan nuevos recursos y tiene límites definidos por el hardware. Cuando los clientes de Amazon RDS necesitan escalar verticalmente, por ejemplo, pueden cambiar de una máquina más pequeña a una más grande, pero la instancia de RDS más grande de Amazon tiene solo 68 GB de memoria.
La escala horizontal tiene ventajas y desventajas. Por ejemplo, agregar computadoras de bajo costo a un clúster a primera vista puede parecer una solución rentable, pero es importante que el administrador sepa si los costos de licencia para esos servidores adicionales, el costo de las operaciones adicionales de alimentación y refrigeración y la la gran huella que ocuparán en el centro de datos realmente hace que escalar horizontalmente sea una mejor opción que escalar verticalmente.
Las bases de datos SQL como Oracle y db2 también admiten el escalado horizontal a través del clúster de discos compartidos. 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 una escala horizontal.
Pero el enfoque es diferente de las bases de datos noSQL (como mongodb, CouchDB o IBM Cloudant) es que la fragmentación de los datos no es parte de la escala horizontal. En las bases de datos noSQL los datos se reducen durante la escala horizontal.
Las bases de datos relacionales tradicionales fueron diseñadas como sistemas de base 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 base 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 en http://goo.gl/uzLIWB .
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 de la memoria / disco del servidor, debe comenzar a fragmentar los datos entre los 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 es también una fantástica base de datos de escalamiento horizontal NoSQL, utilizada en muchas aplicaciones y juegos comerciales de alta disponibilidad y posiblemente el mejor desempeño en la categoría. Particiona los datos automáticamente en el clúster, agregar nodos es simple, y puede usar hardware básico, instancias de vm más baratas (por ejemplo, usar Large en lugar de High Mem, High Disk en AWS). Está construido a partir de la Membase (Memcached) pero agrega persistencia. Además, en el caso de Couchbase, todos los nodos pueden hacer lecturas y escrituras, y son iguales en el clúster, con solo la replicación de conmutación por error (no la replicación del conjunto de datos completo 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 excelente publicación de blog sobre Couchbase Architecture: http://horicky.blogspot.com/2012/07/couchbase-architecture.html
Todas las demás respuestas parecen ya bastante completas, pero no vi a Google Cloud Spanner como un ejemplo de una base de datos relacional con escala horizontal, por eso estoy agregando mi pequeña contribución.
La escala horizontal significa que la escala agregando más máquinas a su grupo de recursos, mientras que la escala vertical significa que la escala agregando más potencia (CPU, RAM) a una máquina existente .
Una forma fácil de recordar esto es pensar en una máquina en un rack de servidores, agregamos más máquinas en dirección horizontal y agregamos más recursos a una máquina en dirección vertical .
En un mundo de base de datos, la escala horizontal a menudo se basa en la partición de los datos, es decir, cada nodo contiene solo parte de los datos, en la escala vertical los datos residen en un solo nodo y la escala se realiza a través de varios núcleos, es decir, distribuyendo la carga entre Los recursos de CPU y RAM de esa máquina.
Con la escala horizontal, a menudo es más fácil escalar dinámicamente agregando más máquinas al grupo existente. La escala 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.
Los 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 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 el tiempo de inactividad.
Las cuadrículas de datos en memoria, como GigaSpaces XAP , Coherence , etc., a menudo se optimizan tanto para la escala horizontal como para la vertical, simplemente porque no están vinculadas al disco. Escalado horizontal a través de la partición y escalamiento vertical a través de soporte multi-core.
Puede leer más sobre este tema en mis publicaciones anteriores: Escalado frente a Escalado y Los principios comunes detrás de las alternativas de NOSQL