Diferença entre dimensionamento horizontal e vertical para bancos de dados [fechado]

Eu me deparei com muitos bancos de dados NoSQL e bancos de dados SQL. Existem vários parâmetros para medir a força e as fraquezas desses bancos de dados e a escalabilidade é um deles. Qual é a diferença entre o dimensionamento horizontal e vertical desses bancos de dados?

Escala horizontal significa que você escala adicionando mais máquinas ao seu conjunto de recursos, enquanto Escala vertical significa que você escala adicionando mais energia (CPU, RAM) a uma máquina existente .

Uma maneira fácil de lembrar isso é pensar em uma máquina em um rack de servidor, adicionamos mais máquinas na direção horizontal e mais recursos a uma máquina na direção vertical .

Em um mundo de banco de dados, o dimensionamento horizontal é geralmente baseado no particionamento dos dados, ou seja, cada nó contém apenas parte dos dados; no dimensionamento vertical, os dados residem em um único nó e o dimensionamento é feito por vários núcleos, ou seja, espalhando a carga entre os recursos de CPU e RAM dessa máquina.

Com o dimensionamento horizontal, muitas vezes é mais fácil dimensionar dinamicamente adicionando mais máquinas ao pool existente - o dimensionamento vertical costuma ser limitado à capacidade de uma única máquina, o dimensionamento além dessa capacidade geralmente envolve tempo de inatividade e vem com um limite superior.

Bons exemplos de escala horizontal são Cassandra, MongoDB, Google Cloud Spanner .. e um bom exemplo de escala vertical é o MySQL - Amazon RDS (a versão em nuvem do MySQL). Ele fornece uma maneira fácil de escalar verticalmente, alternando de máquinas pequenas para maiores. Esse processo geralmente envolve tempo de inatividade.

As grades de dados na memória, como GigaSpaces XAP , coerência etc., geralmente são otimizadas para escala horizontal e vertical, simplesmente porque não estão vinculadas ao disco. Escalonamento horizontal por meio de particionamento e escalonamento vertical por meio de suporte multinúcleo.

Você pode ler mais sobre esse assunto nos meus posts anteriores: Scale-out vs Scale-up e Os princípios comuns por trás das alternativas NOSQL

Escalando horizontalmente ===> Milhares de lacaios farão o trabalho juntos por você.

Escalando verticalmente ===> Um grande hulk fará todo o trabalho para você.

Vamos começar com a necessidade de dimensionamento que está aumentando os recursos, para que seu sistema possa agora lidar com mais solicitações do que antes.

Quando você percebe que seu sistema está ficando lento e não consegue lidar com o número atual de solicitações, é necessário escalar o sistema.

Isso fornece duas opções. Você aumenta os recursos no servidor que está usando atualmente, ou seja, aumenta a quantidade de RAM, CPU, GPU e outros recursos. Isso é conhecido como escala vertical.

A escala vertical é normalmente cara. Isso não torna o sistema tolerante a falhas, ou seja, se você estiver dimensionando o aplicativo em execução com um único servidor, se esse servidor ficar inativo, o sistema ficará inoperante. Além disso, a quantidade de encadeamentos permanece a mesma na escala vertical. A escala vertical pode exigir que seu sistema seja desativado por um momento em que o processo ocorre. O aumento de recursos em um servidor requer uma reinicialização e desligamento do sistema.

Outra solução para esse problema é aumentar a quantidade de servidores presentes no sistema. Esta solução é muito usada na indústria de tecnologia. Isso acabará por diminuir a taxa de solicitação por segundo em cada servidor. Se você precisar dimensionar o sistema, basta adicionar outro servidor e pronto. Você não seria obrigado a reiniciar o sistema. O número de threads em cada sistema diminui, levando a um alto rendimento. Para segregar as solicitações, igualmente para cada servidor de aplicativos, você precisa adicionar um balanceador de carga que atuaria como proxy reverso nos servidores da web. Todo esse sistema pode ser chamado como um único cluster. Seu sistema pode conter um grande número de solicitações, o que exigiria mais clusters como esse.

Espero que você tenha todo o conceito de introdução da escala no sistema.

Há uma arquitetura adicional que não foi mencionada - serviços de banco de dados baseados em SQL que permitem o dimensionamento horizontal sem a complexidade do sharding manual. Esses serviços fazem o sharding em segundo plano, permitindo que você execute um banco de dados SQL tradicional e expanda como faria com os mecanismos NoSQL, como MongoDB ou CouchDB. Dois serviços que eu conheço são o EnterpriseDB para PostgreSQL e Xeround para MySQL. Eu vi uma publicação detalhada da Xeround, que explica por que a expansão nos bancos de dados SQL é difícil e como eles fazem isso de maneira diferente - trate isso com um pouco de sal, pois é uma publicação do fornecedor. Verifique também a entrada do banco de dados em nuvem da Wikipedia, há uma boa explicação sobre SQL vs. NoSQL e serviço vs. auto-hospedado, uma lista de fornecedores e opções de dimensionamento para cada combinação. ;)

