Dimensionamento de hardware para MongoDB com Graves
Avalie esse Podcast
O processo de determinar a quantidade certa de recursos de servidor para o banco de dados do seu aplicativo é um pouco como a geometria. As variáveis são muitas e diversas. Aqui estão apenas alguns:
- A quantidade total de dados armazenados
- Número de coleções
- Número de documentos em cada coleção
- Tamanho de cada documento
- Atividade no banco de dados
- Número e frequência de leituras
- Número e frequência de gravações, atualizações e exclusões
- Esquema de dados e índices
- Número de entradas de índices, tamanho dos documentos indexados
- Usuários
- Proximidade dos seus servidores de banco de dados
- Número total de usuários, o padrão de uso (consulte leituras/gravações)
Essas são apenas algumas e são um pouco complicadas porque a resposta a uma dessas perguntas pode depender inteiramente da resposta a outra, cuja resposta depende de outra. É aqui que reside a dificuldade em realizar um exercício de dimensionamento.
Um dos melhores neste exercício parte ciência, parte arte é Jay Runkel. Jay se juntou a nós no podcast para discutir o processo e as possibilidades. Este artigo contém a transcrição desse episódio.
Se você preferir ouvir, aqui está um link para o capítulo no YouTube.
michael lynn (00:00): bem-vindo ao podcast. Neste episódio, estamos falando sobre dimensionamento. Às vezes, é uma tarefa difícil descobrir quanto servidor você precisa para dar suporte ao seu aplicativo, e isso pode custar se você errar. Então, temos os especialistas para nos ajudar hoje. Estamos trazendo Jay Runkel. Jane Runcel é arquiteta executiva de soluções aqui no MongoDB. Um cara super inteligente. Ele já faz isso há algum tempo. Ele já ajudou centenas de clientes a dimensionar suas instâncias, talvez até milhares. Então, uma ótima conversa com Jay Runkel sobre como dimensionar suas instâncias do MongoDB. espero que você aproveite o capítulo.
Michael Lynn (00:55): Jay, como você está? É ótimo ver você de novo. Já faz um tempo para nós. Por que você não diz ao público quem você é e o que você faz?
Jay Runkel (01:02): Então, sou arquiteto executivo de soluções na MongoDB. Portanto, as equipes de vendas do MongoDB são divididas em duas classes individuais. Existem os representações de vendas que lidam com o relacionamento com o cliente, muitos dos aspectos comerciais das vendas. E há arquitetos de soluções que desempenham o papel de pré-vendas, e lidamos com muitos dos aspectos técnicos das vendas. Então, passo muito tempo trabalhando com clientes, entendendo seus desafios técnicos e ajudá-los a entender como o MongoDB pode ajudá-los a resolver esses desafios técnicos.
michael lynn (01:34): É um papel demais. Passei algum tempo como arquiteto de soluções nos últimos anos, e até aqui no MongoDB, e é uma função fantástica. Você ajuda os clientes em sua jornada, usando o MongoDB e resolvendo alguns de seus problemas técnicos. Então hoje vamos focar no dimensionamento, como é dimensionar um cluster MongoDB, seja ele on prem no seu próprio data center ou no MongoDB Atlas, o banco de dados como serviço. Mas antes de chegarmos lá, gostaria de aprender um pouco mais sobre o que o levou a este ponto, Jay. Onde você estava antes do MongoDB? O que você estava fazendo? E como você consegue preencher The Gap entre algo que requer as habilidades de um desenvolvedor e a função de vendas?
Jay Runkel (02:23): Sim, então meu treinamento e minha experiência no início da carreira foram como desenvolvedor e fiz isso por cerca de cinco, seis anos e percebi que não queria sentar na frente de uma mesa todos os dias. Então, o que fiz foi começar a procurar outras funções onde pudesse passar muito mais tempo com os clientes. E aconteceu de eu fazer uma apresentação na frente de um VP de vendas uma vez, cerca de 25 anos atrás. E após a reunião, ele disse: "Ei, eu realmente preciso que você ajude a apoiar a equipe de vendas". E isso meio que começou minha carreira em pré-vendas. E trabalhei para muitas empresas diferentes ao longo dos anos, mais recentemente relacionadas ao MongoDB. Antes do MongoDB, trabalhei para o MarkLogic, onde o MarkLogic é outro grande banco de dados sem SQL. E obtive a maior parte da minha experiência em bancos de dados de documentos na MarkLogic, uma vez que eles têm um banco de dados de documentos baseado em XML.
michael lynn (03:18): Então, obviamente, trabalhar com clientes e ajudá-los a entender como usar o MongoDB e o document model, isso é muito técnico. Mas o aspecto de vendas está quase no extremo oposto do espectro de personalidade. Como você encontra isso? Você acha difícil ficar entre esses dois tipos de funções?
Jay Runkel (03:40): Para mim, quase tudo se confunde. Acho que, em termos dessa função, é técnico, mas as vendas meio que se fundiram. Você também pode fazer coisas não técnicas em que você está apenas tentando entender as dores de negócios de um cliente e ajudá-lo a entender como, se fossem da solução MongoDB, ela resolveria essas dores de negócios. Mas você também pode se aprofundar na tecnologia, trabalhar com o desenvolvedor e entender alguns desafios técnicos que eles enfrentam e como o MongoDB também pode resolver esse problema. Então, para mim, parece muito fácil e a maioria das interações com os clientes começa nesse alto nível em que realmente entendemos a situação comercial, a dor e onde eles querem estar no futuro. E, geralmente, a conversa evolui para " Tudo bem, agora que temos esse problema comercial, quais são os requisitos técnicos necessários para alcançar essa solução e eliminar a dor e como o MongoDB pode atender a esses requisitos? "
Nic Raboy (04:41): Então, imagino que você experimente um conjunto bastante diversificado de solicitações de clientes. Como se todo cliente provavelmente estivesse fazendo algo realmente surpreendente e precisasse do MongoDB para um caso de uso muito específico. Você já se sentiu estressado por talvez não saber como ajudar um cliente em particular porque é tão exótico?
Jay Runkel (05:03): Sim, mas essa é a melhor coisa do trabalho. O melhor de estar no MongoDB é que, muitas vezes, os clientes procuram o MongoDB porque falharam com outra coisa, seja porque criaram um aplicativo como Oracle ou Postgres ou algo assim e ele não está executando, ou eles não podem implementar novas funcionalidades com rapidez suficiente, ou eles apenas analisaram os requisitos desse novo aplicativo que desejam criar e perceberam que não podem criá-lo em plataformas de dados tradicionais. Então, sim, muitas vezes você pode entrar com um cliente e começar a falar sobre um caso de uso ou problema que ele tem e, no início, você pode ficar: "Nossa, não sabe como vamos resolver isso. " Mas, à medida que você entra na conversa, normalmente trabalha e colabora com o cliente. Eles conhecem seus negócios, conhecem sua infraestrutura técnica. Você conhece o MongoDB. E combinando essas duas fontes de informação, muitas vezes, nem sempre, você pode encontrar uma solução para resolver o problema. Mas esse é o desafio, é isso que o torna divertido.
Nic Raboy (06:07): Então, eu estaria absolutamente incorreto se dissesse algo como você está mais no papel de preencher The Gap do que o cliente está procurando, em vez de tentar ajudá-lo a descobrir o que precisa para o problema? Parece que eles vieram de talvez uma outra solução que falhou para eles, você disse. E então eles talvez tenham uma ideia aproximada do que querem realizar com o banco de dados, mas você precisa levá-los para a próxima etapa em vez de: "Ei, eu tenho essa ideia. Como executo essa ideia?" tipo de coisa.
Jay Runkel (06:36): Sim, eu diria que, para alguns clientes, é muito simples, muito direto. Digamos que queremos criar o aplicativo de carrinho de compras. Provavelmente existem centenas ou milhares de aplicativos de carrinho de compras criados no MongoDB. É um lindo cortador de biscoitos. Essa não é uma conversa longa. Mas há outros clientes que querem poder processar, digamos, pagamentos digitais 500,000 por segundo e ter todos esses requisitos em torno de cem por cento de disponibilidade. Podem fazer com que o aplicativo continue funcionando sem problemas se um data center inteiro falhar, onde você realmente precisa se aprofundar e entender seu caso de uso e todos os requisitos detalhadamente para descobrir uma solução que funcione para eles. Nesse caso, a função de DevOps geralmente é com quem estamos falando.
Nic Raboy (07:20): Incrível.
michael lynn (07:21): Sim. Portanto, antes de entrarmos nos detalhes técnicos de exatamente como você faz o que faz em termos de recomendação do dimensionamento de uma implantação, vamos falar um pouco sobre as possibilidades das implantações do MongoDB. Algumas pessoas podem estar ouvindo e pensando: " Bem, eu tive essa ideia para um aplicativo e ele está no meu laptop agora e sei que terei que Go a produção em algum momento. " Quais são as opções que eles têm para implantar o MongoDB?
Você pode executar o MongoDB em seu laptop, movê-lo para um mainframe, movê-lo para a cloud no MongoDB Atlas, movê-lo de um provedor de cloud para outro dentro do Atlas e nenhuma modificação em seu código além da connection string.
Jay Runkel (07:46): Portanto, o MongoDB suporta praticamente todas as principais plataformas que você pode considerar. O MongoDB realm tem um banco de dados para um dispositivo móvel. O próprio MongoDB é executado nos sistemas operacionais Microsoft e Mac. Ele é executado em mainframes IBM. Ele é executado em uma variedade de versões do Linux. Você também pode executar o MongoDB na nuvem, pode criar uma instância da AWS ou uma instância do Azure, instalar e executar o MongoDB. Ou também temos nossa solução em nuvem chamada Atlas, na qual implantaremos e gerenciaremos seu cluster MongoDB para você no provedor de nuvem de sua escolha. Então, você essencialmente tem todo esse intervalo e pode escolher a plataforma e, essencialmente, escolher quem vai gerenciar o cluster para você.
michael lynn (08:34): fantástico. Digo, as opções são ilimitadas e o melhor de tudo é que o que você realmente mencionou lá é uma API consistente em todas essas plataformas. Para que você possa desenvolver e criar seu aplicativo, o que aproveita o MongoDB em qualquer linguagem em que esteja trabalhando, e não precisa se preocupar com isso, independentemente do destino de implantação que você usa. Então, diretamente no seu laptop, execute-o localmente, baixe o servidor MongoDB e execute-o em seu laptop. Execute-o em uma instância do docker e, em seguida, implante-o literalmente em qualquer lugar e não precise tocar em seu código. É esse o caso?
Jay Runkel (09:07): Isso é absolutamente verdade. Você pode executá-lo em seu laptop, movê-lo para um mainframe, movê-lo para a nuvem no Atlas, movê-lo de um provedor de nuvem para outro no Atlas e nenhuma modificação em seu código além da connection string.
michael lynn (09:20): fantástico.
Nic Raboy (09:21): Mas quando você conversa com clientes, temos todas essas opções. Como você determina se alguém deve ou não estar on prem ou alguém deve estar no Atlas ou etc.?
Jay Runkel (09:32): Essa é uma ótima pergunta. Agora, encontro o Atlas, porque quem quer gastar recursos de energia gerenciando um banco de dados quando isso é algo que o MongoDB simplificou, automatizou e assegurou que fosse implantado com as melhores práticas, com o mais alto nível de segurança possível? Então esse é o caso ideal. Talvez seja para lá que a maioria dos nossos clientes está se direcionando. Agora, há determinados setores e determinados clientes que têm determinados requisitos ou políticas de segurança que os impedem de serem executados em um provedor de nuvem, e esses clientes são os que ainda se fazem autogerenciados no local.
Nic Raboy (10:15): Mas quando se trata de coisas que exigem, digamos, o auto-gerenciamento no local, esses requisitos, quais seriam? Como HIPAA e FERPA e todos esses outros motivos de segurança? Acredito que o Atlas apoia isso, certo?
Jay Runkel (10:28): Sim. Mas eu diria que, mesmo que as regulamentações permitam explicitamente que as organizações estejam na nuvem, muitas vezes elas têm políticas internas que são ainda mais cautelosas e não querem correr riscos, portanto, permanecerão no local. Outras opções são: se você é uma empresa que historicamente foi implantada em seus próprios data centers, se você tem o novo aplicativo que está construindo, se ele é a única coisa na nuvem e todos os seus servidores de aplicativos ainda estão dentro do seu próprios data centers, às vezes isso também não faz muito sentido.
michael lynn (11:03): Então, gostaria de esclarecer uma coisa. Você mencionou e sua pergunta era sobre conformidade. E eu quero apenas ter certeza de que está claro. Não há razão para que alguém que exija conformidade não possa implantar em um Atlas além de algo internamente, alguma conformidade interna. Quero dizer, somos capazes de gerenciar aplicativos que exigem HIPAA e FERPA e todas essas restrições de conformidade, certo?
Jay Runkel (11:27): Com certeza. Temos organizações de serviços financeiros e empresas de saúde que executam seus negócios, seus aplicativos principais, dentro do Atlas hoje, gerenciando todos os tipos de dados confidenciais, PII e dados HIPAA. Então, sim, isso foi feito e pode ser feito com toda a infraestrutura de segurança fornecida pelo Atlas.
Nic Raboy (11:48): Incrível.
michael lynn (11:49): Só queria esclarecer isso. Go, Nic.
Nic RaBoy (11:51): Eu queria apenas apontar aqui, para qualquer um que esteja ouvindo este capítulo específico do podcast, gravamos um capítulo anterior com o Kerry White, certo o Piper?
michael lynn (12:01): correto.
Nic Raboy (12:01): ... sobre as diferentes práticas de segurança do MongoDB, caso queira saber mais.
michael lynn (12:06): Sim. Ótimo. OK. Então, já estamos alguns minutos e estou ansioso para entrar no cerne da questão em torno do tamanho. Mas antes de entrarmos nos detalhes técnicos, vamos falar sobre o que é grande, o que é pequeno e meio que preparar o terreno para as possibilidades.
Jay Runkel (12:24): Ok. Então, grande e pequeno é um tanto relativo, mas o MongoDB tem clientes que têm um conjunto de réplicas simples com alguns gigabytes de dados para clientes que gerenciam mais de petabytes de dados em clusters MongoDB. E o número de servidores pode variar de três instâncias em um conjunto de réplicas que talvez tenham um gigabyte de RAM cada a um cluster que tenha várias centenas de servidores e talvez 50 ou cem fragmentos, algo assim.
michael lynn (12:59): Uau. OK. Portanto, uma gama muito grande. E só para esclarecer o glossário aqui, Jay está usando termos como conjunto de réplicas. Para aqueles que são novos no MongoDB, o MongoDB criou alta disponibilidade e você pode implantar várias instâncias do MongoDB que trabalham em unísono para replicar as alterações no banco de dados e chamamos isso de cluster ou conjunto de réplicas. Ótimo. Então, vamos falar sobre a abordagem de dimensionamento. O que você faz quando se aproxima de um novo cliente ou de uma nova implantação e o que precisa pensar quando começa a pensar em como dimensionar e implementar?
Jay Runkel (13:38): Ok. Então, antes de Go lá, vamos falar sobre o que é dimensionamento e o que significa dimensionamento. Então, normalmente, quando falamos sobre dimensionamento no MongoDB, estamos realmente falando sobre o tamanho de um cluster que precisamos para resolver o problema de um cliente? Essencialmente, quanto hardware precisamos dedicar ao MongoDB para que o aplicativo tenha um bom desempenho? E o desafio em torno disso é que muitas vezes não é óbvio. Se você estiver criando um aplicativo, saberá aproximadamente quantos dados e aproximadamente como os usuários irão interagir com o aplicativo. E alguém quer saber quantos servidores você precisa e quanta RAM eles têm? Quantos núcleos? Qual deve ser o tamanho dos discos? Portanto, não é óbvio, é uma lacuna muito grande entre o que você sabe e quais são as respostas de que você precisa. Então, o que espero poder fazer hoje é mostrar como você chega lá.
michael lynn (14:32): Incrível. Por favor, faça.
Jay Runkel (14:33): Ok. Então vamos conversar sobre isso. Então, há algumas coisas que queremos abordar, como dissemos. Antes de mais nada, queremos descobrir, é um cluster fragmentado? Não que você já tenha definido o que é sharding, essencialmente. É uma maneira de particionar os dados para que você possa distribuir os dados em um conjunto de servidores, para que você possa ter mais servidores gerenciando os dados ou processando queries. Então isso é uma coisa. Queremos descobrir de quantas partições, de quantos fragmentos de dados precisamos. E então também precisamos descobrir como são as especificações desses servidores? Quanta RAM eles devem ter? Quanto CPU? Quanto disco? Esse tipo de coisa.
Jay Runkel (15:12): Então, a maneira mais fácil que encontro de lidar com isso é dividir esse processo em duas etapas. O primeiro passo é calcular a quantidade total de RAM de que precisamos, o número total de núcleos, essencialmente, a quantidade total de espaço em disco, esse tipo de coisa. Depois de termos os totais, podemos descobrir quantos servidores precisamos para entregar esses totais. Por exemplo, se fizermos algumas contas, que explicarei em breve, e descobrirmos que precisamos de 500 gigabytes de RAM, podemos descobrir que precisamos de cinco fragmentos se todos os nossos servidores tiverem cem gigabytes de RAM. Esse é basicamente o tipo de etapas pelas quais vamos Go. Basta descobrir quanto de RAM, quanto disco, quanto IO. E, em seguida, descobrir quantos servidores são necessários para atender a esses totais.
michael lynn (15:55): Ok. Então, um pouco de álgebra básica, e uma das variáveis são os servidores atuais que temos. E se não tivermos servidores disponíveis e isso for uma espécie de variável aberta e indefinida?
Java (16:05): Sim, então no Atlas, você tem muitas opções. Não há apenas um. Muitas vezes, se estamos implantando no data center de alguns clientes, eles têm uma caixa de pizza padrão que fica em uma prateleira, então sabemos como é e podemos projetá-la para isso. Em algo como o Atlas, isso se torna um problema de otimização de preços. Então, se descobrirmos que precisamos de 500 gigabytes de RAM, como eu disse, podemos descobrir se é melhor usar 10 fragmentos em que cada fragmento tem 50 gigabytes de RAM? É mais barato basicamente? Ou devemos fazer cinco fragmentos em que cada fragmento tenha cem gigabytes de RAM? Então, no Atlas, é como se você realmente experimentasse e encontrasse o preço mais eficaz.
Michael Lynn (16:50): Entendi, tudo bem.
Nic Raboy (16:52): Mas será que estamos considerando apenas uma faixa de preço que é eficaz? MEAN, talvez eu tenha perdido, mas o que estamos ganhado ou perdido ao usar os shards 50 gigabytes em vez dos shards de cem gigabytes?
Jay Runkel (17:04): Portanto, há algumas outras considerações. Um é o tempo de backup e restauração. Se você particionar os dados, se você fragmentar mais os dados, cada partição terá menos dados. Então, se você pensar em se recuperar de um desastre, será mais rápido porque você restaurará um número maior de servidores menores. Isso tende a ser mais rápido do que restaurar um único fluxo, restaurando menos servidores maiores. A outra questão é que, se você pensar em muitos de nossos clientes crescerem ao longo do tempo, eles estão adicionando shards. Se você usar shards de máquinas menores, cada etapa incremental será menor. Portanto, é mais fácil dimensionar corretamente o cluster porque você pode, em partes menores, adicionar fragmentos adicionais para adicionar mais capacidade. Onde, se você tiver menos shards maiores, cada shard adicional é um passo muito maior em termos de capacidade, mas também de custo.
Michael Lynn (18:04): Ok. Você mencionou sharding e falamos brevemente sobre o que é isso. É o particionamento dos dados. Você sempre usa fragmentos?
Jay Runkel (18:12): Eu diria que a maioria dos nossos clientes não fragmenta. Quero dizer, um único conjunto de réplicas, que normalmente é um fragmento, pode depender novamente da carga de trabalho, do lado do servidor e tudo mais. Mas geralmente vemos algo em torno de um a dois terabytes de dados em uma única réplica definida como uma espécie de limite superior. E na maioria dos nossos aplicativos, eu não sei as porcentagens exatas, mas em algum lugar 80 - 90% dos aplicativos do MongoDB estão abaixo da faixa de um terabyte. Portanto, na maioria dos aplicativos, você nem precisa se preocupar com sharding.
michael lynn (18:47): euadoro porqueadororegras práticas, coisas que podemos pensar sobre isso tipo de simplificação do processo. E o que obtive lá foi veja, se você tem um terabyte de dados ou mais sob gerenciamento de seu cluster, normalmente vai querer começar a pensar em fragmentação.
Jay Runkel (19:02): Pense nisso. E pode não ser necessário, mas talvez você queira começar a pensar sobre isso. Sim.
michael lynn (19:06): Ok, ótimo. Agora mencionamos álgebra e uma das variáveis foi o tamanho do servidor e os recursos disponíveis. Conte-me sobre os elementos individuais no servidor que analisamos e, em seguida, faremos a transição para o que o aplicativo está fazendo e como sobrepomos isso.
Jay Runkel (19:25): Ok. Então, quando você curte um servidor, há muitas especificações que você pode considerar. Acontece que, com o MongoDB, digamos, 95% das vezes, as únicas coisas com as quais você realmente precisa se preocupar é com quanto espaço em disco, quanta RAM e, em seguida, com que velocidade de um sistema de E/S você tem, na verdade, quantas IOPS você precisa. Acontece que outras coisas, como CPU e rede, embora teoricamente possam ser gargalos, na maioria das vezes não são. Normalmente é espaço em disco RAM e IO. E eu diria que está em algum lugar entre 98, 99% dos aplicativos MongoDB. Se você os dimensionar apenas considerando RAM, IOPS e espaço em disco, fará uma estimativa muito boa do tamanho e terá muito mais CPU e muito mais rede do que precisa.
michael lynn (20:10): Tudo bem. Estou amando porque estamos, estamos progredindo. Então, regra geral super simples: veja a quantidade de armazenamento de banco de dados necessária. Se você tiver um terabyte ou mais, talvez queira fazer mais cálculos. E a próxima etapa seria verificar o espaço em disco, a RAM e a velocidade dos discos ou do IOPS, iOS por segundo necessários.
Jay Runkel (20:29): Sim. Portanto, o IOPS é uma métrica que todos os fabricantes de dispositivos IO fornecem e é realmente uma medida da rapidez com que o sistema IO pode acessar aleatoriamente blocos de dados. Então, se você pensar no que um banco de dados faz, MongoDB ou qualquer banco de dados, quando alguém emite uma query, ele está realmente andando no disco e pegando os blocos aleatórios de dados que satisfazem essa query. Portanto, o IOPS é uma métrica muito boa para dimensionar sistemas IO para banco de dados.
michael lynn (21:01): Ok. Agora eu ouvi o termo conjunto de trabalho, e isso é crucial quando se fala em dimensionar servidores, dimensionar a implantação de um aplicativo específico. Fale-me sobre o conjunto de trabalho, o que ele é e como você determina o que ele é.
Jay Runkel (21:14): Ok. Então dissemos que precisvamos dimensionar três coisas: RAM, IOPS e o espaço em disco. Portanto, o conjunto de trabalho realmente nos ajuda a determinar de quanta RAM precisamos. Portanto, a definição de conjunto de trabalho é realmente o tamanho dos índices mais o conjunto de documentos acessados com frequência usados pelo aplicativo. Então, deixe-me detalhar isso um pouco. Se você está considerando qualquer banco de dados, inclusive o MongoDB, se deseja um bom desempenho, deseja que o material acessado com frequência pelo banco de dados esteja na memória e no cache. E se não estiver em cache, isso significa que o servidor precisa Go para o disco, que é muito lento, pelo menos em comparação com a RAM. Portanto, quanto mais desse conjunto de trabalho, os índices e os documentos acessados com frequência couberem na memória, melhor será o desempenho. O motivo pelo qual você deseja ter os índices na memória é que praticamente todas as consultas, sejam elas uma consulta fina ou uma atualização, terão que usar os índices para localizar os documentos que serão afetados. E, portanto, como toda consulta precisa usar os índices, você deseja que eles estejam no cache, para que o desempenho seja bom.
michael lynn (22:30): Sim. Isso faz sentido. Mas vamos clicar double vezes nisto um pouco. Como Go para determinar quais são os documentos acessados com frequência?
Jane Runcel (22:39): Essa é uma ótima pergunta. Infelizmente, é por isso que há um pouco de arte no dimensionamento, em vez de apenas enviarmos uma planilha e dizermos: "Preencha e você obterá a resposta." Portanto, os documentos acessados com frequência realmente dependem do seu conhecimento do aplicativo e de como você espera que ele seja usado ou de como os usuários o estão usando, se já for um aplicativo em produção. Portanto, é realmente o conjunto de dados que é acessado o tempo todo. Então, posso dar alguns exemplos e talvez isso deixe mais claro.
michael lynn (23:10): Sim, perfeita.
Jay Runkel (23:10): Digamos que seja um aplicativo em que os clientes estão procurando suas contas. Talvez seja uma companhia telefônica ou empresa de cabo ou algo assim ou Hulu, Netflix, o que você tem. Na maioria das vezes, as pessoas só se preocupam com as contas que receberam este mês, mês passado, talvez dois meses atrás, três meses atrás. Se você é alguém como eu, que costumava viajar muito antes do COVID, talvez você fique muito atrasado em seus relatórios de despesas e olhe para trás quatro ou cinco meses, mas raramente passou disso. Então, nesse tipo de aplicativo, os documentos acessados com frequência provavelmente serão as contas do mês atual. Essas são as coisas que as pessoas estão vendo o tempo todo, e o resto das coisas não precisa estar em cache porque não é acessado com muita frequência.
Nic RaBoy (23:53): Então, o que eu MEAN, então, no que diz respeito às acessadas com frequência, vamos usar o exemplo das faturas mais recentes. E se a sua aplicação ou a sua demanda for tão alta? Você está tentando acomodar todas as contas mais recentes nesse acesso frequente ou está restringindo ainda mais o subconjunto?
24 13 estiverem online ao mesmo tempo, só precisarão dos índices e dos dados para os mil usuários ativos. Se eu fizer login no aplicativo e levar um segundo ou qualquer outra coisa para gerar a primeira fatura, mas todo o resto for muito rápido depois disso, à medida que exergo as diferentes linhas da minha fatura ou o que for, ficarei satisfeita. Então, normalmente é isso que você está procurando é apenas para as pessoas que estão atualmente envolvidas no sistema, você deseja que seus dados estejam na RAM.
Michael Lynn (24:57): Então publiquei um artigo talvez dois ou três anos atrás, e o título do artigo era "Conhecendo o Incognoscível". E é um pouco disso que estamos falando aqui, porque você está mencionando coisas como índices e mencionando coisas como documentos acessados com frequência. Portanto, isso obviamente exigirá que você entenda como seus dados são dispostos. E nos referimos a isso como um esquema. Você também precisará ter um bom entendimento de como está indexando, quais índices está criando. Então me diga, Jay, até que ponto o dimensionamento informa o esquema ou vice-versa?
Jay Runkel (25:32): Então, uma das coisas que fazemos como parte de todo o processo de design do MongoDB é criar o dimensionamento como parte dos processos de design, conforme você está sugerindo. Porque o que pode acontecer é que você pode criar um esquema muito bom e descobrir qual índice você usa, e então você pode olhar para esse design específico e dizer: " Uau, isso MEAN que vou precisar de 12 fragmentos. " Você pode pensar um pouco mais sobre isso, criar um esquema diferente e dizer: "Ah, esse só vai precisar de dois fragmentos." Então, se você pensar sobre isso, agora você tem que Go até seu pai e pedir hardware. Se você precisar de dois shards, provavelmente está solicitando seis servidores. Se você tiver 12 shards, está solicitando 36 servidores. Garanto que seu chefe ficará muito mais feliz pagando seis do que 36. Portanto, obviamente, essa é uma troca que você deve fazer. Os esquemas funcionarão melhor, poderão ser mais fáceis de desenvolver e também terão implicações diferentes na infraestrutura de que você precisa.
michael lynn (26:35): Ok. E então, obviamente, a criticidade do dimensionamento aumenta quando você está falando sobre uma implantação local, porque obviamente para colocar um servidor no lugar, é uma compra. Você está esperando que ela chegue. Você precisa fazer networking. Agora, quando nos movemos para a nuvem, ela é um pouco reduzida. E gostaria de falar um pouco sobre a flexibilidade que acompanha uma implantação no MongoDB Atlas, porque sabemos que o MongoDB Atlas começa do zero. Temos uma instância gratuita para sempre, que é chamada de nível M0 e vai até M700 com muita RAM e muita CPU. O que me impede de dizer: " Ok, eu realmente não vou me concentrar no dimensionamento e talvez eu simplesmente implante um M0 e veja no que funciona. "
O MongoDB Atlas oferece diferentes camadas de clusters com quantidades variáveis de RAM, CPU e disco. Essas camadas são rotuladas começando com M0 - Grátis, e continuando até M700 com enormes quantidades de RAM e CPU. Cada camada também oferece diferentes tamanhos e velocidades de discos.
Jay Runkel (27:22): Então você poderia, na verdade. A coisa realmente fabulosa sobre o Atlas é que você pode implantar, eu não começaria com M0, mas você pode começar com um M10 e habilitar. Há dois tipos de recursos no Atlas. Um aumentará automaticamente o tamanho do disco para você. Então, à medida que você carrega mais dados, acho que à medida que o disco fica cerca de 90% cheio, ele o aumenta automaticamente. Então, você pode começar bem pequeno e confiar apenas no Atlas para ampliá-lo. E, da mesma forma, para o tamanho da instância em si, há outro recurso em que ele aumentará automaticamente a escala da instância como carga de trabalho. Então, à medida que você começar a usar mais RAM e CPU, ela escalará automaticamente a instância. Assim, seria uma via de mão única. E você poderia dizer: "Nossa, eu posso simplesmente sair desse podcast agora e usar esse recurso e isso é ótimo". Mas, muitas vezes, o que as pessoas querem é alguma compreensão do orçamento. O que eles devem esperar gastar no Atlas? E é aqui que o dimensionamento se torna útil porque lhe dá uma ideia de: "Qual será o meu orçamento do Atlas?"
Nic RaBoy (28:26): Eu queria fazer outro plug desatarado aqui para um capítulo de podcast anterior. Se você quiser saber mais sobre a funcionalidade de auto-scaling do Atlas, nós realmente fizemos um capítulo. Faz parte de uma série com Rez Con do MongoDB. Então, se você está interessado em saber mais sobre isso, confira o capítulo anterior.
michael lynn (28:44): Sim, então o auto-scaling é um recurso incrivel. Então, o que eu ouvi, Jay, é que você pode subimplantar e aumentar manualmente enquanto analisa os fragmentos e analisa o monitoramento. Ou você pode implementar um tamanho de instância relativamente pequeno e confiar no MongoDB para escalá-lo automaticamente.
Jay Runkel (29:07): Com certeza, e se seu chefe vier até você e disser: " Quanto vamos gastar em novembro no Atlas? " Talvez você Go examinar algumas dessas análises sobre as quais estamos falando para descobrir: " Bem, de que tamanho de instância realmente precisamos ou para onde espero que essa lista nos aumente para que eu possa ter uma ideia do que dizer ao meu chefe. "
michael lynn (29:27): Com certeza. Essa é a única extremidade da igualdade. A outra extremidade da igualdade é o desempenho. Portanto, se você estiver abaixo do dimensionamento e esperando que o auto-scale entre em ação, provavelmente experimentará algumas dores na frente do usuário, certo?
Jay Runkel (29:42): Então depende. Se você tiver um volume de trabalho que vai dar grandes passos. Quero dizer, não há como a Atlas saber que, no momento, você está fazendo consultas 10 por segundo e, na segunda-feira, está fazendo uma grande iniciativa de marketing e espera que sua base de usuários cresça. A partir da tarde de segunda-feira, em vez de 10 consultas por segundo, você terá mil consultas por segundo. Não há como o Atlas prever isso. Portanto, se esse for o caso, você deve escalar manualmente o cluster antes disso, para não ter problemas. No entanto, como alternativa, se você adicionar alguns usuários todos os dias e, com o tempo, eles carregarem cada vez mais dados, de modo que a utilização esteja crescendo em um ritmo linear, estável e agradável, o Atlas deverá ser capaz de prever, "Ei, essa tendência vai continuar," e escalá-lo, e você provavelmente terá uma escala automática perfeita e uma boa experiência do cliente.
Michael Linn (30:40): Então, parece uma ótima rede de segurança. Você pode fazer o seu, fazer sua lição de casa, fazer seu dimensionamento, certificar-se de que está informando suas decisões sobre o esquema e vice-versa e, em seguida, fazer uma aposta, mas também contar com o dimensionamento automático para selecionar o mínimo e também especificar um máximo para o qual você deseja escalar.
Jay Runkel (30:57): Com certeza.
michael lynn (30:58): Uau. Então, cobrimos muito território.
Nic Raboy (30:59): Então, eu tenho algumas perguntas, já que você realmente faz interface com os clientes. Quando você está trabalhando com eles para tentar encontrar uma solução de dimensionamento ou uma solução de dimensionamento para eles, você já chegou ao cenário em que, sabe de uma coisa, o cliente presumiu que precisaria de tudo isso, mas, na realidade, eles precisam de muito menos ou o contrário?
Jay Runkel (31:19): Então, acho que ambos os cenários são verdadeiros. Acho que há clientes que estão acostumados a usar bancos de dados relacionais e fazer dimensionamentos para eles. E esses clientes geralmente ficam satisfeitos quando veem quanto hardware precisam para o MongoDB. Geralmente, dado o fato de que o MongoDB é um document model e usa muito menos juntas, os requisitos do servidor para satisfazer o mesmo volume de trabalho do MongoDB são significativamente menores do que um banco de dados relacional. Acho que também encontramos clientes que têm cargas de trabalho de volume muito alto e talvez também tenham expectativas orçamentárias irrealistas. Talvez seja a primeira vez que eles têm que lidar com o problema da escala que estão enfrentando atualmente. Então, às vezes, isso requer alguma educação e trabalho com esse cliente.
Michael Lynn (32:14): Existem ferramentas disponíveis que os clientes podem usar para ajudá-los nesse processo?
...normalmente, o tamanho do índice é 10% do tamanho dos dados. Mas se você quiser ser mais preciso, o que você pode fazer é que existem ferramentas disponíveis, uma delas se chama Faker ...
Jay Runkel (32:18): Então, há algumas coisas. Conversamos sobre tentar descobrir quais são os tamanhos dos nossos índices e coisas assim. E se você não tiver, digamos que esteja apenas começando a projetar o aplicativo. Você não tem dados. Você não sabe quais são os índices. É muito difícil fazer esses tipos de estimativas. Então há algumas coisas que você pode fazer. Uma delas é que você pode usar alguma regra prática, como normalmente o tamanho do índice é 10% do tamanho dos dados. Mas se você quiser ser mais preciso, o que você pode fazer é que existem ferramentas lá fora, uma delas é chamada Faker for Python. Há um site chamado Mockaroo que permite que você simplesmente gere um conjunto de dados. Você essencialmente fornece um documento e essas ferramentas ou sites gerarão muitos documentos e você poderá carregá-los no MongoDB. Você pode construir seus índices. E então você pode apenas medir o tamanho de tudo. Essas são algumas ferramentas que lhe dão a capacidade de descobrir qual será pelo menos o tamanho do índice do conjunto de trabalho apenas criando um conjunto de dados.
michael lynn (33:16): Sim. Ame essas ferramentas. Portanto, mencionando-os novamente, eu os utilizei amplamente em exercícios de dimensionamento. Mockaroo é um ótimo online. É apenas em uma página da web e você especifica a forma do documento que deseja e o número de documentos que deseja criar. Há um nível gratuito e depois um nível pago. E então o Faker é uma biblioteca JavaScript que usei muito para gerar documentos falsos.
Jay Runkel (33:37): Sim. Eu acho que também está disponível em Python.
michael lynn (33:40): ótimo. Sim. Fantástico.
Nic Raboy (33:41): Sim, isso é demais. Se as pessoas tiverem mais perguntas sobre o dimensionamento de seus possíveis clusters MongoDB , você participa ativo nos fóruns da MongoDB Community por acaso?
Jay Runkel (33:56): Sim, definitivamente estou. Sinta-se à vontade para entrar em contato comigo e ficarei feliz em responder a qualquer uma de suas perguntas.
Nic Raboy (34:03): Sim, então isso é community.MongoDB.com para quem nunca esteve em nossos fóruns antes.
michael lynn (34:09): fantástico. Jay, cobrimos muito terreno em pouco tempo. Espero que isso tenha sido realmente útil para os desenvolvedores. Obviamente é um assunto sobre o qual poderíamos conversar por muito tempo. Gostamos de manter os capítulos em torno 30 a 40 minutos. E acho que estamos certos nesse momento. Há mais alguma coisa que você gostaria de compartilhar com as pessoas que estão ouvindo e que querem aprender sobre tamanhos?
Java (34:28): Então, eu dei uma apresentação sobre o dimensionamento no MongoDB World 2017 e esse vídeo ainda está disponível. Então, se você Go apenas MongoDB acessar o site do e Atlas Search por e dimensionamento, você o encontrará. E se você quiser ter uma visão ainda mais detalhada do dimensionamento no MongoDB, você pode dar uma olhada nessa apresentação.
Nic RaBoy (34:52): Então 2017 está há algum tempo atrás em anos de tecnologia. Ainda é um conteúdo válido?
Jay Runkel (35:00): Não acredito que tenha mencionado a palavra Atlas nessa apresentação, mas os conceitos ainda são válidos.
Michael Lynn (35:06): Então, incluiremos um link para essa apresentação nas notas do programa. Certifique-se de procurar por isso. Onde as pessoas podem encontrar você nas redes sociais? Você é ativo no espaço social?
Jay Runkel (35:16): Você pode entrar em contato comigo no Twitter em @jayrunkel. Eu tenho uma conta no Facebook e coisas assim, mas não presto muita atenção nisso.
michael lynn (35:25): Ok, ótimo. Bem, Jay, foi uma ótima conversa. Muito obrigado por compartilhar seu conhecimento sobre o dimensionamento do MongoDB. Nic, mais alguma coisa antes de Go?
Nic Raboy (35:33): Não, é isso. Isso foi fantástico, Jay.
Jay Runkel (35:36): Agradeço muito que vocês tenham me recebido.
michael lynn (35:38): da mesma forma. Tenha um ótimo dia.
Jay Runkel (35:40): Tudo bem. Muito obrigado.
Locutor 2 (35:43):Obrigado pela escuta. Se você curtou este capítulo, por favor curta e se inscreva. Tem uma pergunta ou uma sugestão para o show? Visite-nos no MongoDB Community em https://www.mongodb.com/community/forums/.
Determinar a quantidade correta de recursos de servidor para seus bancos de dados envolve uma compreensão dos tipos, quantidade e padrões de leitura/gravação dos dados. Não existe uma fórmula máxima que funcione em todos os casos. Graças a Ele por nos ajudar a explorar o processo. Ele montou uma apresentação do MongoDB World 2017 que ainda é muito aplicável.
Avalie esse Podcast