‫Jonas: Bem-vindo de volta.
‫Portanto, agora vamos falar
‫um pouco sobre o desempenho de leitura no MongoDB,
‫por que algo chamado de índices é tão
‫importante e como podemos realmente criá-los.
‫E eu quero começar esta demonstração sobre índices disparando uma
‫consulta simples em todos os nossos tours.
‫Então, vamos vir aqui para obter
‫todos os passeios e
‫também filtrarei por um preço inferior a 1.000.
‫Ok e então vamos ver.
‫Sim, obtemos três resultados de volta, certo.
‫E isso é importante ter em
‫mente para o que vou mostrar a
‫seguir, que é que também podemos obter algumas estatísticas
‫sobre a consulta em si.
‫Então, vamos basicamente para a função de manipulador.
‫E então, lembre-se disso agora mesmo na fábrica de manipuladores.
‫Certo, então é isso, eu acho que está
‫no fundo.
‫Sim, é isso, pegue todas as funções de
‫fábrica que irão criar este manipulador que
‫é chamado para a consulta que acabamos de executar.
‫E aqui na consulta,
‫na verdade, agora adicionarei um método de explicação.
‫Ok, então após a consulta iremos então chamar o explain all right.
‫E então vamos dar uma olhada nisso.
‫E agora obtemos um resultado completamente diferente,
‫que são basicamente essas estatísticas.
‫Agora, há um monte de coisas aqui.
‫Mas
‫estou realmente interessado nessas estatísticas de execução, certo.
‫Você pode ver aqui que
‫o número de documentos devolvidos foi três.
‫E esse é exatamente o resultado que obtivemos antes.
‫Então, antes de fazer a explicação certa.
‫Mas o que é realmente importante
‫notar aqui
‫é que o número de documentos examinados é nove, certo.
‫E isso significa que o MongoDB teve
‫que examinar, basicamente, digitalizar todos os nove documentos
‫para encontrar os três corretos.
‫Portanto, os três que correspondem à consulta estão bem.
‫E isso não é nem um pouco eficiente, certo?
‫Agora, é claro, nessa
‫escala, com apenas nove documentos, não faz absolutamente nenhuma diferença.
‫Mas se tivéssemos centenas de
‫milhares, ou mesmo milhões de documentos
‫aqui, isso afetaria significativamente
‫o desempenho de leitura desta consulta.
‫Então, novamente, não será o caso neste aplicativo, mas pode
‫ser em um aplicativo que você criará algum dia.
‫E então você realmente precisa aprender sobre índices.
‫Porque com os índices,
‫poderemos meio que resolver esse problema.
‫Portanto, podemos criar índices em campos específicos em uma coleção.
‫Por exemplo, o Mongo cria automaticamente um
‫índice no campo ID por padrão.
‫E vamos realmente ver que no Compass está bem.
‫Por exemplo, em todos os passeios, temos aqui a guia de índices.
‫Então, até este ponto, nós só estivemos aqui
‫na guia de
‫documentos, mas como você pode ver, temos muitas coisas diferentes
‫aqui e uma delas são os índices.
‫E, novamente, você vê que, por padrão, temos um índice de ID.
‫E esse índice de ID é basicamente uma lista ordenada
‫de todos os IDs que são armazenados
‫em algum lugar fora da coleção.
‫E você pode ver
‫um tamanho aqui, que tem 36 kilobytes, esse índice certo.
‫E este índice é extremamente útil.
‫Porque sempre que os documentos
‫são consultados pelo ID, o MongoDB pesquisa aquele índice ordenado em vez de
‫pesquisar por toda a coleção e olhar
‫todos os documentos um por um, o
‫que é obviamente muito mais lento.
‫Então, novamente, sem um índice, o Mongo precisa olhar
‫cada documento um por um.
‫Mas com um índice no campo que estamos consultando,
‫esse processo se torna muito mais eficiente.
‫Então isso é muito inteligente, certo?
‫E, claro, podemos definir nossos próprios índices
‫em campos que consultamos com frequência.
‫Então, vamos realmente fazer isso com o
‫campo de preço que acabamos
‫de consultar antes, porque acredito que é um
‫dos mais importantes que as pessoas consultarão, certo.
‫E é assim que funciona.
‫Portanto, precisamos ir para o modelo de passeio certo.
‫E então vamos fazer isso bem aqui após esta declaração
‫interna e dizemos tourschema. índice ok.
‫E então um objeto com o nome do
‫campo e lembre-se de como eu
‫disse que iríamos definir o índice do preço e então um ou um menos.
‫E um significa que estamos classificando o
‫índice de preços
‫em ordem crescente, enquanto o menos significa ordem decrescente.
‫Na verdade, também existem outros tipos de índices, como para
‫texto ou para dados geoespaciais, mas veremos
‫isso um pouco mais tarde.
‫Ok, então vamos salvá-lo
‫agora e tentar nossa consulta novamente.
‫E, na verdade, vou fazer isso algumas vezes
‫aqui para ter certeza de que o índice está realmente definido.
‫Porque às vezes não é definido imediatamente.
‫Mas agora vamos dar uma olhada aqui.
‫E assim, de fato, ainda temos nosso número de devolvidos em três, mas
‫desta vez o número de documentos que foram examinados,
‫de modo que foram digitalizados, também foi de apenas três.
‫E isso prova que com
‫esse índice basicamente conseguimos exatamente o que queríamos.
‫Portanto, antes tínhamos que digitalizar todos os nove documentos e
‫agora o mecanismo só precisa digitalizar os três documentos
‫que também foram devolvidos.
‫E novamente porque seus
‫preços agora estão ordenados nesse índice.
‫E isso torna muito mais fácil
‫e rápido para o mecanismo do MongoDB localizá-los.
‫E, portanto, é claro que é um grande ganho de desempenho.
‫Vamos agora também verificar o Compass aqui e, na
‫verdade, vamos recarregar todo o banco de dados, e agora
‫ele realmente deveria estar
‫aqui, mas por algum motivo não está.
‫Vamos tentar recarregar os documentos.
‫Talvez apareça então.
‫Na verdade, não, vamos analisar também o esquema, e isso é
‫algo sobre o qual
‫falaremos um pouco mais tarde.
‫Mas, como você pode ver, ainda temos apenas esses dois índices.
‫Mas isso não importa porque já
‫sabemos que o índice está realmente funcionando direito?
‫Portanto, é
‫completamente normal que às vezes leve algum tempo para atualizar.
‫Agora, outra coisa que você pode notar aqui
‫é como este índice de ID
‫de que falamos anteriormente diz que é único aqui.
‫E tão único também é uma propriedade
‫que podemos dar aos índices.
‫E esta é realmente a
‫razão pela qual os IDs devem ser sempre únicos.
‫Simplesmente porque o
‫índice do ID tem essa propriedade única.
‫Você provavelmente também percebeu que existe um índice
‫para o nome aqui, certo?
‫Mas não criamos isso manualmente, certo?
‫Então você consegue adivinhar por que está aqui?
‫Bem, é porque em nossa definição de esquema, definimos
‫o campo de nome para ser único.
‫E então o que o
‫Mongos faz nos bastidores para garantir a exclusividade desse
‫campo é criar um índice exclusivo para ele, certo.
‫E por isso, não só o ID,
‫mas também o nome sempre tem que ser único.
‫Ok e isso já é ótimo.
‫Portanto, quando tudo o que fazemos é
‫consultar apenas um único campo,
‫um índice de campo único é perfeito porque
‫lembre-se de que o índice que
‫acabamos de definir é chamado de índice de campo único.
‫Não tenho certeza se mencionei isso naquela época, mas acho que sim.
‫Mas, de qualquer forma, se às vezes consultarmos
‫esse campo, mas combiná-lo com outro,
‫então é realmente
‫mais eficiente criar um índice composto.
‫Portanto, um com dois campos e não apenas um.
‫Então, vamos criar uma consulta para isso apenas para ilustrar.
‫E então outro campo que
‫acho que será consultado o tempo todo é a média de avaliações.
‫Portanto, as classificações médias, acho que é assim que se chama, e digamos que
‫queremos maior ou igual a 4. 7 ok.
‫Vamos enviar essa consulta.
‫E vamos ver quantos resultados obteremos.
‫Onde fica isso?
‫Sim aqui.
‫Então, o número de
‫resultados, então o número de documentos que são
‫retornados, para que correspondam a esta consulta, é dois.
‫Mas ainda tivemos que examinar três documentos.
‫E de novo, nessa escala, é claro,
‫isso não faz nenhuma diferença.
‫Mas, como você entende, este é apenas um exemplo.
‫E agora queremos corrigir a situação também e,
‫para isso, usaremos um índice composto.
‫Então, vamos voltar aqui.
‫Comente este aqui.
‫Ou, na verdade, primeiro duplique-o e depois comente.
‫E, na verdade, é muito simples.
‫Tudo o que precisamos fazer é adicionar aqui o outro campo.
‫Então, as avaliações são médias e vamos colocar esta
‫em ordem crescente.
‫Ou, na verdade, essa é a ordem decrescente, certo.
‫Então, vamos salvar isso.
‫Vamos voltar aqui.
‫E, novamente, vou fazer isso algumas vezes aqui, certo.
‫E vamos ver nossos resultados.
‫E agora temos o resultado que queríamos.
‫Portanto, apenas dois documentos foram digitalizados
‫para localizar os dois documentos que estávamos realmente procurando.
‫Perfeito e, na verdade, este índice composto que acabamos
‫de criar também vai funcionar quando a consulta de
‫apenas um desses dois campos aqui individualmente, ou seja,
‫média de preço ou classificação.
‫Portanto, quando criamos um índice composto como
‫este, não precisamos criar um
‫indivíduo para cada um dos campos, ok.
‫Eu só quero verificar como fica no Compass agora.
‫Mas bem, ainda parece o mesmo.
‫Mas, novamente, não é realmente importante.
‫Uma coisa que ainda podemos ver
‫aqui e que
‫é bem interessante é o tamanho desses índices.
‫Portanto, 72 kilobytes é, na verdade, muito maior do que
‫o tamanho total de todos os documentos combinados,
‫que é apenas 14 kilobytes, certo?
‫Basicamente, esses índices que criamos para
‫pesquisar os documentos ocupam muito mais espaço do
‫que os próprios documentos.
‫Mas, novamente, isso é apenas porque estamos
‫operando em uma escala muito pequena neste exemplo.
‫E isso não é realmente relevante, ok.
‫Mas ainda é importante falar sobre
‫isso porque, na verdade, isso me leva à nossa próxima pergunta.
‫E a
‫questão é: como decidimos qual campo realmente precisamos indexar?
‫E por que não definimos índices em todos os campos?
‫Bem, meio que usamos a estratégia que
‫usei para definir os índices de preço e avaliação média.
‫Então, basicamente, precisamos estudar cuidadosamente os padrões de acesso
‫de nosso aplicativo para descobrir quais campos
‫são mais consultados e, em
‫seguida, definir os índices para esses campos.
‫Por exemplo, não estou definindo um índice aqui no tamanho do grupo
‫porque não acredito
‫realmente que muitas pessoas irão consultar esse parâmetro e,
‫portanto, não preciso criar um índice lá.
‫Porque realmente não queremos exagerar nos índices.
‫Portanto, não queremos definir índices cegamente em todos os
‫campos e, basicamente, esperar o melhor.
‫E a razão
‫para isso é que cada índice realmente
‫usa recursos, como você pode ver aqui direito.
‫Além disso, cada índice precisa ser atualizado sempre
‫que a coleção subjacente for atualizada.
‫Portanto, se você tem uma coleção com uma alta proporção de leitura
‫e gravação, ou seja, uma coleção que é
‫principalmente gravada, então não faria absolutamente
‫nenhum sentido criar um índice em qualquer campo desta coleção, porque
‫o custo de sempre atualizar o índice
‫e manter ele na memória claramente supera o benefício
‫de ter o índice em primeiro lugar
‫se raramente temos pesquisas,
‫portanto, temos consultas para essa coleção.
‫Portanto, em resumo, ao decidir se
‫indexar um determinado campo ou não,
‫devemos meio que equilibrar a
‫frequência das consultas usando aquele campo exato
‫com o custo de manutenção desse índice e
‫também com o padrão de leitura e gravação do recurso.
‫No entanto, assim como acontece com a modelagem de
‫dados, não existem regras realmente rígidas aqui.
‫Então é tudo um
‫pouco confuso e você realmente precisa
‫de alguma experimentação e também experiência para acertar, tudo bem.
‫Mas faça o que fizer, não ignore apenas a indexação.
‫Porque mesmo que não
‫seja perfeito, sempre terá um grande benefício para sua aplicação.
‫Tudo bem, e isso é tudo o
‫que tenho a dizer sobre índices.
‫Há apenas mais um índice que desejo definir aqui,
‫que é para o tour ok.
‫Porque mais tarde iremos realmente
‫querer usar o slug exclusivo para consultar os passeios.
‫Isso significa que o slug provavelmente se
‫tornará o campo mais consultado.
‫E, portanto, faz
‫todo o sentido também ter um índice para aquele.
‫Portanto, tourschema. índice
‫e slug um.
‫E na maioria das vezes, um ou menos não é tão importante.
‫Ok, agora estou realmente curioso para tentar
‫ver isso aqui no Compass.
‫Então, o que vou fazer é tentar me conectar ao banco
‫de dados novamente aqui.
‫E posso pegar aqui apenas a partir dos mais recentes.
‫Clique, conecte e então devemos nos conectar ao
‫mesmo banco de dados.
‫Então, natours, tours, vamos aos nossos índices.
‫E agora vamos nós.
‫Portanto, agora temos nossos índices bem aqui.
‫Então, vamos aumentar esta janela
‫e dar uma olhada no que temos.
‫Portanto, temos nossa lesma aqui.
‫Temos o preço, que é o primeiro que definimos.
‫E também temos a média de preços e avaliações,
‫que é composta e você também vê aqui
‫que este aqui é crescente e este está
‫decrescente porque tem o menos.
‫E outra coisa que você pode notar é
‫que, na verdade,
‫não temos mais esse índice de preços em nosso código.
‫Mas ainda está aqui.
‫E, portanto, não é suficiente remover o índice
‫do nosso código, realmente precisamos excluí-lo do próprio banco de dados direito.
‫Portanto, lembre-se de que o tínhamos aqui
‫no início e, em
‫seguida, comentamos e criamos este novo índice
‫composto, mas novamente o índice está parado aqui.
‫Mas, como não precisamos
‫mais dele, podemos simplesmente ir em frente e excluí-lo.
‫Agora precisamos digitar o nome apenas para ter
‫certeza de que não cometemos erros.
‫E aqui vamos nós, ótimo.
‫Então esse é o poder dos índices.
‫Eles realmente podem tornar nosso desempenho de
‫leitura em bancos de dados muito, muito melhor.
‫E, portanto, em
‫seus próprios aplicativos, você nunca deve ignorá-los.
‫E antes de terminar, vamos retomar aquele
‫método de explicação que adicionamos
‫aqui em nossa função de manipulador.
‫E, na verdade,
‫apenas como referência, vou deixar aqui assim, ok.
‫Dê uma chance.
‫De volta ao menu de postagens.
‫Vamos tentar isso agora.
‫E, de fato, ele voltou a funcionar.
‫Ok e agora é isso mesmo.