Utilização do servidor: Couchbase vs MongoDB

Quando comecei a usar o MongoDB em 2012, como responsável pelas operações e pela arquitetura, tive alguns problemas importantes com a forma como ele foi arquitetado. Com o passar do tempo, observei que outras pessoas tinham desafios semelhantes. Um problema fundamental é que o MongoDB não utiliza totalmente o poder dos servidores/instâncias que possui, por design. Detesto provisionar três bons servidores/instâncias, mas depois o aplicativo só usa realmente uma fração dos recursos. É isso que o MongoDB faz. Você só pode gravar no primário em um conjunto de réplicas. Então, para escalonar as leituras, é preciso ler nos nós secundários, e essas leituras podem ser eventualmente consistentes. Se você precisa ter consistência total, só pode interagir com o nó primário de um conjunto de réplicas.

O Couchbase, por outro lado, permite que você dimensione para fora, para cima ou ambos. Você não terá servidores subutilizados por design. Todos os servidores do cluster estão contribuindo para o desempenho do aplicativo E ainda oferecem alta disponibilidade.

Então, vamos nos aprofundar e ver como esses dois bancos de dados lidam com isso.

Dimensionamento com o MongoDB

Na raiz do problema está a arquitetura "mestre-escravo" do MongoDB. Se você tem três servidores físicos, por exemplo, e executa um cluster do MongoDB como um conjunto de réplicas (com a opção recomendada um instância do MongoDB por servidor), o aplicativo só pode gravar em um desses três servidores, o que está executando o Primário. Os outros dois servidores no conjunto de réplicas são puramente escravos ("secundários" em termos de MongoDB) e só estão lá no caso de o primário ficar inativo. Você certamente poderia ler os dados desses dois secundários para escalonar as leituras, mas, nesse caso, suas leituras não seriam mais consistentes. Portanto, na abordagem recomendada pelo MongoDB, esses servidores secundários são subutilizados (fora das tarefas de manutenção do banco de dados em segundo plano) e pouco apreciados pelo aplicativo.

Como os servidores secundários solitários ficam lá, eles devem ser configurados com os mesmos recursos que o primário, caso sejam necessários para tornar-se uma Primária. Enquanto isso, eles são pouco utilizados pelo seu aplicativo. Então, digamos que seu site esteja funcionando muito 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 permitido pelo seu SLA. Agora é hora de escalonar! Com o MongoDB, você precisa adicionar no mínimo outro quatro mas a melhor prática é seis servidores. De acordo com as práticas recomendadas do MongoDB, você precisa adicionar outro conjunto de réplicas (Shard #2). São três servidores, mas há os servidores de configuração que contêm as informações sobre onde cada documento está localizado; portanto, de acordo com as práticas recomendadas, são três mais servidores.

Bem, pelo menos com todos esses novos servidores, você terá muito mais taxa de transferência para gravações, certo? Não tão rápido! Mesmo com a adição de mais seis servidores, agora você tem apenas dois servidores para gravar, e não nove. Você tem o Primário original (conjunto de réplicas #1) e agora um novo Primário (conjunto de réplicas #2). Tudo isso e tudo o que você fez foi aumentar significativamente a complexidade e a sobrecarga de manutenção do seu cluster. Se precisar adicionar outro fragmento para obter mais desempenho de gravação, você precisará adicionar outro três nós. Seu aplicativo nem chega a jogar com dois de cada um desses servidores em cada conjunto de réplicas.

Uma maneira de contornar a subutilização de servidores bare metal que observei é colocar muitos e muitos processos mongod no mesmo servidor, contra o próprio recomendações. Problemas de desempenho à parte, e mesmo que sejam usados servidores virtuais, o que acontece quando um dos nós fica inoperante? Quantos primários e secundários você perderá? Você já controlou onde estão todos os primários e secundários para garantir que um conjunto de réplicas esteja adequadamente distribuído entre os servidores do cluster para resistir a isso? Se você fala em aumentar a complexidade, isso faz muito bem!

Dimensionamento com o Couchbase

Vamos dar uma olhada no mesmo cenário de três servidores que discuti acima, mas desta vez com o Couchbase em mente. Seu aplicativo pode ler e gravar em todos os três servidores com discos isolados, memória, rede, núcleos de CPU etc. No Couchbase, seus dados são distribuídos uniformemente entre os três servidores e replicados entre eles. O SDK do Couchbase que seu aplicativo usa sabe como acessar seus dados, onde os serviços do Couchbase estão no cluster e como acessá-los. Vamos usar o mesmo cenário de dimensionamento acima e ver suas opções no Couchbase. Você pode adicionar rapidamente outro servidor ao cluster com dois cliques no Admin Console OU com um comando da CLI.

Compare isso com o etapas necessárias para adicionar um conjunto de réplicas com o MongoDB. Com o Couchbase, quando você precisa de mais capacidade, basta adicionar mais um ou dois servidores e, em seguida, fazer o rebalanceamento. Na próxima semana, se precisar de mais capacidade, você pode adicionar mais e reequilibrar novamente. Está vendo como isso é fácil? Seus aplicativos estão sempre usando todos dos servidores no cluster. Você não precisa nem mesmo alterar seu aplicativo e pode adicionar um ou mais servidores a qualquer momento, sem tempo de inatividade. O resultado final é que você não está desperdiçando servidores ou recursos de servidor. Você pode usar cada parte de cada um dos servidores, se quiser, e escalonar horizontalmente. Você pode escrever seu aplicativo em um nó do Couchbase em seu computador e implantá-lo em um cluster de produção do tamanho que desejar, sem nenhum esforço extra.

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 obter ambos no Couchbase? E quando se trata de reduzir a complexidade, se você quiser usar VMs com o Couchbase, poderá usar o Rack/Zone Awareness.

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

Compare isso com o lado do Couchbase e você verá como ele é muito mais simples, limpo e fácil de gerenciar. Para obter mais informações sobre essas linhas, consulte Postagem no blog de Manuel Hurtado que compara a configuração de um cluster pronto para produção no Couchbase com a do MongoDB. Há também comparações arquitetônicas independentes de terceiros que abordam o problema, como este.

Resumo

Se não estiver óbvio até agora, o MongoDB tem alguns problemas sérios sobre como um aplicativo pode utilizar totalmente todos esses servidores/instâncias caros. Sim, existem algumas soluções alternativas, mas a maioria das pessoas de operações desaconselhará esse tipo de empilhamento; mesmo com a virtualização, não é uma boa ideia usar essa densidade. Além de tudo isso, não é algo que o MongoDB provavelmente consertará tão cedo, pois está embutido em sua arquitetura principal. O Couchbase, por outro lado, foi arquitetado para utilizar totalmente todos os servidores que você fornecer a ele, distribuindo os dados e a carga uniformemente 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 em torno disso, além da sobrecarga de gerenciamento, custa mais de $700 por ano apenas para alimentar (não resfriar) um servidor comum de commodity 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, esse é realmente um exemplo em que as considerações arquitetônicas podem ter implicações significativas em termos de custo e complexidade. Portanto, se você estiver disposto a isso, fazer download Couchbase, carregue-o e veja como é fácil extrair a potência desses servidores e do próprio Couchbase.