Sugestões de esquema com Julia Openhein - Episódio 59 do podcast
Avalie esse Podcast
Hoje, estamos com Julia Oppenheim, Gerente Associada de Produtos no MongoDB. Julia conversa conosco e compartilha detalhes de um conjunto de recursos do MongoDB Atlas criado para ajudar os desenvolvedores a melhorar o design de seus esquemas para evitar antipadrões comuns.
A noção de que MongoDB é sem esquema é um pouco imprópria. Os bancos de dados relacionais tradicionais usam uma entidade separada no banco de dados que define o esquema: a estrutura das tabelas/linhas/colunas e os valores aceitáveis que são armazenados no banco de dados. O MongoDB tem uma abordagem ligeiramente diferente. O esquema existe de fato no MongoDB, mas para ver qual é esse esquema, você normalmente olha para os documentos gravados anteriormente no banco de dados. Com isso em mente, você, como desenvolvedor, tem o poder de tomar decisões sobre a estrutura dos documentos que armazena em seu banco de dados... e, como dizem, com grande poder, vem uma grande responsabilidade.
O MongoDB criou um conjunto de recursos embutidos no Atlas que permitem ver quando suas suposições sobre a estrutura de seus documentos se mostram abaixo do ideal. Esses recursos estão incluídos nas sugestões de esquema e, no episódio de podcast de hoje, Julia Oppenheim se junta a Nic Raboy e eu para falar sobre como as sugestões de esquema podem ajudar você a manter e melhorar o desempenho de seus aplicativos ao expor antipadrões em seu esquema.
Júlia: [00:00:00] Meu nome é Júlia Openhein e bem-vinda ao podcast do Mongo DB. Fique atento para saber mais sobre como melhorar seu esquema e aliviar os antipadrão de esquema com sugestões de esquema e Mongo DB Atlas.
Michael: [00:00:12] E hoje estamos conversando com Julia Oppenheim. Bem vinda ao programa, Julia, é ótimo ter você no podcast. Obrigado. É ótimo estar aqui. Então por que você não se apresenta ao público? Deixe as pessoas saberem quem você é e o que faz no Mongo DB.
Julia: [00:00:26] Sim. Claro. Então, oi, eu sou a Julia. Na verdade, entrei no Mongo DB há cerca de nove meses como gerente de produto na equipe do Rez. Então, sim, eu sabia que você já havia conversado com ele antes. E se você ouviu esses episódios, o Rez provavelmente falou sobre o que nossa equipe faz, que é. Garantir que a jornada do cliente ou a jornada do usuário com o Mongo DB ocorra sem problemas e que suas implementações tenham desempenho. Garantir que os desenvolvedores possam se concentrar no que é realmente empolgante e interessante para eles, como lançar novos recursos, e que não tenham que se estressar com a questão da minha implantação e do meu banco de dados. Você sabe, se haverá algum problema. Tentamos tornar esse processo o mais tranquilo possível.
Michael: [00:01:10] Incrível. E hoje vamos nos concentrar em esquemas, certo. Sugestões de esquema e eliminação de esquema. Antipadrão, então espere o telefone, Manager. Sim, sim, Go em frente, Nic.
Nic: [00:01:22] Pensei que as pessoas chamariam isso de banco de dados sem esquema.
Michael: [00:01:28] Sim, acho que isso é verdade. Com o banco de dados de documentos, não é necessário planejar o esquema com antecedência. Então, talvez Julia, você queira esclarecer por que precisamos de sugestões de esquema no banco de dados Mongo?
Julia: [00:01:41] Sim, não, acho que esse é um ponto muito bom e definitivamente um equívoco comum. Então, acho que uma das vantagens do Mongo é que o esquema pode ser bastante flexível. E não é rígido no sentido de que outros relational database, você sabe, têm um conjunto rígido de regras e como você pode acessar os dados. Serei definitivamente mais tolerante nesse aspecto, mas, no final das contas, ainda assim.
Precisa de determinados tipos de valor de campos e coisas assim, dependendo das necessidades do seu aplicativo. Portanto, uma das primeiras coisas que qualquer desenvolvedor fará é mapear quais são seus casos de uso para seus aplicativos e descobrir como eles devem armazenar os dados para garantir que esses casos de uso possam ser realizados.
Eu acho que você pode ficar um pouco preso ao esquema no MongoDB, é isso. As necessidades do seu aplicativo mudaram ao longo do ciclo de desenvolvimento. Portanto, um esquema que pode funcionar no primeiro dia, quando você sabe, a base de usuários é relativamente pequena, seu conjunto de recursos é bastante limitado. Pode não funcionar. À medida que seu aplicativo se torna Cisco, talvez seja necessário refatorar um pouco, e nem sempre é óbvio como fazer isso.
E, você sabe, não esperamos que os usuários sejam especialistas em MongoDB e em design de esquema com Mongo DB, e é por isso que penso. Destacar antipadrões de esquema é muito útil.
Michael: [00:03:03] Incrível. Então, quer contar um pouco sobre como o produto funciona? Como as sugestões de esquema funcionam no Mongo DB. Atlas?
Julia: [00:03:12] Sim. Portanto, há dois locais em que você, como usuário, pode ver os antipadrões de esquema em que eles estão. A guia de consultor de desempenho, que Rez definitivamente mencionou quando falou sobre piloto automático e sugestões de índices, e você também pode ver os antipadrões de esquema em nosso Data Explorer. Portanto, a guia coleções, e podemos falar um pouco sobre por que as temos em dois lugares separados, mas, em geral, o que você, como usuário, verá é o mesmo.
Então, nós. Para sinalizar os antipadrões de esquema, fornecemos uma breve explicação do motivo pelo qual os sinalizamos. Mostraremos quais coleções são impactadas, você sabe, por esse antipadrão que identificamos e também daremos uma chamada à ação sobre como abordá-las. Então, na verdade, temos Docs sobre os seis antipadrão de esquema que nós.
Procure nesta fase do produto, você sabe, o ciclo de vida, e nós damos algumas etapas sobre como resolvê-lo, qual seria nossa recomendação, e também meio que explicamos, você sabe, por que é um problema e como ele pode realmente voltar a prejudicá-lo mais tarde.
Nic: [00:04:29] Então você jogou fora o esquema de palavras-chave.
Antipadrões, algumas vezes agora, você quer repassar o que você disse? Há seis deles, certo? Queremos saber o que cada um desses seis é.
Júlia: [00:04:39] Sim, claro. Então há, como você disse, há seis. Então, achamos que procuramos o uso de Nossas operações de pesquisa de dólares. Isso significa que é muito, muito semelhante a entrar no mundo relacional, em que você acessaria dados em diferentes collections. E isso nem sempre é o ideal porque você está lendo e executando, você sabe, lógica diferente em mais de uma coleção. Então, em geral, leva muito tempo e um pouco mais de recursos. Você sabe, quando vemos isso, estamos meio que achando que essa pessoa pode ter um passado mais relacional.
Isso não quer dizer que isso seja sempre um problema. Pode fazer sentido fazer isso em certos casos. É aí que as coisas ficam um pouco mais complicadas, mas esse é o primeiro que procuramos. O outro está procurando por arrays ilimitadas. Então, se você apenas continuar. Incorporando informações e não há limite para isso.
O tamanho dos seus documentos pode ficar muito, muito grande. Na verdade, temos um limite estabelecido e esse é um dos nossos terceiros antipadrões. Se você continuar, atingirá nosso limite de 16 megabytes por documento, o que significa isso. Seus documentos mais populares são o conjunto de trabalho, ocupam muito espaço na RAM.
Então, agora vamos ao disco para atender à sua solicitação, que é, você sabe, geralmente novamente, vamos levar algum tempo, é mais recurso, você sabe, consumptivo, coisas assim.
Nic: [00:06:15] Isso pode estar fora do escopo, mas como você evita uma array ilimitada no Mongo DB? Tipo. Entendo o conceito, mas nunca, nunca tinha lido disso em um banco de dados antes, então isso seria novo para eu.
Júlia: [00:06:27] Então, isso vai ser um pouco contraditório em relação ao antipadrão de pesquisa que acabou de mencionar, e acha que podemos falar mais sobre isso. Porque eu reconheço isso quando estava aprendendo sobre antipadrão e eles me pareceram muito contraditórios e me estressou. Então, falaremos sobre isso daqui a pouco, mas da maneira que você evitaria.
A array ilimitada provavelmente seria para fazer referência a outros documentos. Então isso é essencialmente fazer a aparência disso. Desligando o padrão , você tem uma coleção de desenvolvedores e tem informações diferentes sobre o desenvolvedor, como a equipe deles no Mongo DB.
Você sabe há quanto tempo eles estão aqui e talvez você tenha todas as confirmações de obtenção e confirmação. Pode ser um documento incorporado. Pode ter a data do commit e em qual projeto estava e coisas assim. Um desenvolvedor pode ter, você sabe, infinitamente muitos commits, como talvez eles apenas confirmem muito e não haja limite para isso.
Então você sabe, é um relacionamento um para muitos e. Se isso estivesse em uma matriz, acho que todos nós vemos que isso provavelmente atingiria esse limite de 16 megabytes. Em vez disso, talvez queiramos considerar fazer é criar uma coleção de commits, onde a vincularíamos ao desenvolvedor que fez o commit e a referenciaríamos no documento original do desenvolvedor.
Não sei se essa analogia foi útil, mas é assim que você lidaria com isso.
Michael: [00:08:04] Eacho que o principal aqui é que você toma essas decisões sobre como projeta seu esquema. Você não é forçado a normalizar os dados de uma maneira em todo o banco de dados, como faz no mundo relacional.
Então, você tomará uma decisão sobre o número de elementos em uma matriz potencial versus o custo de armazenar esses dados em coleções separadas e fazer uma pesquisa. E. Obviamente, você sabe, você pode começar, embarcar em sua jornada para desenvolver um aplicativo, pensando que suas matrizes estarão dentro do escopo de um número relativo e relativamente baixo.
E talvez o padrão de uso mude ou o número de usuários altere o número de desenvolvedores que usam seu aplicativo muda. E em algum momento você pode precisar mudar isso. Então, deixe-me fazer a pergunta sobre o. O caso de usuário quando estou interagindo com o Mongo DB Atlas, e meu caso de uso muda. Meu padrão de usuário muda.
Como isso vai aparecer? Como vai surgir no produto que agora eu violei os limites do que é um padrão aceitável. E agora estou no escopo de um antipadrão.
Julia: [00:09:16] Certo. Portanto, quando isso acontece, o melhor lugar para sinalizá-lo é a guia do consultor de desempenho. Então, temos um pequeno cartão que diz: "Melhore seu esquema". E se tivermos antipadrões sinalizados, mostraremos o número de sugestões. Você pode clicar nele para saber mais sobre elas. E o que fazemos ali é baseado em. Uma amostra de seus dados. Portanto, tentamos capturá-las de forma reativa. Veremos que algo está acontecendo e lhe daremos uma sugestão para melhorar.
Então, para fazer isso, gostamos de analisar seus dados. Tentamos determinar quais collection são importantes, quais collection você está realmente usando. Portanto, com base no número de leituras e gravações nas collection, identificaremos suas principais collection 20 e depois. Veremos o que está rolando. Vamos procurar, você sabe, o padrão nervoso, alguns dos quais mencionei e meio que apenas coletar, tudo isso está acontecendo nos bastidores, a propósito, vamos meio que coletar, você sabe, distribuições de, você sabe, tamanho médio de dados, nossas pesquisas acontecendo, você sabe, apenas procurando alguns desses antipadrões que mencionei, e então determinaremos quais. Você pode realmente corrigir quais são mais impactantes, quais são realmente um problema. E então mostramos isso ao usuário.
Nic: [00:10:35] Então, ele está monitorando o tipo de queries que você está fazendo ou está apenas observando, com base em como seus documentos são estruturados quando sugere um esquema?
Julia: [00:10:46] Sim. Ele procura principalmente como seus documentos estão estruturados. A pesquisa de dólar é um pouco complicada porque é uma operação que acontece nos bastidores, mas se baseia no fato de que você está fazendo referência a coisas dentro do documento.
Michael: [00:11:00] Ok. Então conversamos sobre as arrays ilimitadas. Nós conversamos sobre três antipadrão até agora. Você deseja continuar na viagem de anti-patterns?
Júlia: [00:11:10] Ok. Sim. Sim, não, definidamente. Portanto, um que também sinalizamos está no nível do índice, e isso é algo que também está disponível no Porphyry Performance Advisor em geral.
Então, se você tem índices desnecessários na collection, isso é problemático porque um índice que acabou de existir, você sabe, consome recursos, ocupa espaço e. Ele pode diminuir a velocidade, gravar, mesmo que diminua a velocidade das leituras. Então, é como acontece com os índices em geral, mas há o caso em que o índice não está realmente fazendo nada e pode estar meio obsoleto.
Talvez seus padrões de query tenham mudado e coisas assim. Portanto, se você tiver índices excessivos em sua collection, sinalizaremos isso, mas direi que, no consultor de desempenho, agora temos recomendações de remoção de índices. Diremos que este é o índice real que você deve remover. Então, um pouco mais granular, o que é bom.
Então, outro que temos é reduzir o número de collection que você tem em geral. Então, a certa altura, as collection, novamente, consomem muitos recursos. Você tem índices nas coleções. Você tem muitos documentos. Talvez você esteja referenciando coisas que podem ser incorporadas. Esse é mais um sinal de que você pode querer refatorar seu cenário de dados no Mongo DB.
Michael: [00:12:36] Ok. Falou-se sobre vários, em padrões até agora, falou-se no uso da pesquisa de dólares, armazenando arrays ilimitadas em seus documentos. Já conversamos sobre ter muitos índices. Falei sobre ter um tamanho de documento grande em suas collections. Falei sobre muitas collections.
E então eu acho que o último que precisamos encobrir é sobre quadrados que não diferenciam maiúsculas de minúsculas e rejeitam quadrados. Quer falar um pouco sobre isso?
Julia: [00:13:03] Sim. Então. Assim como com os outros antipadrões, vamos procurar ver quando você tem consultas que estão usando red jacks que não diferenciam maiúsculas de minúsculas e recomendar que você tenha o índice apropriado.
Portanto, pode ser insensível a maiúsculas e minúsculas. Índice, pode ser um índice do Atlas Search, coisas assim. Ou seja, você sabe, o último antipadrão que sinalizamos.
Michael: [00:13:25] Ok. Ok, ótimo. E, obviamente, você sabe, qualquer tipo de operação no banco de dados exigirá recursos. E a ideia aqui é que há um equilíbrio entre aproveitar o recurso e operar com eficiência.
Então, esse é um recurso de produto disponível no Mongo, DB, Atlas. Todas essas coisas estão disponíveis hoje. Correto? Sim. E você poderá ver essas sugestões na guia do consultor de desempenho, certo?
Júlia: [00:13:55] Sim. Performance Advisor. E também, como mencionei, nosso Data Explorer, que são nossas coleções. Sim. Correto.
Michael: [00:14:02] Sim. Incrível. Todo o objetivo de. Automatizar o gerenciamento de banco de dados é facilitar a interação do desenvolvedor com o banco de dados. O que mais queremos dizer ao público sobre sugestões de esquema ou qualquer coisa neste espaço de produto? Então, Júlia: [00:14:19] Talvez eu queira destacar o que você acabou de mencionar, que, você sabe, seu esquema altera os antipadrão que podem ser, você sabe, mais nocivos para o seu desempenho.
Mude com o tempo e realmente depende da sua carga de trabalho e de como você está acessando os dados. Você sabe, alguns desses antipadrão da FMA entram em conflito uns com os outros. Digo que em alguns casos você deve reduzir as referências e em outros casos não deve, isso realmente depende, você sabe, são dos dados que você deseja acessar juntos, que estão sendo armazenados juntos.
E faz isso. Faz sentido. Portanto, nem todos sempre se aplicam. Será meio situacional e é por isso que estamos aqui para ajudar.
Nic: [00:15:01] Então, quando as pessoas estão usando o Mongo DB para criar documentos em suas coleção oito níveis de profundidade. As sugestões de esquema ajudarão nesses cenários a tentar melhorar como as pessoas criaram seus dados?
Julia: [00:15:23] Definitivamente, as sugestões de esquema ainda estão em seus primeiros dias. Acho que lançamos esse produto há quase um ano. Com certeza capturaremos qualquer um dos seis antipadrões que acabamos de mencionar se eles estiverem ocorrendo em alto nível.
Portanto, se você estiver aninhando muitas coisas no documento, isso provavelmente aumentará. Você sabe, o tamanho do documento e nós sinalizamos isso. Talvez não consigamos direcionar isso para dizer, é por isso que seu documento tem tamanhos tão grandes. Mas acho que essa é uma chamada muito boa e é seguro dizer que sabemos que não estamos capturando todos os cenários que um usuário pode encontrar com seu esquema.
Você pode realmente fazer o que quiser ao projetar seus documentos do Mongo DB. Estamos pesquisando ativamente quais sugestões de esquema faz sentido procurar em nossa próxima iteração desse produto. Então, se você tiver feedback, você sabe, não hesite em entrar em contato. Gostaríamos muito de ouvir seus comentários.
Então, sim, definitivamente há algumas limitações em que estamos trabalhando nisso. Estamos investigando.
Michael: [00:16:27] Ok. Digamos que eu seja desenvolvedor e tenha várias collections que talvez não sejam acessadas com tanta frequência, mas estou preocupado com os padrões delas. Como posso forçar o consultor de desempenho a analisar uma collection específica?
Julia: [00:16:43] Sim, essa é uma pergunta muito boa. Então, como mencionei antes, apresentamos os antipadrões em dois lugares. Um deles é o consultor de desempenho, que é para o caso de uso mais reativo, em que fazemos uma varredura, vemos o que está acontecendo e as 20 coleções mais ativas e mais ou menos. Fazendo alguma lógica para determinar onde as mudanças mais impactantes poderiam ser feitas.
E também há a aba de collections no Atlas. E é aqui que você pode Go dizer que está desenvolvendo ativamente ou adicionando documentos à coleção. Eles ainda não são muito usados, mas você quer ter certeza de que está no caminho certo. Se você visualizar o esquema e os antipadrão, ele principalmente executará nosso algoritmo para você.
E nós vamos. Pesquise uma amostra de coleções para isso, ou desculpe, uma amostra de documentos para essa coleção e exiba as sugestões lá. Então é um pouco mais direcionado. E eu diria muito útil para quando você está desenvolvendo algo ativamente ou tem uma pequena carga de trabalho.
Michael: [00:17:39] Temos uma grande conferência em julho. É Mongo, db.live. A minha primeira pergunta é: você vai estar lá? Você está talvez fazendo uma apresentação sobre esse assunto em.live?
Júlia: [00:17:50] Não estou fazendo uma apresentação sobre esse assunto em.live, mas Estarei lá. Estou muito, muito ansioso por isso.
Michael: [00:17:56] Incrível. Bem, talvez possamos convidar você para o dia da comunidade, que é a semana seguinte, quando temos conversas, sessões, jogos e todo tipo de coisas legais para a comunidade. Talvez possamos fazer com que você fale um pouco sobre isso no evento que seria. Isso seria fantástico. I'm be.live é a nossa maior conferência de usuários do ano. Encheu-se a nós em 13julho e 14julho. É grátis. Está tudo online. Há uma programação enorme de keynotes e sessões de discussão de ponta.
Todos os tipos de me perguntam qualquer coisa, painéis e atividades de quebrar o córneo muito mais. Você pode obter mais information@mongodb.com shard live. Tudo bem, null, mais alguma coisa a adicionar antes de começarmos a envolver?
Nic: [00:18:36] Nada para nós. Tipo, Júlia, há mais alguma palavra de ordem de última hora ou qualquer coisa que você queira dizer ao público sobre sugestões de esquemas com o banco de dados mongo ou qualquer coisa que os ajude? Sim,
Júlia: [00:18:47] Acho que não. Pense que cobrimos muito novamente. Eu gostaria apenas de enfatizar que você sabe, não fique sobrecarregado. O esquema é muito importante para o Mongo DB. E deve ser flexível. Estamos aqui para ajudá-lo.
Nic: [00:19:00] Essa é a palavra-chave aqui. Não é um esquema menos. É apenas esquema flexível, direito?
Julia: [00:19:05] Yes, yes, yes.
Michael: [00:19:05] Sim. Bem, Julia, muito obrigado. Essa foi uma ótima conversa.
Julia: [00:19:09] Incrível. Obrigado por me receber.
Avalie esse Podcast