\u00c0 medida que os servidores secund\u00e1rios solit\u00e1rios permanecem l\u00e1, eles devem ser configurados com os mesmos recursos do Prim\u00e1rio, caso sejam necess\u00e1rios para tornar-se<\/i> a Primary. Enquanto isso, elas s\u00e3o mal utilizadas pela sua aplica\u00e7\u00e3o. Depois, digamos que o seu site esteja indo fantasticamente bem, mas o desempenho do banco de dados est\u00e1 come\u00e7ando a sofrer um pouco e as grava\u00e7\u00f5es est\u00e3o demorando mais do que o seu SLA permite. Agora \u00e9 hora de escalar! Com o MongoDB, voc\u00ea precisa adicionar no m\u00ednimo<\/i> outro quatro<\/i> mas a melhor pr\u00e1tica \u00e9 seis<\/i> servidores. De acordo com as melhores pr\u00e1ticas do MongoDB, voc\u00ea precisa adicionar outro<\/i> conjunto de r\u00e9plicas (Shard #2). S\u00e3o tr\u00eas servidores, mas al\u00e9m disso h\u00e1 os servidores de configura\u00e7\u00e3o que armazenam as informa\u00e7\u00f5es sobre a localiza\u00e7\u00e3o de cada documento; portanto, de acordo com as melhores pr\u00e1ticas, isso significa tr\u00eas<\/i><\/b> mais<\/i> servidores.<\/p>\n\n\n\n
Bem, pelo menos com todos esses novos servidores voc\u00ea ter\u00e1 muito mais largura de banda para grava\u00e7\u00f5es, certo? N\u00e3o t\u00e3o r\u00e1pido! Mesmo adicionando mais seis servidores, agora voc\u00ea s\u00f3 pode gravar em at\u00e9 dois servidores, e n\u00e3o em nove. Voc\u00ea tem o Prim\u00e1rio original (conjunto de r\u00e9plicas #1) e agora um novo Prim\u00e1rio (conjunto de r\u00e9plicas #2). Com tudo isso, a \u00fanica coisa que voc\u00ea conseguiu foi aumentar significativamente a complexidade e a sobrecarga de manuten\u00e7\u00e3o do seu cluster. Se precisar adicionar outro shard para obter mais desempenho de grava\u00e7\u00e3o, voc\u00ea precisar\u00e1 adicionar outro<\/i> tr\u00eas n\u00f3s. Sua aplica\u00e7\u00e3o nem sequer chega a usar dois de cada um desses servidores em cada conjunto de r\u00e9plicas.<\/p>\n\n\n\n
Uma maneira de contornar a subutiliza\u00e7\u00e3o de servidores bare metal que tenho observado \u00e9 colocar muitos e muitos processos mongod no mesmo servidor, contrariando as pr\u00f3prias recomenda\u00e7\u00f5es do Mongo Recomenda\u00e7\u00f5es<\/span><\/a>. Deixando de lado os problemas de desempenho, e mesmo que servidores virtuais sejam usados, o que acontece quando um dos n\u00f3s cai? Quantas inst\u00e2ncias prim\u00e1rias e secund\u00e1rias voc\u00ea perder\u00e1? Voc\u00ea tem acompanhado onde est\u00e3o todas as inst\u00e2ncias prim\u00e1rias e secund\u00e1rias para garantir que um conjunto de r\u00e9plicas esteja adequadamente distribu\u00eddo pelos servidores no cluster para suportar isso? Voc\u00ea fala sobre aumentar a complexidade, meu Deus, isso com certeza faz isso!<\/p>\n\n\n\n Vamos analisar o mesmo cen\u00e1rio de tr\u00eas servidores que discuti acima, mas desta vez pensando no Couchbase. Sua aplica\u00e7\u00e3o pode ler e gravar em discos isolados, mem\u00f3ria, rede, n\u00facleos de CPU, etc., em todos os tr\u00eas servidores. No Couchbase, seus dados s\u00e3o distribu\u00eddos uniformemente entre os tr\u00eas servidores e replicados entre eles. O SDK do Couchbase que sua aplica\u00e7\u00e3o usa sabe como acessar seus dados, onde est\u00e3o os servi\u00e7os do Couchbase no cluster e como acessar todos eles. Vamos pegar o mesmo cen\u00e1rio de escalabilidade acima e ver suas op\u00e7\u00f5es no Couchbase. Voc\u00ea pode adicionar rapidamente outro servidor ao cluster com dois cliques no Console de Administra\u00e7\u00e3o OU com um comando de CLI.<\/p>\n\n\n\n Compare isto com o etapas necess\u00e1rias<\/span><\/a> para adicionar um conjunto de r\u00e9plicas ao MongoDB. Com o Couchbase, quando voc\u00ea 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\u00ea pode adicionar mais e rebalancear novamente. Viu como isso \u00e9 f\u00e1cil? Suas aplica\u00e7\u00f5es est\u00e3o sempre usando todos<\/i> dos servidores no cluster. Voc\u00ea nem precisa alterar sua aplica\u00e7\u00e3o e pode adicionar um ou mais servidores a qualquer momento que desejar, sem tempo de inatividade. O resultado final \u00e9 que voc\u00ea n\u00e3o est\u00e1 desperdi\u00e7ando servidores ou recursos de servidores. Voc\u00ea pode usar cada peda\u00e7o de cada um dos servidores, se quiser, e escalar horizontalmente. Voc\u00ea pode escrever sua aplica\u00e7\u00e3o em um n\u00f3 do Couchbase no seu computador e implant\u00e1-la em um cluster do tamanho que for em produ\u00e7\u00e3o, sem esfor\u00e7o adicional.<\/p>\n\n\n\n O Couchbase tamb\u00e9m tem dados de r\u00e9plica, \u00e9 claro, mas os dados de r\u00e9plica s\u00e3o usados apenas para Alta Disponibilidade. Por que abrir m\u00e3o da consist\u00eancia em prol do desempenho como no MongoDB, quando voc\u00ea pode ter ambos no Couchbase? E quando se trata de reduzir a complexidade ao usar VMs com o Couchbase, voc\u00ea pode usar a Consci\u00eancia de Rack\/Zona (Rack\/Zone Awareness).<\/p>\n\n\n\n Abaixo est\u00e1 uma r\u00e1pida compara\u00e7\u00e3o visual do que estamos falando aqui. Note que, no cluster do MongoDB com todos esses servidores, h\u00e1 apenas tr\u00eas servidores nos quais voc\u00ea pode gravar dos quatorze listados.\u00a0<\/p>\n\n\n\n \u00a0<\/p>\n\n\n\n Compare isso com o lado do Couchbase e voc\u00ea ver\u00e1 o quanto isso \u00e9 realmente mais simples, limpo e f\u00e1cil de gerenciar. Para mais informa\u00e7\u00f5es sobre esse assunto, consulte Postagem do blog de Manuel Hurtado<\/span><\/a> Isso contrasta a configura\u00e7\u00e3o de um cluster pronto para produ\u00e7\u00e3o em Couchbase versus MongoDB. H\u00e1 tamb\u00e9m compara\u00e7\u00f5es arquitet\u00f4nicas independentes de terceiros que abordam o problema, como esta<\/span><\/a>.<\/p>\n\n\n\n Se j\u00e1 n\u00e3o for \u00f3bvio at\u00e9 agora, o MongoDB tem alguns problemas s\u00e9rios em como uma aplica\u00e7\u00e3o pode utilizar totalmente todos esses servidores\/inst\u00e2ncias caros. Sim, existem algumas solu\u00e7\u00f5es alternativas, mas a maioria dos profissionais de opera\u00e7\u00f5es desaconselhar\u00e1 esse tipo de empilhamento; mesmo com virtualiza\u00e7\u00e3o, ir a esse n\u00edvel de densidade simplesmente n\u00e3o \u00e9 uma boa ideia. Al\u00e9m de tudo isso, isso n\u00e3o \u00e9 algo que o MongoDB provavelmente v\u00e1 consertar t\u00e3o cedo, j\u00e1 que est\u00e1 enraizado em sua arquitetura principal. O Couchbase, por outro lado, foi arquitetado para utilizar totalmente cada servidor que voc\u00ea 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.<\/p>\n\n\n\n A utiliza\u00e7\u00e3o do servidor \u00e9 uma quest\u00e3o importante porque os custos combinados de licen\u00e7as de banco de dados, hardware, despesas gerais de gerenciamento e custos de instala\u00e7\u00f5es podem rapidamente sair do controle. Para colocar alguns n\u00fameros nisso, deixando de lado as despesas gerais de gerenciamento, custa mais de $700 por ano<\/span><\/a> apenas para alimentar (o que n\u00e3o \u00e9 nada legal) um servidor comum em seu pr\u00f3prio data center. E se voc\u00ea optar por usar a nuvem para obter capacidade, o custo total pode chegar a $8-10.000 por inst\u00e2ncia, por ano<\/a>. Portanto, este \u00e9 verdadeiramente um exemplo em que as considera\u00e7\u00f5es arquiteturais podem ter implica\u00e7\u00f5es significativas de custo e complexidade. Portanto, se voc\u00ea estiver disposto, v\u00e1 baixar<\/span><\/a> Carregue o Couchbase e veja como \u00e9 f\u00e1cil extrair todo o potencial desses servidores e do pr\u00f3prio Couchbase.<\/p>","protected":false},"excerpt":{"rendered":" When I started out using MongoDB in 2012 as the ops and architecture guy, I had a few key problems with how it is architected. As time has passed, I\u2019ve observed others having similar challenges. A fundamental problem is MongoDB does not fully utilize the power of servers\/instances it has, by design. I hate provisioning […]<\/p>\n","protected":false},"author":23,"featured_media":18,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"_acf":"","footnotes":""},"categories":[1],"tags":[],"ppma_author":[93],"class_list":["post-375","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"yoast_head":"\nEscalonando com o Couchbase<\/h2>\n\n\n\n
\r\n$> \/opt\/couchbase\/bin\/couchbase-cli rebalance \n -c :8091 \n --server-add=:8091 \n -u Administrator -p<\/code><\/pre>\n\n\n\n![](\"\/wp-content\/original-assets\/2015\/november\/server-utilization-couchbase-vs-mongodb\/cb-v-mongo.png\")
<\/p>\n\n\n\nResumo<\/h2>\n\n\n\n