Utilização de Servidores: Couchbase vs MongoDB

Quando comecei a usar o MongoDB em 2012 como o cara de operações e arquitetura, eu tinha alguns problemas importantes com a forma como ele é arquitetado. Com o passar do tempo, observei outras pessoas enfrentando desafios semelhantes. Um problema fundamental é que o MongoDB não utiliza totalmente o poder dos servidores/instâncias que possui, por design. Eu detesto provisionar três bons servidores/instâncias, mas ver que a aplicação só usa realmente uma fração dos recursos. É isso que o MongoDB faz. Você só pode gravar no nó primário em um conjunto de réplicas. Depois, para escalar leituras, você precisa ler a partir dos nós secundários, e essas leituras podem ser eventualmente consistentes. Se você precisar de consistência total, só poderá interagir com o nó primário de um conjunto de réplicas.

Por outro lado, o Couchbase permite que você faça a escalabilidade horizontal, vertical ou ambas. Você não terá servidores subutilizados por design. Todos os servidores no cluster contribuem para o desempenho da aplicação E ainda oferecem alta disponibilidade.

Então vamos mergulhar de cabeça e ver como os dois bancos de dados lidam com isso.

Escalando com o MongoDB

Na raiz do problema está a arquitetura “Master-Slave” do MongoDB. Se você tiver três servidores físicos, por exemplo, e executar um cluster do MongoDB como um conjunto de réplicas (com a recomendada um instância do MongoDB por servidor), a aplicação só pode gravar em um desses três servidores, aquele que executa o Primário. Os outros dois servidores no conjunto de réplicas são puramente escravos (“secundários” nos termos do MongoDB) e estão lá apenas no caso de o Primário cair. Você certamente poderia ler dados desses dois secundários para dimensionar as leituras, mas então suas leituras não seriam mais fortemente consistentes. Portanto, na abordagem recomendada pelo MongoDB, esses servidores secundários são subutilizados (fora das tarefas de manutenção em segundo plano do banco de dados) e mal apreciados pela aplicação.

