Que tipos de sistemas precisam "aumentar a escala" em vez de "expandir"?

Há muito tempo que me pergunto se existem sistemas que precisam ser "escalonados" (para um servidor mais poderoso e mais caro), em vez de "escalonados", divididos em muitos servidores menores.

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

Como o aumento parece trazer custos de hardware muito mais altos do que o dimensionamento, parece que você gostaria de evitar, se possível, mas não tenho certeza se é sempre evitável ou não.

Então, existem sistemas que não podem ser escalonados e precisam ser escalados? 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?)

Eu trabalho principalmente com um aplicativo que tem 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 "escalar" em sistemas progressivamente maiores, a fim de acomodar cargas de trabalho crescentes do usuário.

Muitos aplicativos transacionais e de linha de negócios herdados têm esses tipos de restrições. É uma das razões pelas quais enfatizo que o foco do setor 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 expansão que eu descrevo são realmente não-sexuais , 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 ).

Do ponto de vista do desenvolvedor, posso dizer que quase todos os mecanismos tradicionais de banco de dados existentes no mercado só podem ser ampliados e ampliados.

Nos últimos anos, com a necessidade de maior escalabilidade e sistemas altamente disponíveis, houve esforços para aumentar a escala dos bancos de dados existentes. Mas, como os designs são prejudicados pelo código legado, é muito mais importante do que fundamental para o design. Você encontrará isso se tentar dimensionar a maioria dos mecanismos de banco de dados conhecidos. A adição de servidores escravos pode ser bastante difícil de configurar e você notará que ele possui limitações significativas, algumas das quais podem exigir uma nova alteração nas tabelas do banco de dados.

Por exemplo, a maioria deles é mestre / (multi) escrava, em vez de projetos com vários mestres. Em outras palavras, você pode ter apenas um servidor inteiro sentado lá e não conseguir processar consultas. Alguns o fazem, mas com limitações ... por exemplo, leia apenas o projeto multi-escravo. Portanto, você pode ter um servidor que recebe gravações e todos os outros fornecem dados somente leitura. Você notará que, ao configurar esses sistemas, nem sempre é um processo direto e difícil de funcionar bem. Em muitos casos, parece muito mais um acréscimo.

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

Portanto, parece que a melhor maneira de obter melhor desempenho de um servidor SQL tradicional é aumentar a escala! Enquanto no NOSQL e NewSQL, ambos aumentam e aumentam.

A razão pela qual os sistemas RDBMS tradicionais são fortemente acoplados é porque todos eles precisam de uma visualizaçã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 através de algum tipo de mecanismo de bloqueio exige cooperação de outros servidores que prejudicam o desempenho ou afetam 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 a carga de trabalho estar espalhada pelos servidores e não apenas entre processos ou threads em que o acesso aos dados ainda é bastante rápido.

Na minha opinião, a demarcação de escala para cima / para fora é determinada de quão paralelo um fluxo de trabalho pode ser e com que firmeza os segmentos paralelos precisam se coordenar.

Encadeamento único
Por qualquer motivo, esse fluxo de trabalho pode funcionar apenas em um único encadeamento.

Um meio de rosca um meio de sistema dimensionar -se para torná-lo ir mais rápido.

Paralelismo firmemente acoplado
Este é um sistema multiencadeado em que os encadeamentos precisam ser acoplados firmemente entre si. Talvez a comunicação entre processos precise ser muito rápida ou tudo precise ser gerenciado através de um único gerenciador de memória. A maioria dos sistemas RDBMS é esse tipo de computação paralela.

Para a maior parte, estes sistemas são aqueles que escala até melhor do que fora embora haja exceções. Por exemplo, fluxos de trabalho que funcionariam em um cluster no estilo Imagem de sistema único, espaço de memória único, mas alta latência entre threads, podem facilitar o dimensionamento. Mas esses sistemas SSI são muito difíceis de trabalhar, para que a maioria dos engenheiros apenas faça uma caixa maior.

Paralelismo fracamente acoplado
Este é um sistema multiencadeado / de processo em que os encadeamentos são aceitáveis ​​com altas latências entre si. Ou não precisam conversar um com o outro. Servidores da Web e farms de renderização ampliados são exemplos clássicos desse tipo de sistema. Sistemas como esses são muito mais fáceis de criar do que um paralelismo maior que o de acoplamentos estreitos, e é por isso que há muita empolgação nesse estilo de sistema.

Este é o estilo onde a escala para fora é muito mais fácil.