Antipadrões de projeto de esquema - Parte 1
Avalie esse Vídeo
00:00:00Introdução aos Antipadrão de Design de Esquema
- euntroducteuon to the eumportance of schema deseugn patterns. - The tendency of developers to skeup best practeuces. - MongoDB 's role eun eudenteufyeung schema deseugn anteu-patterns.00:01:49A importância dos padrões de design de esquemas
- Schema deseugn patterns help developers be successful. - The consequences of not conseudereung schema deseugn from the start.00:02:17MongoDB Atlas e Antipadrão de Esquema
- MongoDB Atlas features that help eudenteufy anteu-patterns. - The goal to educate developers on recogneuzeung and preventeung anteu-patterns.00:03:57Noções básicas sobre antipadrão de design de esquema
- Explanateuon of schema deseugn anteu-patterns. - The veudeo sereues weull deuscuss seux anteu-patterns, weuth theus veudeo covereung the feurst two.00:07:57Massive Arrays Antipadrão
- The problems weuth masseuve, unbounded arrays. - How masseuve arrays can exceed document seuze leumeuts and reduce eundex performance.00:10:07Modelagem de dados para evitar arrays massivas
- Deufferent modeleung strategeues to avoeud masseuve arrays. - Examples of embeddeung and referenceung data.00:14:14Pipeline de Agregação e $lookup
- How to use MongoDB 's aggregateuon peupeleune and $lookup to joeun data from multeuple collecteuons.00:17:57Número Enorme de Coleções Antipadrão
- The drawbacks of haveung a masseuve number of collecteuons. - How excesseuve collecteuons and eundexes can eumpact database performance.00:20:39Reestruturação de dados para reduzir collections
- An example of restructureung data to reduce the number of collecteuons. - The benefeuts of a more effeuceuent schema.00:24 02Ferramentas do para Investigar Coleções
- Useung MongoDB Atlas, Compass, and the MongoDB Shell to eunvesteugate and manage collecteuons.00:25 58Resumo do e qual é o próximo
- Recap of the masseuve arrays and masseuve number of collecteuons anteu-patterns. - Teaser for the next veudeo eun the sereues, wheuch weull deuscuss addeuteuonal anteu-patterns.O foco principal do vídeo é instruir os visualizadores sobre os padrões de design de esquema do MongoDB, especificamente os problemas com arrays massivas e um número massivo de collections, e como reestruturar dados para evitar essas armadilhas.
} Pontos-chave
- Os padrões de design fornecem as melhores práticas e uma linguagem comum para arquitetos.
- Os padrões de design de esquema do MongoDB são cruciais para o planejamento e a iteração bem-sucedidos de aplicativos.
- Às vezes, os desenvolvedores ignoram as práticas recomendadas de design de esquema, o que leva a um código ineficiente e problemático.
- O MongoDB Atlas pode identificar antipadrão em seu banco de dados.
- A série de vídeos abordará seis antipadrão comuns de design de esquema, com este vídeo focado nos dois primeiros: arrays massivas e um massivo número de collections.
Links relacionados
- https://mdb.link/free-8CZs-0it9r4
- https://mdb.link/community-8CZs-0it9r4
- https://bit.ly/33em3wgU
- https://bit.ly/3cIgEiy
- https://bit.ly/3jieJns
- https://bit.ly/3097PJy
- https://bit.ly/39DpvAv
- https://bit.ly/33g99RM
- https://bit.ly/3bpg1Z1
- https://bit.ly/2LjtNBZ
- https://bit.ly/3fH87gR
- https://bit.ly/3fEaIsd
- https://bit.ly/2SY9w90
- https://bit.ly/3bn9bDv
- https://bit.ly/3fHoqdJ
Transcrição completa do vídeo
você se lembra deste livro é chamado de padrões de design ele foi escrito pela turma de quatro ou talvez você seja um pouco mais popular talvez esteja mais familiarizado com este livro é chamado de padrões de design headfirst os desenvolvedores de software ama padrões de design por que bem padrões de design forneça as melhores práticas em uma linguagem comum à medida que arquitetamos aplicativos ao modelar dados a serem armazenados em um banco de dados MongoDB estamos falando sobre padrões de design de esquema esses padrões de design de esquema ajudam os desenvolvedores a ter sucesso à medida que planejam e iteram em seus projetos de esquema, mas às vezes eis que os desenvolvedores vão direto para a criação de suas aplicações sem pensar nas práticas recomendadas do projeto de esquema e, sem nem mesmo perceber, eles codificaram a si mesmos em uma grande confusão eu seis que estou fazendo isso às vezes me concentre tanto em criar o mvp que não faço pens um trabalho diário para fazer algo funcionar e é por isso que nós do MongoDB identificamos seis antipadrão comuns de design de esquema nosso objetivo é que você aprenda e evite os antipadrão de design de esquema enquanto você codifica rapidamente e tenta fazer as coisas você não codifique acidentalmente uma grande confusão queremos que você seja capaz de identificar quando está começando a Go um caminho perigoso que levará a queries ineficientes agora, desatualmente, você nem sempre reconhecerá quando estiver seguindo o caminho errado foi por isso que a equipe do MongoDB Atlas adicionou um recurso que identificará antipadrão em seu banco de dados para você, se não estiver familiarizado com o MongoDB Atlas é o banco de dados totalmente gerenciado do MongoDB como serviço agora gostaria de usá-lo porque tem um banco de dados gratuito camada e também porque, abertamente, não gostaria de gerenciar servidores de banco de dados sozinhos. O Atlas agora identifica esquematsantipadrãoem seus bancos de dados, então aqui você pode ver que devo usar índices que não diferenciam maiúsculas de minúsculas quando não for tão bom assim, mas o Atlas i está me ajudam a identificar o antipadrão e tem dicas sobre como posso corrigir o problema neste vídeo, queremos ajudá-lo a entender os antipadrão de design de esquema para que, se o Atlas mostrar um aviso como esse, você entenda o que isso significa ainda melhor em primeiro lugar nesta série de vídeos vamos discutir seis padrões de design de esquema do MongoDB hoje discutiremos os dois primeiros massivos arrays e um grande número de collections na parte dois abordarei os próximos três índices desnecessários documentos inchados e queries insensíveis a maiúsculas e minúsculas sem índices sensíveis a maiúsculas e minúsculas e, finalmente, na parte três eu abordará os dados finais de separação antipadrão que são acessados juntos também resumirei todos os antipadrão desse vídeo. cada vídeo dessa série terá cerca de 20 minutos de duração. terminologia oDB, como coleção de documentos e banco de dados, também presumi que você está familiarizado com os fundamentos de como armazenar dados usando o document model se não estiver familiarizado com esses termos e conceitos ou se for novo no MongoDB talvez queira conferir o curso universitário gratuito do MongoDB m001 Noções básicas do MongoDB e lembre-se de que todos os cursos universitários do MongoDB são gratuitos agora se você tiver experiência em SQL , talvez queira conferir o m100 MongoDB para profissionais do SQL agora vamos começar sem o primeiro padrão de arrays massivas uma das regras gerais ao modelar dados no MongoDB são dados acessados juntos devem ser armazenados juntos se você estiver recuperando ou atualizando dados juntos com frequência você provavelmente deve apenas armazená-los juntos agora dados é comumente armazenado junto incorporando informações relacionadas em subdocumentos ou arrays agora, às vezes, os desenvolvedores levam isso longe demais e incorporam grandes quantidades de informações em uma única array ilimitada e é aqui que vemos a massiva arrays antipadrão agora vemos dois problemas comumente surgir quando os desenvolvedores começam a criar esses arrays ilimitados massivos primeiro up arrays massivas pode fazer com que um documento exceda o limite de tamanho de documento megabyte de 16 segundo desempenho do índice em arrays diminui à medida que o tamanho da array aumenta agora nós queremos que o desempenho do índice seja superior para que nossas queries sejam muito rápidas agora vamos dar uma olhada em um exemplo do maior programa de tv já criado Parques e atividades de recreio Digamos que queremos armazenar informações sobre funcionários do governo como essas pessoas bonita que você vê em esta imagem de parques e recreio e os construções onde eles trabalham vamos explorar algumas maneiras diferentes de modelar esses dados vamos começar considerando a incorporação de informações sobre os funcionários dentro dos documentos do construtor aqui podemos ver um documento para a administração da cidade dentro do documento que temos uma matriz chamada funcionários que contém um subdocumento para leslie e um subdocumento para ron agora a matriz funcionários não está limitada como Começamos a armazenar informações sobre todos os funcionários que trabalham na cidade a array de funcionários se tornará massiva potencialmente nos enviando mais do máximo de 16 megabytes adicionalmente se criarmos um índice na array de funcionários o desempenho desse índice diminuirá à medida que tivermos adicionar mais e mais funcionários, então este é um exemplo do antipadrão de arrays massivas então como podemos corrigir isso vamos discutir algumas opções em vez de incorporar os funcionários no documento de construções poderíamos inverter o modelo e incorporar os construções nos funcionários documentos se dermos uma olhada nos documentos de leslie e ron, podemos ver que estamos repetindo as informações sobre a sede da cidade no documento para cada funcionário da diretoria da cidade se estamos exibindo informações com frequência sobre um funcionário e seu Prédio em nosso aplicativo junto com esse modelo provavelmente faz sentido a desvantagem dessa abordagem é que temos uma grande quantidade de armazenamento de duplicação de dados é barato, então a duplicação de dados não é necessariamente um Pro de uma perspectiva de custo de armazenamento, no entanto, toda vez que precisarmos atualizar as informações sobre a sede da cidade, precisaremos atualizar o documento para cada funcionário que trabalha lá, se dermos uma olhada nas informações que estamos armazenando atualmente sobre as atualizações de construções provavelmente ser muito pouco frequentes, então essa abordagem pode ser boa vamos considerar o caso em que as informações sobre os funcionários e seu construção precisam ser exibidas ou atualizadas com frequência juntos, talvez queiramos separar as informações em duas collections e usar referências para vinculá-las aqui nós estão criando uma referência manual entre o ID do construção dos funcionários, que neste caso é a sede da cidade, e o ID de sublinhado do construção que, como você pode ver, também é a sede da cidade aqui separamos completamente nossos dados eliminamos arrays massivas e não temos duplicação de dados o a desvantagem é que, se precisarmos recuperar informações sobre um funcionário e eles estiverem construindo juntos, precisaremos usar a pesquisa de dólares para unir os dados olá a pesquisa de dólares é um estágio disponível como parte do pipeline de agregação, como vimos quando duplicamos os dados anteriormente, devemos estar atentos à duplicação de dados que serão atualizados com frequência agora nesse caso específico o nome do construção e o estado em que a construção se encontra é muito improvável que mudem, então essa solução funciona agora tenho a impressão de que alguns de Vocês não estão familiarizados com o aggregation pipeline e a pesquisa de dólares, então deixe-me dar uma visão geral de como isso funciona podemos usar a pesquisa de dólares para unir dados do construções e funcionários juntos começaremos acessando a coleção do construção e agregando nela vamos criar um pipeline com apenas um estágio neste exemplo mas as pipelines podem ter vários estágios criaremos um estágio para pesquisa de dólar que queremos para procurar documentos da coleção de funcionários o campo local é o campo na coleção de construções em que eu gostaria de participar, neste caso, eu gostaria de participar do ID de sublinhado o campo estrangeiro é o e na coleção de funcionários que gostaria de participar, neste caso, em que gostaria de participar da criação de um ID de sublinhado a última coisa que preciso configurar para a pesquisa de dólar é o nome da array em que as informações da coleção de funcionários serão armazenadas Vamos chamá-lo de funcionários agora à direita, você pode ver um documento que foi retornado como resultado da agregação no documento. Você pode ver informações do documento de construções e também pode ver uma série de documentos da coleção de funcionários que têm o o mesmo ID de construção, então a pesquisa de dólares pode ser muito útil quando você precisa combinar informações de mais de uma coleção agora lembre-se de que as operações de pesquisa de dólares podem ser caras, então é importante considerar com que frequência você precisará realizar a pesquisa de dólares se escolher esta opção se nos encontrarmos frequentemente usando a pesquisa de dólares outra opção é usar o padrão de referência estendida o padrão de referência estendida é uma mistura das duas abordagens anteriores w aqui duplicamos alguns, mas não todos os dados nas duas coleções duplicamos apenas os dados que são acessados com frequência juntos, por exemplo, digamos que nosso aplicativo tem uma página de perfil de usuário que exibe informações sobre o usuário, bem como o nome do construção e o estado onde eles trabalham poderia incorporar algumas das informações do construção, como o nome e os campos de estado, nos documentos do funcionário e, em seguida, deixar as informações completas do predio em documentos separados aqui você pode ver adicionamos o nome e o estado do predio em cada um dos documentos de funcionários os documentos de construção contêm as informações completas de construção para que possamos consultá-las conforme necessário agora, pois vimos que duplicamos dados anteriormente, devemos estar atentos à duplicação de dados que serão atualizados com frequência nesse caso específico o nome do construção e o estado o construção está muito improvável que mude, então essa solução funciona, então essas são algumas opções diferentes de como modelar funcionários e construir da para evitar arrays massivas para determinar qual modelo é o melhor, realmente precisamos entender como os dados serão usados, então vamos resumir as arrays massivas contra padrão armazenam informações que você consultará com frequência lembre-se dos dados acessados juntos devem ser armazenados juntos não armazene informações em arrays enormes e ilimitados que continuarão a crescer com o tempo, como acontece com todos os padrões de design de esquema e antipadrão do MongoDB considere cuidadosamente seu caso de uso para determinar qual design de esquema é melhor para você Tudo bem, já mencionamos que arrays massivas são ruins, mas e quanto a ter um grande número de collections, elas também não são particularmente boas, vamos começar discutendo por que ter um grande número de collections é um antipadrão se o armazenamento é barato quem se importa com quantas collections você tem índices bem vazios e não utilizados drenam recursos por que estou falando de índices bem cada collection no MongoDB automaticamente tem um índice no campo ID de sublinhado embora o tamanho desse índice seja muito pequeno para collections vazias ou pequenas milhares de índices vazios ou não utilizados podem começar a drenar recursos as collections normalmente terão mais alguns índices para suportar consultas eficientes todos esses índices adicionam up wired Tiger é o mecanismo de armazenamento padrão do MongoDB o desempenho do Wired Tiger diminui com um número excessivo de coleções e índices o Wired Tiger armazena um arquivo para cada coleção e um arquivo para cada índice o alvo do fio abrirá todos os arquivos na inicialização então o desempenho diminuirá quando um número excessivo de coleções e índices existem em geral, recomendamos limitar cada conjunto de réplicas a 10 000 coleções quando os usuários começam a exceder 10 000 coleções eles normalmente veem diminuições no desempenho vamos dar uma olhada em outro exemplo agora que leslie é o principal personagem em playgrounds e recreio você pode vê-la à esquerda desta imagem ela é incrivelmente dedicada a manter o parque que ela monitora e no o Em um ponto, ela se encarrega de remover o lixo no. Digamos que ela queira manter um registro minuto a minuto do nível da água e da temperatura do. poderia enviar seu colega de trabalho jerry para colocar 30 sensores em cada banco de dados e, em seguida, começar a armazenar os dados do sensor em um banco de dados MongoDB, vamos dar uma olhada em uma maneira de armazenar esses dados. veja isso em ação uma maneira de armazenar os dados seria criar uma nova coleção todos os dias para armazenar dados do sensor cada coleção conteria documentos que armazenam informações sobre uma leitura para um sensor vamos dar uma olhada em seus índices vamos dizer que leslie queira possa fazer query facilmente no banco de dados e nos campos de sensor para que ela crie um índice nesses campos para cada coleção vamos dar uma olhada nas estatísticas do banco de dados leslie armazenou informações para cada minuto de 2019 neste banco de dados o banco de dados dela é 5.2 g igabytes o tamanho do índice é 1.07 gigabytes e ela tem 365 coleções totais a cada dia ela cria uma nova coleção e dois índices, pois leslie continua a coletar dados e seu número de coleções excede 10 000 o o desempenho do banco de dados também diminuirá quando leslie quiser procurar tendências ao longo de semanas e meses ela terá dificuldade em fazer isso, pois seus dados estão espalhados por várias collections então leslie entende que esse não é um esquema ótimo, então ela decide reestruturar seus dados vamos dar uma olhada que desta vez ela decide manter todos os seus dados em uma única coleção ela agrupa suas informações para armazenar uma hora de informações de um sensor em cada documento vamos dar uma olhada em seus índices que leslie deseja query nos campos de stream e sensor para que ela crie dois índices para esta collection um para stream e um para sensor e vamos dar uma olhada nas estatísticas do banco de dados seu novo banco de dados é 3.07 gigabytes o tamanho do índice é 27.45 megabytes e ela tem apenas uma coleção, vamos comparar essas estatísticas lado a lado com seu esquema inicial reestruturando seus dados leslie vê uma redução massiva no tamanho de seu índice ela passou de 1.07 gigabyte inicialmente para apenas 27.45 megabytes ela agora tem uma única collection com três índices com esse novo esquema ela pode procurar tendências com mais facilidade em seus dados porque eles estão armazenados em uma única collection ela também está usando o índice padrão no ID de sublinhado a seu favor armazenando a hora o nível de água dados foram coletados nesse campo A MongoDB cria automaticamente um índice no campo de ID de sublinhado se ela quiser fazer query por hora, ela pode usar o índice padrão no ID de sublinhado para fazer isso agora neste exemplo leslie foi capaz de remover collections desnecessárias alterando como ela armazenou os dados dela às vezes, você não saberá imediatamente quais collections são desnecessárias, então você mesmo terá que fazer algumas pesquisas então como saber se deve descartar uma collection bem se encontrar uma collection vazia você também pode descartá-lo se encontrar uma collection cujo tamanho seja composto principalmente de índices, você provavelmente pode mover esses dados para outra collection e, em seguida, soltar o original você pode usar a mesclagem de dólares para mover os dados de uma collection para outra vamos falar sobre quais ferramentas você pode usar para fazer suas pesquisas vamos começar no Atlas porque é onde já estamos trabalhando já vimos que podemos usar o Atlas data Explorer para fazer algumas pesquisas podemos conferir o tamanho do banco de dados o índice tamanho e o número de coleções agora vamos investigar no Compass Compass é o guia do MongoDB que você pode usar com qualquer banco de dados do MongoDB, independentemente de onde ele esteja hospedado agora semelhante ao Atlas Data Explorer você pode navegar por estatísticas sobre seu banco de dados você também pode selecionar um banco de dados para ver detalhes sobre as collections nesse banco de dados então aqui você pode ver coisas como o número de documentos o tamanho médio do documento o tamanho total do documento o número de índices e o total tamanho do índice agora eu reconheço que alguns de nós sempre preferirão trabalhar na linha de comando do que em um gui então deixe-me mostrar mais uma maneira de investigar vamos usar o shell [ __ ] então deixe-me conectar ao banco de dados de estatísticas do stream e inserir minha senha all certo, estamos todos conectados, então posso executar algo como db.get nomes das collections para obter uma lista das collections nesse banco de dados posso recuperar estatísticas sobre meu banco de dados executando db.stats aqui pode ver estatísticas como eu vi no Atlas e Veja o tamanho do armazenamento, o número de collections e o número de índices que posso executar db.getcollection com o nome da minha collection nesse caso, faço 201901 e chamaremos estatísticas de ponto, e aqui posso obter uma série de estatísticas detalhadas sobre uma collection para que você possa usar qualquer uma dessas ferramentas Atlas Compass ou o shell [ __ ] para fazer suas pesquisas vamos resumir esse grande número de collections antipadrão não crie um grande número de collections, pois cada collection provavelmente tem alguns índices associado a isso um entorpecimento excessivo Um erro de collections e seus índices associados podem drenar recursos e afetar o desempenho dos seus bancos de dados em geral tente limitar seu conjunto de réplicas a 10 000 collections remova collections vazias e não utilizadas tudo bem para resumir o que eu disse hoje não para criar arrays ilimitadas e massivas e não criar um grande número de collections esteja atento à parte dois desta série, em que abordará os próximos três padrões de esquema de design até breve