À medida que os servidores secundários solitários permanecem lá, eles devem ser configurados com os mesmos recursos do Primário, caso sejam necessários para tornar-se a Primary. Enquanto isso, elas são mal utilizadas pela sua aplicação. Depois, digamos que o seu site esteja indo fantasticamente bem, mas o desempenho do banco de dados está começando a sofrer um pouco e as gravações estão demorando mais do que o seu SLA permite. Agora é hora de escalar! Com o MongoDB, você precisa adicionar no mínimo outro quatro mas a melhor prática é seis servidores. De acordo com as melhores práticas do MongoDB, você precisa adicionar outro conjunto de réplicas (Shard #2). São três servidores, mas além disso há os servidores de configuração que armazenam as informações sobre a localização de cada documento; portanto, de acordo com as melhores práticas, isso significa três mais servidores.

Bem, pelo menos com todos esses novos servidores você terá muito mais largura de banda para gravações, certo? Não tão rápido! Mesmo adicionando mais seis servidores, agora você só pode gravar em até dois servidores, e não em nove. Você tem o Primário original (conjunto de réplicas #1) e agora um novo Primário (conjunto de réplicas #2). Com tudo isso, a única coisa que você conseguiu foi aumentar significativamente a complexidade e a sobrecarga de manutenção do seu cluster. Se precisar adicionar outro shard para obter mais desempenho de gravação, você precisará adicionar outro três nós. Sua aplicação nem sequer chega a usar dois de cada um desses servidores em cada conjunto de réplicas.

Uma maneira de contornar a subutilização de servidores bare metal que tenho observado é colocar muitos e muitos processos mongod no mesmo servidor, contrariando as próprias recomendações do Mongo Recomendações. Deixando de lado os problemas de desempenho, e mesmo que servidores virtuais sejam usados, o que acontece quando um dos nós cai? Quantas instâncias primárias e secundárias você perderá? Você tem acompanhado onde estão todas as instâncias primárias e secundárias para garantir que um conjunto de réplicas esteja adequadamente distribuído pelos servidores no cluster para suportar isso? Você fala sobre aumentar a complexidade, meu Deus, isso com certeza faz isso!

Escalonando com o Couchbase

Vamos analisar o mesmo cenário de três servidores que discuti acima, mas desta vez pensando no Couchbase. Sua aplicação pode ler e gravar em discos isolados, memória, rede, núcleos de CPU, etc., em todos os três servidores. No Couchbase, seus dados são distribuídos uniformemente entre os três servidores e replicados entre eles. O SDK do Couchbase que sua aplicação usa sabe como acessar seus dados, onde estão os serviços do Couchbase no cluster e como acessar todos eles. Vamos pegar o mesmo cenário de escalabilidade acima e ver suas opções no Couchbase. Você pode adicionar rapidamente outro servidor ao cluster com dois cliques no Console de Administração OU com um comando de CLI.

$> /opt/couchbase/bin/couchbase-cli rebalance 
    -c :8091 
    --server-add=:8091 
    -u Administrator -p

Compare isto com o etapas necessárias para adicionar um conjunto de réplicas ao MongoDB. Com o Couchbase, quando você precisa de mais capacidade, basta adicionar mais um ou dois servidores e, em seguida, fazer o rebalanceamento. Na semana que vem, se precisar de mais capacidade, você pode adicionar mais e rebalancear novamente. Viu como isso é fácil? Suas aplicações estão sempre usando todos dos servidores no cluster. Você nem precisa alterar sua aplicação e pode adicionar um ou mais servidores a qualquer momento que desejar, sem tempo de inatividade. O resultado final é que você não está desperdiçando servidores ou recursos de servidores. Você pode usar cada pedaço de cada um dos servidores, se quiser, e escalar horizontalmente. Você pode escrever sua aplicação em um nó do Couchbase no seu computador e implantá-la em um cluster do tamanho que for em produção, sem esforço adicional.

O Couchbase também tem dados de réplica, é claro, mas os dados de réplica são usados apenas para Alta Disponibilidade. Por que abrir mão da consistência em prol do desempenho como no MongoDB, quando você pode ter ambos no Couchbase? E quando se trata de reduzir a complexidade ao usar VMs com o Couchbase, você pode usar a Consciência de Rack/Zona (Rack/Zone Awareness).

Abaixo está uma rápida comparação visual do que estamos falando aqui. Note que, no cluster do MongoDB com todos esses servidores, há apenas três servidores nos quais você pode gravar dos quatorze listados. 

 

Compare isso com o lado do Couchbase e você verá o quanto isso é realmente mais simples, limpo e fácil de gerenciar. Para mais informações sobre esse assunto, consulte Postagem do blog de Manuel Hurtado Isso contrasta a configuração de um cluster pronto para produção em Couchbase versus MongoDB. Há também comparações arquitetônicas independentes de terceiros que abordam o problema, como esta.

Resumo

Se já não for óbvio até agora, o MongoDB tem alguns problemas sérios em como uma aplicação pode utilizar totalmente todos esses servidores/instâncias caros. Sim, existem algumas soluções alternativas, mas a maioria dos profissionais de operações desaconselhará esse tipo de empilhamento; mesmo com virtualização, ir a esse nível de densidade simplesmente não é uma boa ideia. Além de tudo isso, isso não é algo que o MongoDB provavelmente vá consertar tão cedo, já que está enraizado em sua arquitetura principal. O Couchbase, por outro lado, foi arquitetado para utilizar totalmente cada servidor que você lhe der, distribuindo os dados e a carga de maneira uniforme pelo cluster. Tudo isso com facilidade de gerenciamento e a capacidade de operar em qualquer escala.

A utilização do servidor é uma questão importante porque os custos combinados de licenças de banco de dados, hardware, despesas gerais de gerenciamento e custos de instalações podem rapidamente sair do controle. Para colocar alguns números nisso, deixando de lado as despesas gerais de gerenciamento, custa mais de $700 por ano apenas para alimentar (o que não é nada legal) um servidor comum em seu próprio data center. E se você optar por usar a nuvem para obter capacidade, o custo total pode chegar a $8-10.000 por instância, por ano. Portanto, este é verdadeiramente um exemplo em que as considerações arquiteturais podem ter implicações significativas de custo e complexidade. Portanto, se você estiver disposto, vá baixar Carregue o Couchbase e veja como é fácil extrair todo o potencial desses servidores e do próprio Couchbase.