Série de automação de banco de dados – Índices automatizados
Avalie esse Podcast
Gerenciar bancos de dados pode ser difícil, mas não precisa ser. A maioria dos aspectos do gerenciamento de banco de dados pode ser automatizada e, com uma plataforma como o MongoDB Atlas, as ferramentas não estão apenas disponíveis, mas são fáceis de usar. Nesta série, conversaremos com Rez Kahn, gerente de produto principal do MongoDB, para saber mais sobre algumas das maneiras pelas quais o Atlas automatiza as várias tarefas associadas à implantação, dimensionamento e garantia do desempenho eficiente de seus bancos de dados. Nesta primeira parte da série, nos concentraremos em um recurso embutido no Atlas, chamado Index Autopilog.
Nic RaBoy (00:56): Rez, obrigado por dedicar seu tempo para participar deste capítulo do podcast. Antes de entrarmos no material principal de realmente contar sobre o gerenciamento de banco de dados e as coisas que você pode automatizar, vamos dar um passo para trás e por que você não nos conta um pouco sobre você?
Rez Kahn (01:10): legal. Prazer em estar aqui, null. Meu nome é Rez. Como gerente de produto principal do MongoDB, trabalho no escritório de Nova York. Meu time é responsável por garantir que a experiência de nossos clientes seja a mais surpreendente possível depois que eles implantarem seu primeiro aplicativo no MongoDB, o que significa que trabalham em problemas como o monitoramento do MongoDB. Como garantimos que nossos clientes possam diagnosticar e corrigir problemas que possam surgir com o MongoDB e uma série de outras áreas interessantes, nas quais abordaremos ao longo do podcast.
Nic RaBoy (01:55): Então, quando você está falando sobre o sucesso do cliente, depois que ele começou a usar o MongoDB, você está se referindo apenas ao Atlas? Você está fazendo referência, por exemplo, ao Realm ou a algumas das outras ferramentas que o MongoDB oferece também? Você quer lançar alguma luz?
Rez Kahn (02:10): Sim, essa é uma boa pergunta. Obvia-mente , a intenção da equipe é ajudar com todos os produtos que o MongoDB oferece suporte hoje e que, eventualmente, oferecerá suporte no futuro. Mas, por enquanto, nosso foco tem sido em como aprimoramos a experiência do Atlas e a tornamos a mais Mágica possível depois que um usuário [inaudível 00:02:29] o primeiro aplicativo.
michael lynn (02:30): Há quanto tempo você está no MongoDB e o que você estava fazendo antes de embarcar?
Rez Kahn (02:35): Bem, estou no MongoDB há alguns anos. Antes de ingressar no MongoDB, eu costumava trabalhar em uma tecnologia de publicidade completamente diferente. Passei cinco anos em uma startup de Nova York chamada AppNexus, que acabou sendo vendida para a At&T, e na AppNexus eu também era gerente de produto. Mas, em vez de construir bancos de dados, ou ajudar a gerenciar melhor os bancos de dados, criei produtos para ajudar nossos clientes a comprar anúncios na Internet com mais eficiência. Boa parte eram produtos baseados em aprendizado de máquina. Então, esses seriam sistemas para ajudar a otimizar a forma como você gasta seu dólar em publicidade.
Rez Kahn (03:18): a raiz do problema que estamos tentando resolver é descobrir em quais anúncios os clientes clicariam e, eventualmente, comprariam um produto com base. Como podemos fazer isso da forma mais eficaz e eficiente possível? Antes do AppNexus, eu tinha passado vários anos no campo de pesquisa tentando criar novos tipos de materiais para construir microchips. Então, era ainda mais off-base em comparação com o que estou fazendo hoje, mas é sempre muito interessante ver a relação entre pesquisa e gerenciamento de produtos. Por fim, concluí que era realmente um bom background ter que ser um bom gerente de produtos.
MichaelLynn (03:59): Sim, sugiro que você deva estar muito interessado em trabalhar nessa área, procurando novos materiais para os tokens. Isso é bem impactante. Então, você está a bordo do MongoDB há cinco anos. Você foi direto para o espaço do Atlas como gerente de produto?
Rez Kahn (04:20): Então, estou no MongoDB há dois anos e sim-
Michael Lynn (04:22): Oh, dois anos, desculpe.
Rez Kahn (04:23): Não se preocupar. Foi contratada como o segundo ou terceiro gerente de produto do Atlas, e teve a sorte de trabalhar com o Atlas quando ele era relativamente pequeno para o que é sem dúvidas uma grande parte do MongoDB atualmente.
michael lynn (04:42): Sim. É enormes. Lembrei-me de quando começou que o Atlas não existia, e lembrei-me de quando eles fizeram os primeiros anúncios, apenas internos, sobre esse produto que estaria na nuvem. Eu simplesmente não conseguia visualizar. É tão estranho ver isso agora que se tornou a maior, é indiscutível a maior parte do nosso negócio. Lembrei-me de observar o gráfico à medida que ele representava cada vez mais uma porcentagem de nossa receita bruta. Atualmente, é uma história excepcional e está ajudar muitas pessoas. Um dos maiores desafios que eu tinha antes mesmo de embarcar no MongoDB foi: como você implementa isso?
michael lynn (05:22): Como você configura isso? Se você deseja alta disponibilidade, ela tem. O MongoDB está embutido, está embutido, mas você precisa configurá-lo, mantê-lo e escalá-lo, e todas essas coisas podem levar horas e, obviamente, esforço associado com isso. Então, para ver algo que subiu ao palco e as pessoas simplesmente criaram, fez tanto sucesso. Então, isso é, eu suponha, um pouco de felicitações pelo Atlas e pelo sucesso que você teve. Mas gostaria de saber se você não gostaria de falar um pouco sobre o espaço de problemas em que o Atlas vive. Talvez toque um pouco mais nos elementos de preocupação que os DBAs e desenvolvedores enfrentam nos quais o Atlas pode causar impacto.
Rez Kahn (06:07): Sim, com certeza. Então, minha experiência com o MongoDB é, na verdade, muito semelhante à sua, Mike. Acho que comecei, usei-o pela primeira vez em uma hackathon em 2012. Lembro-me de que, embora tenha sido muito fácil começar a usá-lo, levamos 10 minutos, acho, para executar a primeira consulta e obter dados do MongoDB. Mas quando tivemos que implementar esse aplicativo em produção e gerenciar o MongoDB, as coisas ficaram um pouco mais complicadas. Levamos algumas horas para realmente configurar as coisas, o que é muito na hackathon, porque você tem apenas duas horas para criar tudo. Portanto, não pensei muito sobre o problema que tive no dia da hackatona, quando estava fazendo a hackatona, até chegar ao MongoDB.
Rez Kahn (06:58): Então, aprender sobre o Atlas e vi meu gerente implantar um Atlas cluster e me mostrar um aplicativo e toda a experiência de ter um aplicativo em execução em uma versão de produção do MongoDB dentro de 20 minutos foram absolutamente Mágicos. Indo mais fundo nele, o problema que estamos tentando resolver é esse, sabemos que a experiência de usar o MongoDB é ótima para um desenvolvedor. É muito fácil e rápido criar aplicativos, mas, se você deseja implementar um aplicativo, há uma série de coisas em que você precisa pensar. Você precisa pensar em como configuro a instância do MongoDB para ter vários nós de modo que, se um desses nós ficar inativo, você terá um banco de dados disponível.
Rez Kahn (07:50): Como configuro um backup dos meus dados para que haja uma cópia dos meus dados sempre disponível caso haja uma perda catastrófica de dados? Como faço para monitorar o desempenho do MongoDB e, se houver uma degradação do desempenho, ser alertado de que há uma degradação do desempenho? Depois de receber o alerta, o que preciso fazer para garantir que posso corrigir o problema? Se a maneira de corrigir o problema for que eu precise de uma máquina maior executando o MongoDB, como faço para atualizar uma máquina e garantir que meu banco de dados não perderá a conectividade ou Go ? Então, todos esses não são problemas fáceis de resolver.
Rez Kahn (08:35): em grandes empresas, você tem equipes de DBS que fazem isso, em startups menores, você não tem DBS. Você tem engenheiros de software que precisam gastar um tempo valioso do dia para lidar com todos esses problemas operacionais. Se você realmente pensar sobre isso, essas questões operacionais não são exatamente coisas de valor agregado nas quais se trabalhar, porque você preferiria passar o tempo criando e diferenciando recursos em seu aplicativo. Então, o valor que o Atlas forneceu é que lidamos com todos esses problemas operacionais para você. São literalmente alguns cliques antes de você ter uma produção no MongoDB em execução, com backup, monitoramento, alertas, todos esses configurados como passe de passe.
Rez Kahn (09:20): Se você precisar atualizar instâncias do MongoDB ou precisar Go para uma instância superior e mais poderosa, todas essas coisas também estão a apenas um clique, e leva apenas alguns minutos para para ser configurado para você. Então, em outras palavras, estamos realmente colocando muito tempo de volta nas mãos de nossos clientes para que eles possam se concentrar em construir e escrever código, o que diferencia seus negócios em vez de gastar tempo fazendo trabalho de operações.
michael lynn (09:45): Incrível. Digo, verdadeiramente mágicko. Então, você Falou um pouco sobre o espaço lá. Você mencionou alta disponibilidade, mencionou monitoramento, mencionou implantação inicial e mencionou escalabilidade. Saiba que conversamos antes de iniciar o podcast. Adoraria que essa fosse a introdução à automação do gerenciamento de banco de dados. Como há tanto, provavelmente poderíamos fazer quatro ou cinco capítulos sozinhos, mas, null, você tem uma pergunta?
Nic RaBoy (10:20): Sim, eu só estava para perguntar, então, de todas as coisas que o Atlas faz por nós, eu só estava para perguntar se há algo que ainda exija intervenção do usuário depois que elas implementou um Atlas cluster? Ou é tudo automatizado? Este é o tópico de automação, direito?
Rez Kahn (10:37): Sim. Eu gostaria que tudo fosse automatizado, mas se fosse, eu não teria um trabalho. Então, obviamente há muito trabalho a fazer. A área específica, que é de grande interesse para nós e para a empresa, é que, uma vez implantado um aplicativo e ele estiver dimensionando, ou estiver sendo usado por muitos usuários, e você estiver fazendo alterações no aplicativo, como podemos fazer isso tem certeza de que o desempenho do próprio MongoDB é o mais legal possível? Agora, esse é um problema muito difícil de resolver, porque você pode falar sobre desempenho de muitas maneiras diferentes. Um dos proxies mais obvios do desempenho é quanto tempo leva para obter respostas para uma query de volta.
Rez Kahn (11:30): Você obviamente quer que seja o mais baixo possível. Agora, a maneira de obter uma latência muito baixa em suas queries é que você pode ter uma máquina muito poderosa apoiando essa instância MongoDB, mas a consequência de ter uma máquina muito poderosa apoiando essa instância MongoDB é que pode ser muito cara. Então, como você gerencia, como você garante que os custos sejam gerenciáveis e, ao mesmo tempo, obtenha o melhor desempenho possível é um problema muito difícil de resolver. Muitas pessoas recebem muito dinheiro para resolver esse problema específico. Então, temos que caracterizar esse problema para nós, como rastrear as métricas necessárias para medir custos, medir o desempenho.
Rez Kahn (12:13): Então, precisamos pensar em como detecto quando as coisas estão dando errado. Se as coisas estiverem mal, quais são as estratégias que posso implementar para resolver esses problemas? Felizmente, com o MongoDB, há muitas estratégias que eles podem implementar. Por exemplo, um dos atributos do MongoDB é que você pode ter vários índices secundários, e esses índices podem ser tão complexos ou simples quanto você quiser, mas quando você coloca índices? Quais índices você coloca? Quando você mantém os índices versus quando você os elimina? Essas são todas as decisões que você precisa tomar porque fazer índices não é algo barato, e mantê-los também não é barato.
Rez Kahn (12:57): Então, você precisa fazer uma otimização em sua mente ao criar índices, quando se livre deles. Esse é o tipo de problema que consideramos nossa experiência e como o MongoDB funciona. Os dados de desempenho que estamos capturando de você usando o Mongo DB podem nos ajudar a fornecer a você recomendações mais orientadas por dados. Então, você não precisa se preocupar em fazer esses cálculos em sua cabeça.
michael lynn (13:22): os custos que você mencionou, há custos associados à implementação e manutenção de índices, mas também há custos se você não fizer isso, correto? Se você teme implementar índices, porque acha que pode impactar negativamente seu desempenho tendo muitos índices. Portanto, apenas ter a ferramenta oferece visibilidade da eficácia de seus índices e de sua estratégia de índice. Isso também é forte.
Nic Raboy (13:51): Então, que tipo de visibilidade você conseguiria exatamente? Eu gostaria de pesquisar um pouco mais sobre o assunto. Digamos que eu tenha meu cluster e tenha muitos e muitos índices criados. Isso me informará sobre índices que talvez eu não use há um mês, por exemplo, para que eu possa removê-los? Como ela transmite essas informações para você de forma eficaz?
Rez Kahn (14:15): Sim. O que o sistema faria é manter um registro de todos os índices que você fez. Ele rastreará o quanto você está usando determinados índices. Ele também acompanhará se há sobreposições entre esses índices, o que pode tornar um índice redundante em comparação com outro. Em seguida, realizamos algumas heurísticas em segundo plano para observar cada índice e fazer uma avaliação, como se é possível ou se é uma boa ideia remover esse índice específico, com base na frequência com que ele foi usado nas últimas X semanas . Se são sobreposições com outros índices e todas essas coisas que você pode fazer por si mesmo.
Rez Kahn (14:58): Mas essas são coisas que você precisa aprender sobre o comportamento do MongoDB, o que você pode, mas por que fazer isso se ele pode apenas lhe dizer que isso é algo ineficiente, e essas são as coisas que você precisa para torná-lo mais eficiente.
Michael Lynn (15:13): Então, quero estar ciente de que nem todos os ouvintes do nosso podcast estarão muito familiarizados com os índices, com o conceito de índices. Você poderia nos dar uma breve introdução sobre o que são os índices e por que eles são tão importantes?
Rez Kahn (15:26): Sim, sim. Essa é uma pergunta muito boa. Então, quando você está trabalhando com um ... Então, índices não são algo exclusivo do MongoDB, todos os outros bancos de dados também têm índices. A maneira de observar os índices é uma estrutura de dados especial que armazena os dados de que você precisa de uma maneira que torna muito rápida a recuperação desses dados. Então, um bom exemplo é, digamos que você tem um banco de dados com nomes e números de telefone. Você deseja consultar o banco de dados com um nome e obter o número de telefone dessa pessoa.
Rez Kahn (16:03): Agora, se você não tiver um índice, o que o software de banco de dados faria é verificar cada registro de nome e número de telefone para encontrar o nome que você é está procurando e, em seguida, ele lhe retornará o número de telefone desse nome específico. Agora, esse é um processo muito caro porque, se você tiver um banco de dados com 50 milhões de nomes e números de telefone, isso levaria muito tempo. Mas uma das coisas que você pode fazer com o índice é criar um índice de nomes, que organizaria os dados de uma maneira em que não fosse necessário passar por todos os nomes para encontrar o nome relevante de que você se importa.
Rez Kahn (16:38): ele pode ir rapidamente a esse registro e retornar o número de telefone que lhe é importante. Então, em vez de passar por 50 milhões de linhas, talvez seja necessário passar por algumas centenas de linhas de dados para obter as informações desejadas. De uma hora para outra, suas queries estão significativamente mais rápidas do que seriam se você não tivesse criado um índice. Agora, o desafio para nossos usuários é, como você disse, migo, muitas pessoas podem não saber o que é um índice, mas as pessoas geralmente sabe o que é um índice. O problema é: qual é a melhor coisa possível que você pode fazer pelo MongoDB?
Rez Kahn (17:18): Há algumas coisas que você precisa aprender. Há algumas análises que você precisa fazer, como examinar as queries que está executando para descobrir, quais queries são as mais importantes. Então, para essas queries, você precisa descobrir qual é o melhor índice. Mais uma vez, você pode pensar nessas coisas por si mesmo se quiser, mas há uma maneira analítica e lógica de fornecer, de processar esses números e apenas dizer que este é o índice que é o melhor índice para você neste determinado ponto no tempo. Essas são as razões pelas quais e esses são os benefícios que isso traria a você.
michael lynn (17:51): Então, tudo bem. Bem, os índices pareceram que eu preciso deles, porque tenho um aplicativo e estou procurando números de telefone e tenho muitos números de telefone. Então, vamos indexar tudo no meu banco de dados. Como isso soa?
Rez Kahn (18:05): Pode ser bom, na verdade. Depende de quantos índices você cria. O complicado é que, como os índices são uma estrutura de dados especial, eles ocupam espaço de armazenamento no banco de dados porque você está armazenando, no meu exemplo anterior, nomes de uma maneira específica. Então, você está essencialmente copiando os dados que já tem, mas armazenando-os de uma maneira específica. Agora, isso pode estar bem, mas se você tiver muitos desses índices, precisará criar muitas cópias dos seus dados. Então, ele usa espaço, que poderia, na verdade, ser usado para armazenar novos dados.
Rez Kahn (18:43): Também tem outro efeito em que, se você estiver gravando muitos dados em um banco de dados, toda vez que escrever um novo registro, precisará garantir que todos esses índices sejam atualizados. Portanto, as gravações podem demorar mais porque você tem índices agora. Então, você precisa encontrar um equilíbrio feliz entre quantos índices eu preciso para obter um ótimo desempenho de leitura, mas não ter muitos índices, então meu desempenho de gravação é difícil? Esse é um ato de equilíbrio que você precisa fazer como usuário, ou você pode usar nossas ferramentas e nós podemos fazer isso.
michael lynn (19:11): Go, sim. Logicamente, é preciso fazer o papel de árbitro do reino, mas é importante ter o equilíbrio certo:
Rez Kahn (19:17): Com certeza.
Michael Lynn (19:17): ... e basear o uso do índice no perfil de leitura e gravação do aplicativo. Portanto, é extremamente importante saber o máximo possível sobre o perfil de leitura e gravação, quantas leituras e quantas gravações, qual o tamanho de cada uma. Portanto, esse é o espaço em que ele se encontra. Há algum slogan ou produto da Atlas a que você se refere quando fala sobre esse recurso?
Rez Kahn (19:41): Sim. Há um produto chamado Performance Advisor, que você pode usar por meio da API ou com a UI. Quando você usa o Performance Advisor, ele verifica as queries executadas em seu banco de dados e fornece uma lista classificada de índices que você deve criar com base na importância. Ele dirá por que um determinado índice é importante. Então, temos esse nome muito parvo chamado pontuação de impacto. Ele apenas informaria que esse é o impacto percentual de ter esse índice criado e classificaria as recomendações do índice com base nisso.
Rez Kahn (20:21): Uma das coisas muito legais que estamos construindo é que temos o Performance Advisor há alguns anos, e é um produto bastante popular entre nossos clientes. Nossos clientes que estão criando um aplicativo no MongoDB Atlas ou, se estiverem alterando um aplicativo, a primeira coisa que fazem após a implantação é Go ao Performance Advisor e verificar se há recomendações de índice. Se houver, então, eles o construirão e, milagrosamente, o desempenho de suas queries se tornará melhor.
Então, ao implantar um Atlas cluster, você pode dizer: "Quero que os índices sejam construídos automaticamente." ... à medida que detectamos consultas que não têm um índice e são importantes e causam degradação no desempenho, podemos descobrir automaticamente qual deveria ser o índice.
Rez Kahn (20:51): Como tivemos sucesso com o produto, o que decidimos em seguida foi: por que fazer as pessoas entrarem no Atlas e ver as recomendações, decidir quais desejam manter, e criar o índice manualmente? Por que não apenas automatizar isso para eles? Então, ao implantar um Atlas cluster, você pode dizer: "Quero que os índices sejam construídos automaticamente." Se você ativar a opção, analisaremos proativamente suas consultas nos detalhes e, assim que detectarmos as consultas, que não têm um índice e são importantes e estão causando degradação do desempenho, podemos descobrir automaticamente como qual deve ser o índice.
Rez Kahn (21:36): Em seguida, crie esse índice para você nostrás dos palcos de uma maneira que ele é executado. É um produto que estamos chamando de modo de motorista automático para indexação, que será lançado nos próximos meses.
Nic Raboy (21:46): Tenho uma pergunta sobre a indexação do piloto automático. Você está dizendo que esse é um recurso que pode ser ativado para permitir que ele faça isso por você quando necessário. Então, em relação a isso, ele também removerá os índices que estiverem abaixo do limite de porcentagem ou você poderá definir o limite para a criação de um índice?
Rez Kahn (22:08): Então, responderei à primeira pergunta, que é excluir índices para você. Atualmente, não pode. Então, na verdade, estamos lançando outro produto no Performance Advisor chamado Recomendações de remoção de índice, onde você pode ver recomendações de quais índices precisa remover. A visão geral do produto que temos na empresa é a de que primeiro construímos recomendações. Se as recomendações forem boas, podemos usá-las para automatizar as coisas para nossos clientes. Portanto, o plano é, nos próximos seis meses, fornecer recomendações sobre quando os índices devem ser removidos.
Rez Kahn (22:43): Se recebermos um bom feedback do usuário e se ele for realmente útil, incorporaremos isso no modo de motorista automático para indexação e fará com que o sistema também faça os índices para você. Em relação à sua segunda pergunta, os limites de quando os índices são criados são configuráveis? Essa é uma boa pergunta, porque passamos muito tempo refletindo se queremos conceder esses limites aos usuários. É uma pergunta difícil de responder porque, por um lado, ter botões, mostradores e botões é tentador porque você pode, como usuário, controlar como o sistema se comporta.
Rez Kahn (23:20): Por outro lado, se você não souber o que está fazendo, poderá criar muitos problemas para si mesmo, e queremos estar cientes disso. Então, o que decidimos fazer é não fornecer muitos botões e mostradores no início para nossos usuários. Selecionamos alguns padrões sobre como o sistema se comporta com base na análise que fizemos com milhares de clientes e esperando que isso seja suficiente. Mas temos uma janela para adicionar esses botões e mostrações de volta se houver casos de uso especiais para nossos usuários, mas vamos fazer isso se fizer sentido, obviamente.
Nic Raboy (23:58): A razão pela qual eu perguntava é porque você tem a categoria de desenvolvedores que provavelmente estão abaixo do índice, certo? Então, para ligar esse botão e agora, existe o risco de indexação excessiva agora, nesse sentido?
Rez Kahn (24:12): Essa é uma ótima pergunta. Da forma como construímos o sistema, construímos algumas falhas de segurança nele, onde o risco de indexação excessiva é muito limitado. Então, fizemos algumas coisas muito legais. Uma das coisas que fazem é, quando detectamos que há um índice que podemos construir, tentamos prever coisas como quanto tempo um índice levaria para ser construído. Então, com base nisso, podemos tomar uma decisão, se o construiremos automaticamente ou se daremos ao usuário o poder de dizer sim ou não sobre a criação desse índice. Porque estamos cientes de quanto tempo e recursos essa criação de índice pode levar. Também temos cofres em segundo plano para evitar a criação de índices descontrolados.
Rez Kahn (24:59): Pense que temos esse limite configurável de, esqueço o número exato, como 10 ou 20 índices para collections que podem ser construídas automaticamente. Depois disso, cabe aos usuários decidir construir mais coisas. A parte muito legal é que, uma vez que tivermos as recomendações de remoção e supondo que funcione realmente, se funcionar bem e os usuários aprovarem, poderíamos usar isso como um sinal para remover índices automaticamente, se você estiver criando índices demais. Como um sistema de loop fechado muito organizado, onde construímos índices e observamos como funciona. Se funcionar bem, nós o manteremos. Se não funcionar bem, nós a removeremos. Você pode estar tão livre quanto quiser.
michael lynn (25:40): Isso parece incrivelmente legal. No entanto, devo ter muito temor em torno disso, especialmente por causa da velocidade com que um sistema como o Atlas, com um aplicativo em execução, a velocidade para fazer esses tipos de alterações pode ser cansativa, certo. Para obter feedback contínuo e, em seguida, agir de acordo com esse feedback. Estou apenas curinga: esse foi um dos desafios que você encontrou ao implementar um sistema como esse?
Rez Kahn (26:12): Sim.&Um dos grandes desafios, e falamos muito sobre isso durante a fase de pesquisa e desenvolvimento, é que acreditamos que há duas estratégias para a criação de índices. Há o que chamamos de reativa e há a proativa. Em geral, a reativa é quando você faz uma alteração no aplicativo e adiciona uma consulta que não tem índice, e é uma consulta muito cara. Você quer criar o índice o mais rápido possível para proteger a instância do MongoDB de um problema de desempenho. A questão é: o que é logo? Como você sabe que essa consulta específica seria usada por um longo tempo em vez de ser usada apenas uma vez?
Rez Kahn (26:55): pode ser uma query feita por um analista e é caro, mas só vai ser usado uma vez. Então, não faz sentido construir um índice para ele. Esse é um problema muito difícil de resolver. Então, no início, nossa abordagem foi, sejamos conservadores. Vamos esperar seis horas e observar o que uma query faz por seis horas. Isso nos dá uma quantidade adequada de confiança de que esta é uma query que realmente estará lá por um tempo e, portanto, um índice faz sentido. Isso faz sentido, Mick?
michael lynn (27:28): Sim. Sim. Sensação perfeita. Estou considerando a maior flexibilidade associada ao uso do MongoDB no Atlas. Agora, obviamente, o MongoDB é um banco de dados aberto. Você pode baixá-lo, instalá-lo em seu laptop e usá-lo em servidores em seu centro de dados. Alguma dessas funcionalidades de automação aparecerá no set de produtos que não são do Atlas?
Rez Kahn (27:58): Essa é uma pergunta muito boa. É claro que queremos disponibilizá-lo ao maior número possível de nossos clientes, porque é muito importante ter sistemas como esse. Existem algumas verdades práticas que tornam isso difícil. Uma das verdades é que, quando você está usando o Atlas, as máquinas subjacentes, que estão fazendo backup do seu banco de dados, são algo que podemos configurar rapidamente e adicionar com muita facilidade, pois é o MongoDB que gerencia essas máquinas para você, porque é um serviço que fornecemos. A infraestrutura está oculta para você, o que significa que os recursos de automação, nos quais precisamos alterar as máquinas subjacentes muito rapidamente, só são possíveis no Atlas porque controlamos essas máquinas.
Rez Kahn (28:49): um bom exemplo disso é, e devemos falar sobre isso em algum momento, temos o dimensionamento automático, em que podemos dimensionar automaticamente uma máquina para cima ou para baixo para gerenciar a sua carga. Mesmo que você queira, podemos oferecer esse recurso aos nossos clientes usando o MongoDB no local porque não temos acesso à máquina, mas no Atlas temos. Para indexação automática, é um pouco mais fácil porque é mais uma configuração de software. Então, é mais fácil para nós fornecê-lo a outros locais onde o MongoDB é usado.
Rez Kahn (29:21): Nós com certeza queremos fazer isso. Estamos apenas começando com o Atlas porque é mais rápido e fácil de fazer, e temos muitos clientes lá. Então, são muitos clientes para testar e nos dar feedback sobre o produto.
michael lynn (29:31): Essa é uma ótima resposta. Isso me ajuda a tirar isso da minha cabeça em termos de arquitetura. Então, parece que há uma camada acima ... MongoDB é um processo de servidor. Você se conecta a ele para interagir e gerenciar seus dados. Mas, no Atlas, há uma camada adicional que está no topo do banco de dados e, através dessa camada, temos acesso a todas as estatísticas associadas à forma como você está acessando seu banco de dados. Então, essa camada não existe no MongoDB para download hoje, de qualquer forma.
Rez Kahn (30:06): Não é. Sim, não é.
Michael Lynn (30:08): Sim.
Rez Kahn (30:09): Exatamente.
michael lynn (30:09): Uau, isso é um pouco no espaço de indexação, mas isso é apenas uma peça do quebra-cabeça, certo? As pessoas que estão aproveitando o banco de dados estão tendo dúvidas em várias áreas. Então, sobre o que mais podemos falar neste espaço onde você está resolvendo esses problemas?
Rez Kahn (30:26): Sim. Há muitas, como você mencionou, a indexação é apenas uma estratégia para otimização do desempenho, mas há muitas outras, uma das mais comuns ou incomuns, a quem você puder perguntar isso, qual deve ser o esquema de seus dados e como otimizar o esquema para obter o desempenho ideal? Esse é um espaço de problema muito interessante. Já fizemos muito isso e temos alguns produtos para ajudá-lo a fazer isso também.
Rez Kahn (30:54): Outro problema é: como projetamos, como prevemos qual seria sua carga de trabalho futura para garantir que estamos provisionando a quantidade certa de energia de máquina atrás do seu banco de dados , para obter o melhor desempenho, mas não pagar mais porque está provisionado em excesso? Quando é o melhor momento para ter um shard versus escalar verticalmente, e qual é a melhor chave de shard a ser usada? Esse também é outro espaço de problema interessante para abordarmos. Então, há muito o que dizer [crosstalk 00:31:33] deveremos, em algum momento.
Michael Lynn (31:36): Essas são todas as facetas do produto que você gerencia?
Rez Kahn (31:39): Essas são todas as facetas do produto que eu gerencio, sim. Uma coisa que eu gostaria de convidar nossos usuários a ouvir o podcast, como mencionei antes, estamos construindo essa ferramenta chamada Modo Autopit para Indexação para criar índices automaticamente para você. Ele está em desenvolvimento de engenharia pesada no momento e esperam lançá-lo nos próximos meses. Faremos um programa de visualização privada para esse produto específico, tentando fazer com que cerca de centenas de usuários usem esse produto e obtenham acesso antecipado a ele. Eu encorajaria você a pensar sobre isso e dar uma chance.
Michael Lynn (32:21): Quem pode participar, quem você está procurando para colocar as mãos nisso?
Rez Kahn (32:26): em teoria, deve ser qualquer pessoa, qualquer pessoa que passe muito tempo construindo índices seria candidata perfeita para isso. Todos os nossos usuários do MongoDB passam muito tempo criando índices. Portanto, estamos abertos a qualquer tipo de empresa ou caso de uso e estamos muito ansiosos para trabalhar com você para ver como podemos tornar o produto bem-sucedido e usar seu feedback para criar a próxima versão do produto.
Michael Lynn (32:51): Ótimo. Bem, esta foi uma introdução fenomenal à automação de banco de dados, Rez. Quero agradecê-lo por ter reservado um tempo para conversar conosco. Nick, antes de encerrarmos, há mais alguma pergunta ou assunto que você acha que deveríamos abordar?
Nic Raboy (33:02): Não, não para este período. Se alguém tiver alguma dúvida depois de ouvir este capítulo, entre em nossa comunidade. Então, este é um quadro de fóruns da comunidade, Rez, Jane, eu mesmo, estamos todos ativos nele. É community.mongodb.com. É uma ótima maneira de tirar suas dúvidas sobre automação.
michael lynn (33:21): Com certeza. Rez, você também está lá. Você deu uma olhada em algumas das perguntas que os usuários encontraram.
Rez Kahn (33:27): Sim, eu faço isso ocasionalmente. Não tanto quanto deveria, mas faço isso.
Michael Lynn (33:32): Incrível.
Nic Raboy (33:32): Bem, há uma pergunta que surge, vamos puxar você.
Michael Lynn (33:34): Sim, se tivermos mais perguntas, vamos colocá-lo lá.
Rez Kahn (33:37): Parece bom.
michael lynn (33:38): Incrível. Bem, ótimo, Rez. Mais uma vez obrigado por dedicar um tempo para falar conosco. Vou exigir que você faça isso. Vamos fazer isso em uma abordagem em série. Vamos detalhar todas essas facetas da automação de banco de dados e as abordaremos uma a uma. Hoje foi uma introdução e um pouco sobre o modo autopit para indexação. Próxima página, o que você acha? O que você acha que quer cobrir a seguir?
Rez Kahn (34:01): Ah, vamos escalar.
Nic Raboy (34:02): Adorei.
michael lynn (34:03): dimensionamento e escalabilidade automática. Euadoro. Impressionante. Tudo bem pessoal, obrigado.
Rez Kahn (34:08): Obrigado.
Uma parte importante para garantir o desempenho eficiente do aplicativo é modelar os dados em seus documentos, mas depois de projetar a estrutura de seus documentos, é absolutamente essencial que você continue revisando o perfil de leitura/gravação do seu aplicativo para garantir que tenha indexado adequadamente os elementos de dados lidos com mais frequência. O gerenciamento automatizado de índices do MongoDB Atlas pode ajudar à medida que o perfil do seu aplicativo muda com o tempo.
Certifique-se de verificar os links abaixo para obter sugestões de leitura sobre considerações de desempenho. Se você tiver dúvidas, visite-nos nos Fóruns da Comunidade.
Em nossos próximos episódios desta série, aproveitaremos o conceito de automatização do gerenciamento de banco de dados para discutir a automatização do dimensionamento do banco de dados, a fim de garantir que o aplicativo tenha a combinação certa de recursos com base em seus requisitos.
Confira os seguintes recursos para obter mais informações:
Avalie esse Podcast