Sim, dimensionar horizontalmente significa adicionar mais máquinas, mas também implica que as máquinas são iguais no cluster. O MySQL pode ser escalonado horizontalmente em termos de leitura de dados, através do uso de réplicas, mas assim que atingir a capacidade do disco / mem do servidor, é necessário começar a compartilhar dados entre os servidores. Isso se torna cada vez mais complexo. Muitas vezes, manter os dados consistentes nas réplicas é um problema, pois as taxas de replicação costumam ser muito lentas para acompanhar as taxas de alteração de dados.

O Couchbase também é um fantástico banco de dados NoSQL Horizontal Scaling, usado em muitos aplicativos e jogos comerciais de alta disponibilidade e, sem dúvida, o melhor desempenho da categoria. Ele particiona os dados automaticamente no cluster, a adição de nós é simples e você pode usar hardware comum, instâncias vm mais baratas (usando Large em vez de High Mem, máquinas High Disk na AWS, por exemplo). É construído fora do Membase (Memcached), mas adiciona persistência. Além disso, no caso do Couchbase, todos os nós podem fazer leituras e gravações e são iguais no cluster, com apenas replicação de failover (não replicação completa do conjunto de dados em todos os servidores, como no mySQL).

Em termos de desempenho, você pode ver um excelente benchmark da Cisco: http://blog.couchbase.com/understanding-performance-benchmark-published-cisco-and-solarflare-using-couchbase-server

Aqui está uma excelente publicação sobre o Couchbase Architecture: http://horicky.blogspot.com/2012/07/couchbase-architecture.html

Os bancos de dados relacionais tradicionais foram projetados como sistemas de banco de dados cliente / servidor. Eles podem ser redimensionados horizontalmente, mas o processo para fazer isso tende a ser complexo e propenso a erros. Os bancos de dados NewSQL, como o NuoDB, são sistemas de banco de dados distribuídos centrados na memória, projetados para expandir horizontalmente, mantendo as propriedades SQL / ACID do RDBMS tradicional.

Para obter mais informações sobre o NuoDB, leia o white paper técnico .

Os bancos de dados SQL como Oracle, db2 também suportam o dimensionamento horizontal por meio do cluster de disco compartilhado. Por exemplo, Oracle RAC, IBM DB2 purescale ou Sybase ASE Cluster edition. É possível incluir um novo nó no sistema Oracle RAC ou no sistema em escala de cores do DB2 para obter a escala horizontal.

Mas a abordagem é diferente dos bancos de dados noSQL (como mongodb, CouchDB ou IBM Cloudant) é que o compartilhamento de dados não faz parte do dimensionamento horizontal. Nos bancos de dados noSQL, os dados são agrupados durante o dimensionamento horizontal.

Você tem uma empresa e há apenas 1 trabalhador, mas você tem um novo projeto no momento em que contrata um novo candidato - esse é o dimensionamento horizontal. onde novo candidato são novas máquinas e projeto é novo tráfego / chamadas para suas APIs.

Onde, como um projeto, com um funcionário do IIT / NIT que lida com todas as solicitações do seu API / tráfego. Se, a qualquer momento, solicitar mais às suas APIs, demiti-lo e substituí-lo por um cara com alto QI NIT / IIT - esse é o dimensionamento vertical.

A adição de muitos balanceadores de carga cria sobrecarga e latência extras, e essa é a desvantagem de expandir horizontalmente nos bancos de dados nosql. É como a pergunta por que as pessoas dizem que o RPC não é recomendado, pois não é robusto.

Penso que, em um sistema real, devemos usar os bancos de dados sql e nosql para utilizar os recursos de computação multicore e em nuvem dos sistemas atuais.

Por outro lado, consultas transacionais complexas têm alto desempenho se bancos de dados sql, como o oracle, estiverem sendo usados. O NoSql pode ser usado para bigdata e escalabilidade horizontal por sharding.

A resposta aceita é pontual na definição básica de escala horizontal versus vertical. Mas, diferentemente da crença comum de que o dimensionamento horizontal de bancos de dados só é possível com Cassandra, MongoDB, etc. Gostaria de acrescentar que o dimensionamento horizontal também é muito possível com qualquer RDMS tradicional; isso também sem usar soluções de terceiros.

Conheço muitas empresas, especialmente empresas baseadas em SaaS que fazem isso. Isso é feito usando a lógica simples do aplicativo. Você basicamente pega um conjunto de usuários e os divide em vários servidores de banco de dados. Assim, por exemplo, você normalmente teria um banco de dados / tabela "meta" que armazenaria clientes, servidor de banco de dados / cadeias de conexão etc. e uma tabela que armazena o mapeamento de cliente / servidor.

Em seguida, basta direcionar as solicitações de cada cliente ao servidor de banco de dados para o qual elas são mapeadas.

Agora, alguns podem dizer que isso é semelhante ao particionamento horizontal e não à escala horizontal "verdadeira" e eles estarão certos de algumas maneiras. Mas o resultado final é que você escalou seu banco de dados em vários servidores Db.

A única diferença entre as duas abordagens para o dimensionamento horizontal é que uma abordagem (MongoDB, etc) é feita pelo próprio software DB. Nesse sentido, você está "comprando" a escala. Na outra abordagem (para escala horizontal RDBMS), a escala é criada pelo código / lógica do aplicativo.