Que tipos de sistemas precisam “escalar” em vez de “escalar”?

Question

Eu tenho me perguntado por um longo tempo se existem sistemas que precisam "escalar" (em um servidor mais poderoso e mais caro) em vez de "escalar" ao serem divididos em muitos servidores menores.

Esses sistemas existem e, em caso afirmativo, há algo em particular que tende a fazer com que os sistemas precisem ser ampliados, em vez de redimensionados? (Por exemplo, talvez as transações do banco de dados de reclamação do ACID ou outros requisitos de integridade de dados strongs criem essa necessidade.)

Como a ampliação parece que traria custos de hardware muito maiores do que o dimensionamento, parece algo que você gostaria de evitar, se possível, mas não tenho certeza se é sempre evitável ou não.

Existem sistemas que não podem ser dimensionados e precisam ser ampliados? O que pode causar isso e como você identificaria esse sistema? (Eles geralmente compartilham algumas características em comum que podem torná-los mais facilmente identificáveis?)

    

Answer 1

Trabalho principalmente com um aplicativo que tenha zero potencial de escala horizontal . Embora seja executado no Linux, o aplicativo, as estruturas de dados e os requisitos de E / S me forçam a "expandir" para sistemas progressivamente maiores, a fim de acomodar cargas de trabalho de usuários maiores.

Muitos aplicativos de linha de negócios e transacionais herdados têm esses tipos de restrições. É uma das razões pelas quais enfatizo que o foco da indústria em soluções em nuvem e arquiteturas em escala da Web orientadas por DevOps ignora uma boa porcentagem do mundo da computação.

Infelizmente, os sistemas de scale-up que eu descrevo são realmente não visuais , então a indústria tende a ignorar seu valor ou a enfatizar as habilidades necessárias para lidar com sistemas grandes e críticos (por exemplo gado versus animais de estimação ).

    

Answer 2

De uma perspectiva de desenvolvedor, posso dizer que quase todos os mecanismos tradicionais de banco de dados tradicionais que podem ser expandidos e expandidos são apenas um pós-pensamento.

Nos últimos anos, com a necessidade de maior escalabilidade e sistemas altamente disponíveis, houve esforços para fazer com que os bancos de dados existentes se expandissem. Mas como os designs são prejudicados pelo código legado, ele é muito mais apegado do que fundamental ao design. Você encontrará isso se tentar escalar a maioria dos mecanismos de banco de dados conhecidos. Adicionando servidores escravos pode ser bastante difícil de configurar e você perceberá que ele vem com limitações significativas, algumas das quais podem requerer o re-jigging de suas tabelas de banco de dados.

Por exemplo, a maioria deles são projetos mestre / (multi) escravo e não multi-mestre. Em outras palavras, você pode ter apenas um servidor inteiro ali parado e não conseguir processar consultas. Alguns fazem, mas com limitações ... por exemplo leia somente design multi-escravo. Portanto, você pode ter um servidor que usa gravações e todos os outros fornecem dados somente leitura. Você perceberá que ao configurar esses sistemas nem sempre é um processo direto e difícil de funcionar bem. Parece muito mais um parafuso em muitos casos.

Por outro lado, existem alguns mecanismos de banco de dados mais recentes sendo desenvolvidos com simultaneidade e design de vários mestres desde o início. NOSQL e NewSQL são a nova classe de design.

Assim, parece que a melhor maneira de obter um melhor desempenho de um servidor SQL tradicional é aumentar de escala! Enquanto com NOSQL & NewSQL é tanto scale up & expandir.

A razão pela qual os sistemas RDBMS tradicionais estão strongmente acoplados é porque todos eles precisam de uma visão consistente dos mesmos dados. Quando você tem vários servidores aceitando atualizações para os mesmos dados de clientes diferentes, em qual deles você confia? Qualquer método que tente garantir que os dados sejam consistentes por meio de algum tipo de mecanismo de bloqueio requer a cooperação de outros servidores que prejudiquem o desempenho ou afetem a qualidade dos dados, pois quaisquer dados lidos de um cliente podem estar desatualizados. E os servidores precisam decidir entre si quais dados são mais recentes ao gravar no mesmo registro. Como você pode ver, é um problema complexo que se torna mais complexo pelo fato de que a carga de trabalho é distribuída entre os servidores e não apenas entre processos ou encadeamentos onde o acesso aos dados ainda é bastante rápido.

    

Answer 3

Na minha opinião, a demarcação scale up / out é determinada em quão paralelo um fluxo de trabalho pode ser, e com que precisão os threads paralelos precisam se coordenar entre si.

Single Threaded
Por qualquer motivo, esse fluxo de trabalho só pode funcionar em um único thread.

Um segmento significa que um sistema significa dimensionar para cima para torná-lo mais rápido.

Paralelismo strongmente acoplado
Este é um sistema multi-threaded onde os segmentos precisam ser bem acoplados uns com os outros. Talvez a comunicação entre processos precise ser muito rápida, ou tudo precisa ser gerenciado por meio de um único gerenciador de memória. A maioria dos sistemas RDBMS é esse tipo de computação paralela.

Na maior parte, esses sistemas são aqueles que escalam up melhor que out , embora existam exceções. Por exemplo, os fluxos de trabalho que funcionariam em um cluster de estilo Imagem de sistema único , espaço de memória único, mas alta latência entre os segmentos, podem fazer dimensionamento mais fácil. Mas esses sistemas SSI são muito complicados de trabalhar, então a maioria dos engenheiros cria uma caixa maior.

Paralelismo de baixo acoplamento
Este é um sistema multi-threaded / processo onde os threads são OK com altas latências entre si. Ou não precisa falar um com o outro. Os servidores web e de renderização em escala são exemplos clássicos desse tipo de sistema. Sistemas como esses são muito mais fáceis de fazer do que o paralelismo strongmente acoplado, e é por isso que há muita empolgação com esse estilo de sistema.

Este é o estilo em que a escala out é muito mais fácil.