Diferença entre escalar horizontalmente e verticalmente para bases de dados
9 answers
A escala Horizontal significa que você escala, adicionando mais máquinas em seu pool de recursos considerando escala Vertical significa que você escala, adicionando mais poder (CPU, memória RAM) para uma máquina existente.
Uma maneira fácil de lembrar isto é pensar numa máquina num suporte de servidor, adicionamos mais máquinas ao longo da direcçãohorizontal e adicionamos mais recursos a uma máquina na direcçãovertical .
Numa base de dados, a escala horizontal mundial baseia-se frequentemente no particionamento dos dados, ou seja, cada nó contém apenas uma parte dos dados, na escala vertical os dados residem num único nó e a escala é feita através do multi-núcleo, ou seja, espalhando a carga entre os recursos da CPU e da RAM dessa máquina.
Com a escala horizontal, é muitas vezes mais fácil escalar dinamicamente adicionando mais máquinas à escala vertical existente. capacidade de uma única máquina, escalando além dessa capacidade muitas vezes 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, mudando de máquinas pequenas para máquinas maiores. Este processo muitas vezes envolve tempo de inatividade.
Redes de dados em memória tais como GigaSpaces XAP, coerência etc.. são muitas vezes otimizados para escalar horizontal e vertical simplesmente porque eles não estão ligados ao disco. Dimensionamento Horizontal através de particionamento e dimensionamento vertical através de suporte multi-core.
Você pode ler mais sobre este assunto em meus posts anteriores: escala Versus escala e os princípios comuns por trás das alternativas NOSQL
Escalabilidade Horizontal é a capacidade de aumentar a capacidade conectando múltiplas entidades de hardware ou software para que elas funcionem como uma única unidade lógica.
Quando os servidores são agrupados, o servidor original está a ser dimensionado horizontalmente. Se um cluster requer mais recursos para melhorar o desempenho e fornecer alta disponibilidade (HA), um administrador pode escalar adicionando mais servidores ao cluster.
Uma vantagem importante da escalabilidade horizontal é que pode fornecer aos administradores a capacidade de aumentar a capacidade no momento. Outra vantagem é que, em teoria, a escalabilidade horizontal é apenas limitada por quantas entidades podem ser conectadas com sucesso. O sistema de armazenamento distribuído Cassandra, por exemplo, funciona em cima de centenas de nós de commodities espalhados por diferentes centros de dados. Como o hardware de commodity é dimensionado horizontalmente, Cassandra é tolerante a falha e não tem um único ponto de falha (SPoF).A escalabilidade Vertical, por outro lado, aumenta a capacidade adicionando mais recursos, como mais memória ou uma CPU adicional, a uma máquina. Escalar verticalmente, que também é chamado de escalar acima, geralmente requer tempo de inatividade enquanto novos recursos estão sendo adicionados e tem limites que são definidos por hardware. Quando os clientes da Amazon RDS precisam escalar verticalmente, por exemplo, eles podem mudar de uma máquina menor para uma maior, mas a maior instância da Amazon RDS tem apenas 68 GB de memoria.
Escalar horizontalmente tem ambas as vantagens e desvantagens. Por exemplo, a adição de baratos mercadoria computadores para um cluster pode parecer uma solução de custo eficaz, à primeira vista, mas é importante para o administrador para saber se os custos de licenciamento para aqueles servidores adicionais, operações adicionais de custo de alimentar e de refrigeração e a grande superfície que vai ocupar o centro de dados verdadeiramente torna a escala horizontal de uma escolha melhor do que a escala verticalmente.
SIM escalar horizontalmente significa adicionar mais máquinas, mas também implica que as máquinas são iguais no conjunto. MySQL pode escalar horizontalmente em termos de leitura de dados, através do uso de réplicas, mas uma vez que ele atinge a capacidade do mem/disco servidor, você tem que começar a sharding dados através de servidores. Isto torna-se cada vez mais complexo. Muitas vezes, manter os dados consistentes entre réplicas é um problema, pois as taxas de replicação são muitas vezes muito lentas para acompanhar as taxas de mudança de dados.
O Couchbase é também um fantástico Banco de dados de escala Horizontal NoSQL, utilizado em muitas aplicações e jogos comerciais de alta disponibilidade e, sem dúvida, o maior artista da categoria. Ele distribui dados automaticamente através do cluster, adicionando nós é simples, e você pode usar hardware commodity, instâncias vm mais baratas (usando grande em vez de alta Mem, máquinas de disco de alta na AWS, por exemplo). É construída a partir da Membase (Memcached), mas adiciona persistência. Além disso, no caso da Couchbase, node pode fazer leituras e escritas, e são iguais no cluster, com apenas replicação de failover (não replicação completa de conjunto de dados em todos os servidores como em mySQL). Em termos de desempenho, pode ver uma excelente referência da Cisco: http://blog.couchbase.com/understanding-performance-benchmark-published-cisco-and-solarflare-using-couchbase-server Aqui está um ótimo post no blog sobre arquitetura Couchbase: http://horicky.blogspot.com/2012/07/couchbase-architecture.htmlBases de dados relacionais tradicionais, quando concebidas como Sistemas de bases de dados cliente/servidor. Eles podem ser dimensionados horizontalmente, mas o processo para fazê-lo tende a ser complexo e propenso a erros. Bases de dados NewSQL likeNuoDB são sistemas de banco de dados distribuídos centrados na memória projetados para escalar horizontalmente, mantendo as propriedades SQL/ácido dos RDBMS tradicionais.
Para mais informações sobre o NuoDB, leia o seu papel técnico em http://goo.gl/uzLIWB.
Vamos começar com a necessidade de escala que está aumentando os recursos para que o seu sistema possa agora lidar com mais pedidos do que poderia antes .
Quando você percebe , seu sistema está ficando lento , e é incapaz de lidar com o número atual de pedidos, você precisa escalar o sistema .
Isto dá-lhe duas opções , ou aumenta os recursos no servidor que está a usar actualmente , I. E. , aumenta a quantidade de ram, cpu, gpu e outros recursos.Isto é ... conhecido como escala vertical .
A escala Vertical é tipicamente dispendiosa . Isso não torna o sistema tolerante a falhas, ou seja, se você estiver escalando aplicação executando com um único servidor, se esse servidor for abaixo, o seu sistema irá abaixo . Também a quantidade de threads permanece a mesma na escala vertical . A escala Vertical pode exigir que o seu sistema desça por um momento em que o processo ocorra . Aumentar os recursos num servidor requer reiniciar e desligar o seu sistema .
Outra solução para este problema é aumentar a quantidade de servidores presentes no sistema . Esta solução é altamente utilizada na indústria de tecnologia . Isto irá eventualmente diminuir o pedido por segunda taxa em cada servidor . Se você precisa escalar o sistema , basta adicionar outro servidor, e você está feito . Você não seria obrigado a reiniciar o sistema . Número de threads em cada sistema diminui levando a alta produtividade . Separar os pedidos, igualmente para cada um dos pedidos servidor, você precisa adicionar balancer de carga que atuaria como proxy reverso para os servidores web . Todo este sistema pode ser chamado como um único conjunto . Seu sistema pode conter um grande número de pedidos que exigiriam mais quantidade de clusters como este .
Espero que consigas todo o conceito de introduzir escala no sistema.Bases de dados SQL como Oracle, db2 também suportam a escala Horizontal através de um conjunto de discos partilhados. Por exemplo, Oracle RAC, IBM DB2 purescale ou Sybase ASE Cluster edition. Novo nó pode ser adicionado ao sistema RAC Oracle ou sistema DB2 purescale para alcançar escala horizontal.
Mas a abordagem é diferente das bases de dados noSQL (como mongodb, CouchDB ou IBM Cloudant) é que o sharding de dados não faz parte da escala Horizontal. Nas bases de dados noSQL, os dados são shraded durante a horizontal escala.
Todas as outras respostas parecem já bastante completas, mas eu não vi o Google Cloud Spanner como um exemplo de um banco de dados relacional com escala horizontal, é por isso que estou adicionando minha pequena contribuição.
Adicionar muitos balancers de carga cria sobrecarga extra e latência e essa é a desvantagem para escalar horizontalmente em bases de dados nosql. É como a pergunta por que as pessoas dizem que RPC não é recomendado, uma vez que não é robusto.
Acho que num sistema real devemos usar as bases de dados sql e nosql para utilizar as capacidades de computação em nuvem e multicore dos sistemas actuais.Por outro lado, as consultas transacionais complexas têm um elevado desempenho se as bases de dados sql como oráculo a ser usado. NoSql poderia ser usado para bigdata e escalabilidade horizontal por sharding.