Tipos de Cluster no MongoDB Atlas Voltamos ao nosso ambiente que nós usamos anteriormente para fazer aquela migração e agora eu quero falar um pouco mais sobre os outros tipos de cluster que nós vamos encontrar na camada paga de MongoDB Atlas. Então, na sua interface gráfica, você vai ter no lado direito esse botão de criar, create. Ao clicar aqui, nós vamos ver que vai aparecer um menu mais detalhado para a gente navegar. Eu quero falar com você exatamente sobre as possibilidades que nós temos aqui dentro. Então, primeiro, logo de cara, vem marcado o tipo do cluster dedicado. Então, aqui é interessante que na maior parte dos projetos, provavelmente nós vamos usar um cluster do tipo dedicado. Conforme o comentário já nos sugere para aplicações produtivas com requisitos mais sofisticados e também com configurações mais avançadas, principalmente isolamento de rede, criptografia de ponta a ponta, acesso granular. Ele ainda sugere o Performance Advisor, que são sugestões para melhorar o desempenho do cluster, como criação dos índices e melhorias do esquema. Bom, vamos falar do dedicado bastante, mas antes só para nos posicionarmos de onde é que nós viemos. Quando nós trabalhamos com a M0, nós estávamos no nível compartilhado, que é o Shared. Então aqui nós vamos encontrar as regiões dos três grandes provedores de nuvem para a gente fazer o deploy da nossa M0. E nós vamos ver que além da M0, existe M2 e M5. A diferença que vai mudar mudar o tamanho do storage. Então lá na M0 são 512 MB de dados, na M2 são 2 GB e na M5 são 5 GB de dados. O restante, como você pode ver aqui, vcpus compartilhadas e memória RAM compartilhada. Então por essa razão, vamos botar um foco maior no dedicado e aqui sim nós vamos poder falar de todas as possibilidades de configuração de cluster que a gente vai encontrar no MongoDB Atlas. Então, primeiro ponto, as primeiras configurações que nós vamos ter aqui nesse menu vai ser escolher o provedor de nuvem. O deploy mínimo de MongoDB no Atlas vai ter sempre três nós, um nó primário e dois secundários, como a gente já viu anteriormente. Agora, só para fins aqui de discussão, vou marcar a AWS. E aqui vão aparecer as regiões da AWS em que a gente pode fazer o deploy. Aqui no Brasil, nós temos a região de São Paulo. Um ponto importante também para mostrar para vocês, vocês vão ver que tem uma estrelinha do lado de São Paulo. Significa que é uma região recomendada, porque nessa região tem três zonas de disponibilidade. Comparação com Califórnia, na Califórnia não tem as três estrelinhas, lá na verdade deve ter uma AZ provavelmente, uma zona de disponibilidade. Então por essa razão é menos recomendável do que as demais, mas quase todas vão ter essa estrelinha dizendo que é uma região recomendada. uma região recomendada. A partir da seleção do provedor de nuvem e da região, nós vamos ter que fazer uma decisão de hardware. Então, aqui tem um ponto interessante, nós vamos ver que tem os tiers ou níveis de serviço para a gente ligar o nosso cluster. Então, M10 e M20 geralmente são ambientes de desenvolvimento, conforme o comentário aqui já está sugerindo. Ou até mesmo uma aplicação produtiva, mas que tenha um tráfego de baixo desempenho. Então, por essa razão, cargas produtivas vão começar aqui na M30. E aqui tem um ponto interessante para a gente discutir. Então, lembra que nós temos três nós. Um nó primário e dois nós secundários. Cada um desses nós vai ter 8 GB de RAM, pelo menos 40 GB de disco, conforme a minha configuração. Marquei 40 GB aqui. E duas VCPUs. O disco pode ser expandido conforme a necessidade se eu botar aqui 150 cada um daqueles três nós vai ter um disco posicionado de 150 gb vocês já perceberam também que o reloginho aqui de dinheiro muda conforme a gente vai configurando os elementos aqui da nossa configuração. Então, diminuir um pouco do disco, vou pagar a menos por isso. Aqui já vai entrar uma configuração bem interessante, que é o Auto Scale. No Auto Scale, eu posso determinar o tamanho mínimo e o tamanho máximo para um pico produtivo, uma alta demanda do cluster, o cluster muda de tamanho. Para essa configuração bem interessante, recomendo você utilizar nas suas aplicações em produção. Uma outra coisa interessante também é o Storage Scaling. Então aqui nós temos a possibilidade de ter o nosso disco expandido conforme a necessidade. Então, o Storage Scaling vai procurar sempre manter um espaço em disco de 30% e é reacionado quando a gente atingir 90% do espaço provisionado. Então, quando bater 90%, ele vai expandir até ficar com uma folga de 30%. Aqui mais para baixo, nós vamos ver a possibilidade na AWS de provisionamento de IOPS, então eu posso chegar com esse tamanho de disco até 3600. Aqui tem uma diferença importante, quando eu provisiono IOPS, eu vou trabalhar com este número, conforme eu configurar aqui, 3.699,9% do tempo. Se eu tirar o provisionamento, eu vou trabalhar com 3.000 IOPS, 99% do tempo, que é o disco estável. Então, a maior parte dos projetos, se você não tiver nenhum requisito específico de IOPS, você vai trabalhar com esta configuração. Adicionalmente, o que é importante você estar atento? Uma M30 vai trabalhar muito bem com 3.000 conexões, número máximo de conexões, e vai trabalhar em uma placa de rede de 10 GB. Um ponto interessante também de comentar aqui é que o MongoDB é muito sensível à memória RAM. Então, diferente do que a gente está acostumado a trabalhar com relacionais, que primeiro a gente olha a quantidade de CPUs, MongoDB, primeiro a gente vai olhar a memória. Então, a gente tem que estar muito atento aos tamanhos dos índices e documentos de acesso frequente para escolher um tamanho de memória adequado para isso. Então, por exemplo, se eu tiver um Working Set, que são índices e dados de acesso frequente da faixa de 16 GB, eu preciso trabalhar com uma M50, porque vai ter memória necessária. Uma regra geral aqui é a seguinte, você pega a memória RAM total do seu cluster e divide por 2. Então, 32 GB, metade disso fica para o Working Set. O Working Set são índices e dados de acesso frequente. Então tendo essa regra geral em mente, você deve ter muito sucesso para obter o melhor desempenho do seu cluster. Uma outra coisa que a gente pode fazer também é entrar em configurações avançadas E aqui realmente eu acho que tem um diferencial muito interessante Configurações multi nuvem, multi região e de isolamento de carga de trabalho Então olha só, a partir de agora eu posso entrar em um modo de trabalho Que eu vou determinar quantos nós eu quero ter no cluster de MongoDB. E aqui nós temos um conceito que existem três tipos de nós. Primeiro, os nós elegíveis, então esse electable nodes, são nós elegíveis, são os nós elegíveis a se tornarem o nó primário. Então eu tenho três números importantes, eu posso ter três, cinco ou sete. Vamos fazer uma configuração só para já ter uma ideia da diferença. Você está percebendo que eu estou marcando Google, São Paulo e vou marcar também Azuri e vou colocar Rio de Janeiro. Então aqui eu estou utilizando os sete nós elegíveis, dois no Rio de Janeiro na Azuri, 2 em São Paulo no Google e 3 na AWS em São Paulo. Sendo que aqui a prioridade é a prioridade de ter a eleição do nó primário. Então sempre eu vou procurar operar conforme minha escolha, minha estratégia, com meu nó primário em AWS. Olha que interessante também aqui em cima. Isso aqui significa que eu consigo sobreviver a uma parada parcial da região, a uma parada completa de uma das regiões que eu tenho equipamentos, eu tenho nós suficientes para que isso aconteça e até mesmo a parada de um provedor de nuvem a gente consegue sobreviver com esses sete nós. Além disso, nós temos mais nós do tipo de read-only, então nós de leitura, e nós analíticos. Então, se a gente tiver uma demanda muito intensa de leitura, nós podemos adicionar mais nós conforme essa necessidade. E da mesma maneira, se tiver uma carga de relatórios, uma carga de BI acontecendo, eu devo utilizar os nós analíticos. Então, na hora que eu estou usando o nó analítico, eu estou, na verdade, segregando, isolando a minha carga de trabalho e dessa maneira o meu transacional não vai competir com a analítica então, logo de cara a gente já vê que tem muita flexibilidade para escolher as regiões para fazer um default cluster multiregião, multinúvel e isolar a carga de trabalho