Os índices suportam a execução eficiente de consultas no MongoDB. Sem índices, o MongoDB deve digitalizar todos os documentos em uma coleção para retornar resultados da consulta. O que são Índices no MongoDB? Estruturas de Dados: Índices no MongoDB são estruturas de dados que melhoram a velocidade de consulta ao permitir o acesso eficiente aos documentos em uma coleção. Baseados em Campos: Podem ser criados em um ou vários campos de um documento, permitindo a otimização de consultas específicas. Se existir um índice apropriado para uma consulta, o MongoDB usa o índice para limitar o número de documentos que deve digitalizar. Mas nada como exemplo prático, certo? Vamos conhecer mais dos índices e testá-los? Índice de campo único: Índices de campo único armazenam informações de um único campo em uma coleção. Por padrão, todas as coleções possuem um índice no _id campo. Você pode adicionar índices adicionais para acelerar consultas e operações importantes. Vamos trabalhar com um banco de sample_mflix, que comporta dados de filmes, abaixo, um exemplo de modelo do nosso documento da coleção movies. E agora queremos fazer uma busca de filmes que obtiveram mais de 3 vitórias em indicações a prêmios. Considerando o nosso modelo sem índice, percebemos: • Nº de documentos examinados: 25.314; • Documentos retornados: 7060, • Tempo de execução: 36ms. E agora, com índice criado: • Em 28ms, todos os 7060 documentos foram encontrados. Índice composto: No caso anterior, em que buscamos em uma query simples somente filmes cujo venceram mais de três indicações aos prêmios, pode ser complementado pelo diretor do filme. Assim, não seria mais interessante termos um índice composto por directors e awards.win?(http://awards.win) Sem sombra de dúvidas, teria mais eficiência na busca. Mas vamos agora a um ponto importante no momento da criação de um índice composto: A ordem dos campos em um índice composto pode afetar o desempenho das consultas, especialmente em consultas que buscam por uma combinação específica de campos. Vamos ver essas diferenças aplicadas ao nosso caso? Sem índice composto: • 52ms de query. • Mais de 25 mil documentos examinados, e • 18 documentos retornados. Com índice desordenado: db.movies.createIndex({ "awards.wins": 1, "directors": 1  }) • index keys examined: 162 • documents examined: 18 • documents returned: 18 Apesar de ter usado os índices percebemos o seguinte, conforme a ordenação do índice, primeiro foi buscado todos os diretores (total de 162 diretores) cujo receberam mais de três prêmios em suas indicações, após esse filtro, foi buscado filmes que foram dirigidos somente por Woody Allen. Índice composto correto: db.movies.createIndex({ "directors": 1, "awards.wins": 1 }) Assim: • index keys examined: 18 • documents examined: 18 • documents returned: 18 Com o índice {"directors": 1, "awards.wins": 1}, o MongoDB começa a busca por "directors" e depois por "awards.wins". Assim, essa ordem demonstra ser mais eficiente para a consulta específica que você está executando. O número menor de index keys examined indica que o MongoDB precisou analisar menos chaves no índice para encontrar os documentos correspondentes. Índice multichave: db.movies.createIndex({ "genres": 1 }) Para a nossa coleção exemplo, vamos criar um índice multichave que abrange múltiplos campos que são arrays, como “genres” e “cast”. Abaixo, sem índice criado. • Documents Examined: 25314, • Documents Returned: 3703. Com índice criado: Índice de texto: Vamos imaginar que utilizamos os plots dos filmes para fazer recomendações com base nos interesses dos usuários. De que forma poderíamos buscar palavras chaves nesses plots para recomendar filmes, sem o uso de índice: db.movies.find({ "plot": { $regex: "prostitution", $options: "i" } }) Primeiro detalhe é o uso do $regex, conhecido por expressões regulares, que nos ajuda a definir uma forma de identificar padrões em cadeias de caracteres (strings). O uso do “$options: i” diz respeito a insensibilidade para palavras maiúscula ou minúsculas. Abaixo, sem uso de índice: Com o índice criado: db.movies.createIndex({plot: 1}) Nesse momento, apesar do índice acima ser criado, ele se caracteriza por ser índice de campo único, ele é útil para consultas que envolvem um campo específico, como por exemplo “love”. O correto, para criar índice textual é: db.movies.createIndex({ "plot": "text" }) Índice Geoespacial: Os índices 2dsphere suportam consultas geoespaciais em uma esfera semelhante à Terra. Para por exemplo, os índices 2dsphere podem • Determinar pontos dentro de uma área especificada. • Calcule a proximidade de um ponto especificado. • Retorna correspondências exatas em consultas de coordenadas. • Abaixo, exemplos de casos de uso: Use índices 2dsphere para consultar e realizar cálculos em dados de localização onde os pontos de dados aparecem na Terra ou em outra superfície esférica. Para exemplo: • Um aplicativo de entrega de comida usa índices 2dsphere para dar suporte procura restaurantes próximos. • Um aplicativo de planejamento de rotas usa índices 2dsphere para calcular a distância mais curta entre as paradas para descanso. • Um planejador urbano usa índices 2dsphere para encontrar parques que existem dentro de limites da cidade. Os índices de hash e clusterizados têm suas próprias aplicações e contextos específicos no MongoDB. Índice de hash: São úteis para distribuir os dados de forma uniforme entre os nós do cluster. Podendo ser aplicados em situações que a distribuição uniforme dos dados é mais importante do que a ordenação, ou acesso sequencial. Não são apropriados para consultas que envolvem ordenação ou faixa de valores, já que não mantém ordem dos valores armazenados. Índice clusterizado: São úteis em situações em que os dados são frequentemente acessados em ordem específica ou quando consultas sequenciais são comuns. Eles organizam fisicamente os documentos de acordo com o campo específico. E então? O que você achou desse artigo, consegui te ajudar? Espero que sim. Em casos de dúvidas, não exite em perguntar/comentar, ficarei feliz em ajudar!

Quando iniciamos a modelagem de dados em MongoDB, precisamos obter respostas para perguntas pertinentes na construção dessa modelagem. Isso porque, um bom modelo de dados irá alavancar os recursos do banco de dados, e explorar o seu modelo de documento flexível. A modelagem de dados com MongoDB difere dos modelos tradicionais, pois não segue a normalização como primeira etapa, a flexibilidade que o MongoDB oferece facilita o mapeamento de documentos para uma entidade ou objeto. O esquema de modelagem no MongoDB abrange três etapas importantes do processo: carga de trabalho, identificação de relacionamento e padrões de design. 1. Carga de trabalho: Esse processo identifica dados relevantes, define como devem ser capturados e processados, e visualiza esses dados como um diagrama. Essa representação visual ajuda a identificar componentes de dados, determinar relacionamentos e encontrar a melhor maneira de demonstrá-los. 2. Relacionamentos, e 3. Padrões. Com base nisso, duas perguntas devem guiar nossa modelagem: 1. Quais são as principais peças de dados, ou entidades armazenadas? 2. Qual dessas entidades muda a longo prazo? 3. Quais tipos de operações serão feitas? IDENTIFICANDO CARGAS DE TRABALHO NO BANCO DE DADOS  Imagine o desenvolvimento de um aplicativo para resumir livros. Nele, os usuários podem criar resumos de livros lidos, detalhando os principais pontos, insights e informações relevantes. Cada resumo pode conter uma síntese do conteúdo, ideias-chave, conclusões e observações pessoais, proporcionando uma visão geral do livro para referência futura ou compartilhamento com outros leitores.   Aqui precisamos:  • Dimensionar os dados;  • Quantificar as operações, e  • Qualificar as operações.  De maneira simplificada, como realizar uma análise da carga de trabalho desta aplicação. E acima, fica evidente que a leitura de resenhas se destaca no exemplo dado. Com isso, vamos aprofundar o detalhamento: IDENTIFICANDO RELACIONAMENTOS Agora, precisamos compreender os relacionamentos entre as entidades de dados que compõe nosso modelo. Portanto, existem maneiras em que os objetos se relacionam podendo ser: um para um, um para muitos, muitos para um, ou muitos para muitos. E a conclusão dessa etapa resulta em um modelo lógico para nossos dados. Portanto, precisamos: • Identificar os relacionamentos; • Quantificar os relacionamentos, e • Referenciar ou incorporar. E por fim, agora, vamos definir se ao construir nosso modelo nós vamos referenciar ou incorporar os dados em um documento só. Aqui, é importante mencionar a regra de ouro da modelagem de dados em MongoDB: O que é usado junto na aplicação, é armazenado junto no banco de dados. Agora, vamos para as especificações de escolhas entre Referenciar e Incorporar: Referenciar: • Quando o lado “muitos” é um número enorme; • Para integridade em operações de escrita nos relacionamentos muitos para muitos, • Quando uma parte é usada com frequência, mas a outra não é, e a memória é uma restrição. Incorporar: • Para a integridade das operações de leitura; • Para integridade de operações de escrita um para um, e um para muitos; • Para dados que são excluídos ou arquivados juntos, • Se não souber, sempre, preferencialmente, incorporar. IDENTIFICANDO PADRÕES Os padrões tornam a modelagem de dados mais eficiente. Com os padrões de design, é mais fácil acomodar mudanças nos requisitos e estrutura de aplicativos. Aqui, vou abordar dois padrões, mas existem outros diversos que podem se encaixar nas mais diversas modelagens de dados: • Computed: São computações frequentes que tendem a reduzir o desempenho do banco, por exemplo, se uma resenha recebe uma enorme quantidade de comentários. Com o computed evita a necessidade de consultar todos os comentários cada vez que uma contagem é necessária, assim, a contagem de comentários já está disponível no documento, facilitando o acesso aos dados. • Extended Reference (Referência estendida): É uma técnica em que um documento faz referência a outro, mas não somente uma referência básica, este inclui todas as informações relevantes no próprio documento. Isso contribui para a redução de necessidades de consultas adicionais para buscar informações relacionadas. CONSTRUINDO NOSSO MODELO Bom, entendemos que nosso aplicativo serve para que cada usuário fique livre para escrever quantas resenhas desejar dos livros que já tenha lido. Assim, entendemos que podemos ter a coleção de usuários e resenhas. Podemos entender que um usuário pode escrever pouco, mas também pode ser alguém muito ativo, e, portanto, se encaixa em um para muitos. Assim, o lado muitos seria enorme, sugerindo que a referência seria a melhor das hipóteses. Vou exemplificar como seria Referenciado: No caso dos comentários, que se enquadram no modelo de relacionamento 'muitos para um', entendemos que, como a regra de ouro nos diz, ao acessarmos uma resenha, desejamos imediatamente ter acesso aos comentários. Portanto, o ideal seria a incorporação dos comentários das resenhas, na coleção resenhas. Por fim, conseguimos então criar nosso modelo. O que você achou desse exemplo? Algo que faria diferente? Espero que tenha esclarecido como funciona os princípios de modelagem do MongoDB.

Um DBA, seja ele responsável por um banco de dados relacional ou não, deve ser capaz de identificar possíveis erros, melhorias e soluções por meio de métricas e mensagens no banco de dados em que está trabalhando. Essa análise pode ser conduzida de várias maneiras. Por exemplo, no caso do MongoDB, é possível baixar logs de eventos que abrangem desde conexões de entrada até os comandos executados e os problemas encontrados. Essas mensagens possibilitam o diagnóstico de problemas, o monitoramento da implementação do banco de dados e a otimização do desempenho. Neste artigo, vou trazer ferramentas que auxiliam nesse processo de análise de logs. Seja esta ferramenta própria do MongoDB, ou não. Log Messages A partir do MongoDB 4.4, todas as mensagens de log são geradas no formato JSON. Elas são registradas como uma série de pares de valores-chave, em que cada chave representa um tipo de campo de mensagens de log, como "gravidade", e cada valor correspondente registra as informações de log associadas a esse tipo de campo, por exemplo, "informativo". A seguir está um exemplo de mensagens de log no formato JSON, conforme apareceria no arquivo de log do MongoDB: {"t":{"$date":"2020-05-01T15:16:17.180+00:00"},"s":"I", "c":"NETWORK", "id":12345, "ctx":"listener", "msg":"Listening on","attr":{"address":"127.0.0.1"}} As entradas de log JSON podem ser escritas de maneiras mais legíveis. Aqui está a mesma entrada de log bem impressa: Abaixo, o que significa cada chave: {   "t": <Datetime>, Data e Hora // timestamp   "s": <String>, Severidade // severity   "c": <String>, Componente // component   "id": <Integer>, Identificador Único // unique identifier   "ctx": <String>, Contexto // context   "msg": <String>, Corpo da mensagem // message body   "attr": <Object> Atributos adicionais// additional attributes (optional)   "tags": <Array of strings> Matriz de strings// tags (optional)   "truncated": <Object> Objeto // truncation info (if truncated)   "size": <Object> Objeto // original size of entry (if truncated) } Com esses arquivos de logs, é possível analisar seus pontos de melhoria, criar soluções e fazer sugestões ao cliente por meio de ferramentas de análise. Uma das ferramentas disponíveis para esse fim é a Mtools. Mtools – o kit detetive oficial Trata-se de um conjunto de linhas de comando de acesso público, embora não seja oficialmente suportado pela MongoDB Inc. Este conjunto compreende ferramentas e scripts desenvolvidos e mantidos pelos engenheiros da MongoDB para auxiliar os DBAs na análise e depuração de problemas que possam surgir em implantações do MongoDB. Um dos aspectos mais importantes e que deve ser considerado ao utilizar o Mtools para suas análises é a versão do mongodb que você está usando, isso porque, a partir da versão 4.4 o mongoDB não oferece mais suporte, portanto, você conseguirá utilizar arquivos de logs de versões que sejam até 4.4. O pacote está disponível por meio de ferramentas comuns de gerenciamento de pacotes Python, como pip e Easy install. Do que é formado o MTOOLS? Em sua versão atual 1.7.2 consiste em 5 scripts individuais: mloginfo, mlogfilter, mplotqueries, mlogvis e Mlaunch.   ·       Mloginfo: É o que utilizamos para a primeira parada na análise do arquivo de log. Esse script analisa o arquivo e gera informações gerais sobre o conteúdo. Algo legal dentro do mloginfo é o acréscimo de seções de informações adicionais: “consultas”, “conexões”, “reinicialização” e “distintas”.     • Mlogfilter: Ajuda a estringir a pesquisa em arquivos de log, permitindo filtras atributos de mensagens de log, como nomes, tipos de operação, ou conexão. Assim, pode também procurar operações lentas definindo um limite, identificando varreduras de coleção. A principal propriedade do mlogfilter é que o formato de saída sempre permanece o mesmo (linhas de log), então você pode canalizar a saída para outra instância do mlogfilter, para o comando grep ou para outros scripts como mplotqueries. • Mplotqueries: É uma ferramenta de visualização para arquivos de logs que passaram por filtro, ou não. Há uma série de opções para tipos de gráficos, como por exemplo, gráfico de dispersão (que mostram todas as operações ao longo do tempo versus sua duração), histogramas, gráficos de eventos e intervalos e outros gráficos mais especializados, como rotatividade de conexões ou alterações no conjunto de réplicas. • Mlogvis: Cria um arquivo HTML independente que mostra uma visualização interativa em um navegador da Web como uma alternativa para mplotqueries. • Mlaunch: Um script para acelerar implantações de teste em seu host local, incluindo réplica set e sharded cluster. • Mgenerate: Cria conjuntos de dados com dados aleatórios baseados em um modelo para testar e reproduzir problemas.  Perfeito, agora que você está familiarizado com os scripts do Mtools, vou explicar como utilizar essas ferramentas. É importante destacar novamente que a versão do MongoDB que você está utilizando para coletar seus logs deve ser até a versão 4.4. Para começar, uma vez que os scripts são escritos em Python, é necessário ter o Python instalado em sua máquina. No diretório onde o Python está instalado, você pode executar o seguinte comando: `py -3.11 -m pip install mtools`. A partir desse momento, você já pode manipular os logs com o mtools. No exemplo abaixo, é inserindo a “seção” –queries   Este exemplo foi retirado de um artigo publicado pela MongoDB: "Cada linha (da esquerda para a direita) exibe o namespace, o padrão de consulta e várias estatísticas dessa combinação específica de namespace/padrão. As linhas são ordenadas pela coluna 'soma', em ordem decrescente. Classificar por 'soma' é uma maneira eficaz de identificar onde o banco de dados passou a maior parte do tempo em geral." Hoje, o MongoDB está lançando a tão esperada versão 7.0. No entanto, a restrição de versão para o uso do Mtools tem afetado significativamente a produtividade dos DBAs ao realizar análises e revisões de seus bancos de dados. Portanto, enquanto podemos aprofundar esse tópico e fornecer exemplos, também podemos questionar se existe outra ferramenta capaz de fornecer essas informações sem tantas limitações. Em contrapartida ao Mtools, o MongoDB tem investido consideravelmente em sua plataforma em nuvem, o MongoDB Atlas. Através do Atlas, temos acesso a outras ferramentas para análise de logs. A partir do plano cluster M10, já é possível fazer o download dos arquivos de log. Nesse contexto, é importante entender as integrações disponíveis no Atlas. O MongoDB Atlas permite a integração com serviços de monitoramento de terceiros para receber alertas do Atlas e visualizar e analisar métricas de desempenho coletadas sobre seu cluster. Por meio do Atlas CLI, uma interface de linha de comando desenvolvida especificamente para o MongoDB Atlas, podemos fazer uso do Prometheus e Grafana para monitorar nossas implementações com eficácia. Prometheus coleta métricas a partir de destinos configurados em intervalos determinados e pode acionar alertas quando observar condições específicas, com o Grafana podemos visualizar e ter uma análise interativa desses alertas. Para visualizar configurações de integração de terceiros você ser Organization Owner ou Project Owner . Agora, vamos abordar outra excelente ferramenta para as análises de Log, chamada Keyhole. Keyhole Uma ferramenta para explorar implantações do MongoDB, e você poderá analisar com logs JSON junto ao Maobi. Portanto, você faz o download dos logs do seu banco, e poderá analisar com o Keyhole. Com Keyhole e Maobi instalados, você poderá: Atente-se agora no recado que fica abaixo da tabela criada pelo Keyhole: top 10 of 421 lines displayed; see HTML report for details. bson log info written to ./out/mongod.2-log.bson.gz TSV log info written to ./out/mongod.2.tsv   Agora, abrimos o Docker, e acessamos o localhost:3030,(http://localhost:3030) e com isso temos três tabelas importantes: • Summary:(http://localhost:3030/#1) Traz o formato do arquivo, ao período que ele se refere, número de operações lentas, e de collscan, dentre mais algumas informações. • Slow Ops Patterns: Aqui, traz em um gráfico as operações mais utilizadas, e o determinado horário em que elas rodam. • Top 25 Slowest Ops: E por fim, as operações mais lentas, e com isso conseguimos fazer uma análise aprofundada sobre as necessidades que permeiam o nosso banco. Independente da ferramenta que você utilize, ou dos recursos que encontre para otimizar seu tempo, esse artigo abrange diversos meios para contribuir com sua análise mais aprofundada do banco, podendo utilizar seja no ambiente de trabalho, quanto para um exercício de projeto pessoal. Nas referências, coloquei diversos links que podem agregar ao assunto, e que confesso, foi um pouco desafiador coletar. Espero que esse artigo tenha sido de grande utilidade para você, DBA. REFERÊNCIAS Documentação Mtools: https://rueckstiess.github.io/mtools/index.html(https://rueckstiess.github.io/mtools/index.html) Artigo técnico: https://www.mongodb.com/blog/post/introducing-mtools(https://www.mongodb.com/blog/post/introducing-mtools) Instalação do Pip: https://pip.pypa.io/en/stable/installation/(https://pip.pypa.io/en/stable/installation/) Repositório GitHub: https://github.com/rueckstiess/mtools(https://github.com/rueckstiess/mtools) Repositório como instalar: https://github.com/rueckstiess/mtools/blob/master/INSTALL.md(https://github.com/rueckstiess/mtools/blob/master/INSTALL.md) Mtools WIKI: https://github.com/rueckstiess/mtools/wiki(https://github.com/rueckstiess/mtools/wiki)

No curso mais recente sobre o Atlas, me questionei sobre suas principais vantagens para as organizações. Vamos entender esses benefícios e como eles se aplicam ao seu negócio? O Atlas fornece uma maneira fácil de hospedar e gerenciar seus dados na nuvem, é uma ferramenta fácil de usar, com escalabilidade automática, segurança avançada, disponibilidade, e oferece os recursos de backup e recuperação, tornando-o uma forma mais simples de organizar e gerenciar o banco. Portanto, uma excelente opção quando sua organização precisa desses componentes oferecidos pelo Atlas. Além do mais, o Atlas é uma ferramenta multicloud, que de acordo com o MongoDB trata-se de uma estratégia de TI em que as organizações usam uma combinação de nuvens públicas, privadas e híbridas de diferentes provedores de nuvem, como AWS (Amazon Web Services), Azure e Google Cloud. Antes de passar para as partes de configurações e especificidades do Atlas, vamos começar com a criação do usuário em um cluster gratuito, e como deve ser feito: Lembrando que o Atlas vem pré-configurado com configurações padrão seguras. Você pode ajustar os recursos de segurança para suas implantações de banco de dados para atender às suas necessidades e preferências de segurança exclusivas. Quando criamos nossa conta no Atlas, criamos também nosso Atlas user. Isso é, responsável por gerenciamento da organização do Atlas, projetos, usuários de banco de dados, faturamento. Com o Atlas user é possível criar então o Database user, para fins de segurança, o Atlas exige que os clientes se autentiquem como usuários do banco de dados MongoDB para acessar os clusters. Atlas Users: Definem as ações que os usuários do Atlas podem executar em organizações, projetos ou ambos. A organização e o projeto Owners podem gerenciar os usuários do Atlas e suas funções em suas respectivas organizações e projetos. Você pode aplicar essas permissões somente no nível da organização ou no nível do projeto. Database User: Fornece aos clientes a implementação de banco de dados em um projeto. É criado pela organização ou Project owners. No conjunto de suas permissões estão: •          atlasAdmin; •          readWriteAnyDatabase, •          readAnyDatabase. Mas então, qual seria a diferença entre o atlas user e o database user? Assim como em instalações locais do MongoDB quanto em ambientes em nuvem, como o MongoDB Atlas, existem três práticas para garantir a segurança dos dados das aplicações: Sobre as regras de acesso baseadas em funções para controlar quais usuários podem realizar operações, chamada de role-based access control (RBAC). No RBAC, as permissões são associadas a funções específicas em vez de serem atribuídas diretamente aos usuários individuais. Isso simplifica a administração de permissões, pois em vez de gerenciar permissões para cada usuário, elas são atribuídas às funções e, em seguida, os usuários são atribuídos às funções apropriadas. Outra forma de segurança das informações é através da criptografia, o qual é um processo de codificação de dados para garantir que só tenha acesso usuários permitidos. Nesse quesito, existem três tipos de criptografia: Conhecendo assim, todas as etapas de início, permissão e segurança no mongo Atlas, podemos passar para um assunto bastante importante, o de backup, restauração e arquivamento de dados. Backups são cópias de dados que armazenam o estado de seu cluster em um determinado momento. Fornecendo uma medida de segurança em caso de perda de dados. Aqui, vale ressaltar que os backups do Atlas não estão disponíveis para clusters gratuitos. Para isso, você pode usar o mongodump para fazer o backup dos dados, e mongorestore para a restauração. Na tabela abaixo, temos as descrições dos tipos de clusters: Backups na Nuvem: O atlas usa os recursos nativos de snapshot do seu provedor de nuvem para oferecer suporte a snapshots de cópia completa e armazenamento de snapshot localizado. Por fim, o MongoDB Atlas oferece opções para diferentes tipos de clusters, desde o gratuito até os dedicados, com recursos que atendem às necessidades variadas de aplicativos. Seja para fins de desenvolvimento, testes ou produção, o MongoDB Atlas é uma escolha confiável para organizar, gerenciar e proteger dados de forma eficiente. Em resumo, o MongoDB Atlas é uma solução abrangente e flexível para o gerenciamento de dados na nuvem, oferecendo escalabilidade, segurança e praticidade para atender às demandas das organizações modernas. Ao utilizar o MongoDB Atlas, você pode se concentrar no desenvolvimento de suas aplicações, sabendo que seus dados estão em um ambiente seguro. COMO INICIAR SEU CLUSTER DE ESTUDOS NO MONGO ATLAS Abaixo, um passo a passo para como iniciar com seu cluster de estudos, quando você cria sua conta, poderá selecionar o tipo do cluster. No nosso caso, vamos optar pelo M0 que é FREE. Assim, agora possuímos o cluster M0, e criamos o usuário e a senha. Basta clicar em seguir após usuário criado.    Aqui, possuímos nosso cluster, sem nenhum banco de dados. Podemos fazer então a criação do mesmo através do Build a Database. E aguardar, assim, a criação do banco de dados de arquivos de estudos. E agora, vamos conectar nosso banco de dados no MongoCompass, clique em CONNECT: Clicando no connect, você escolherá onde deseja acessar, e deve copiar a conecction string: E agora, vamos ao Mongo Compass, e colocar lá a nossa connection string, inserindo o usuário e a senha: E aqui está o nosso banco de dados, completo, para podermos treinar sem medo com um banco exclusivo para estudos! Eai? Gostou do artigo? Espero que tenha te ajudado a entender os benefícios de usar o Mongo Atlas no seu negócio.

No último artigo que publiquei, apresentei um banco de dados de “Pokemons” com duas coleções: Pokemons e Combats. Inclusive, recomendo a leitura do artigo de agregação antes da leitura deste em específico. Na coleção Pokemons, possuímos em torno de 800 documentos com os atributos de cada um dos pokémons, enquanto na coleção Combats é apresentado da seguinte maneira: Antes da resolução desse problema, precisamos nos aprofundar no assunto, principalmente quando essa coleção foi criada. Concordamos aqui que existem outras formas de modelagem, certo? Existem diversas maneiras de arquitetar os dados desse database, e a forma como a coleção foi criada não foi pensada para operações que resolvam essa nossa problemática, fazendo com que tenhamos que utilizar o operador de agregação $lookup. Vamos, então, entender o que faz esse operador, de acordo com a documentação do MongoDB. Executa um left Join para uma coleção no mesmo banco de dados para filtrar documentos da coleção "unida" para processamento. O estágio $lookup adiciona um novo campo de matriz a cada documento de entrada, esse novo campo de matriz contém os documentos correspondentes da coleção "unida". O estágio $lookup passa esses documentos reformulados para o próximo estágio. O $lookup tem a seguinte sintaxe: O alerta fica, se você usa muito esse operador, é bastante provável que a modelagem desse banco poderia ter sido mais bem trabalhada. Fique atento às boas normas para quando você for construir a modelagem do seu banco: 1.     Nesse caso dos combates, não seria mais fácil colocar o nome dos pokémons do que seus respectivos _id, ou por acaso teria uma maneira mais adequada de resolver essa questão? No MongoDB, é possível inserir manualmente um valor específico ao id de um documento. No entanto, o MongoDB não impõe restrições nesse campo, o que significa que você pode inserir documentos com o mesmo id sem o MongoDB identificar um erro. E como podemos perceber, esse foi o método usado para construir a coleção combates, o _id foi inserido manualmente enquanto os documentos foram gerados. E agora, chegamos a uma importante prática no MongoDB, que é o uso do ObjectId, no qual uma das vantagens é a garantia de unicidade. Além disso, o ObjectId possui uma propriedade de ordenação cronológica, o que pode ser útil em determinados cenários de ordenação por tempo. Então vamos lá, qual a diferença em deixar o combats com _id feito manualmente, e com ObjectId gerado pelo MongoDB? O uso do ObjectId pode ser usado como referência de documentos, enquanto o id pode trazer problemas de duplicidade. Outro ponto importante seria Indexação, o ObjectId é otimizado para indexação no MongoDB, e isso significa que consultas que envolvem o campo id terão melhor desempenho. Além do mais, o MongoDB trabalha muito bem com sub documentos, portanto, outra maneira ainda mais fácil (e correta) dentro das estruturas de boas práticas, é incorporar as informações relevantes do pokémon diretamente no documento de combate. Isso evita a necessidade de fazer a junção com outra coleção usando o $lookup. Perceba o exemplo abaixo: Assim, incorporamos os atributos de cada um dos pokémons dentro dos combates. RESOLUÇÃO DO PROBLEMA COM $LOOKUP Voltando ao nosso problema, em como construir nosso pipeline para que o resultado seja, o nome dos pokémons que estão em combate, e o nome do vencedor. Sabendo que queremos substituir o id pelo nome dos pokémons, vamos prosseguir com o $lookup, para o Firstpokemon e Second_pokemon: Tanto o primeiro quanto o segundo $lookup são usados para combinar os documentos da coleção “combats” com os documentos correspondentes da coleção “pokemons” com base no First_pokemon, e Second_pokemon. A continuação dessa agregação é a seguinte: O primeiro $project é usado para remodelar como será a saída dos documentos. A expressão “$arrayElemAt” é usada para obter o primeiro elemento do array “pokemon1_arr” e “pokemon2_arr”, e armazenar em seu respectivo campo. E o segundo $project ele vai procurar o “$pokemon1.name” e o “$second1.name”. O winner é criado com base em uma condição. O valor do "winner" será definido como o campo "name" do "pokemon1". Caso contrário, o valor do campo "winner" será definido como o campo "name" do "pokemon2". Trazendo o seguinte resultado: E então, consegui te ajudar a entender sobre o $lookup? Muito bacana conhecer esse operador, afinal mesmo que não seja altamente recomendado, é bastante útil quando necessário usar. REFERÊNCIAS Udemy. Curso completo MongoDB 2022, Renan Palin. Disponível em < https://www.udemy.com/course/mongodb-curso-completo/> Dataset Pokemon. Disponível em <https://www.kaggle.com/datasets/terminus7/pokemon-challenge> Ressalto aqui, como no artigo anterior, a importância do curso do Renan Palin sobre o assunto de agregação.

Agregação no MongoDB é uma ferramenta que permite a manipulação e análise de dados de forma flexível e eficiente. Isso, porque o aumento exponencial de dados armazenados em banco de dados NoSQL, exige uma ferramenta capaz de realizar consultas complexas, transformando e processando dados de maneira eficiente. De acordo com a própria documentação do MongoDB você pode usar operações de agregação para: i) Agrupar valores de vários documentos; ii) Executar operações nos dados agrupados para retornar um único resultado e iii) Analisar as mudanças dos dados ao longo do tempo. Vamos exemplificar a Agregação com um banco de dados de Pokémon? Os dados desse arquivo vou deixar ao final do artigo com o Link no repositório do GitHub para caso você queira treinar. Vale ressaltar que o exercício foi feito com base no curso do Renan Pallin, (disponível na Udemy). Vamos para o exemplo: Possuímos um banco de dados com duas coleções, uma coleção de pokémons: com mais de 800 deles, e cada um tem as suas skills (e outras de combates, que estarão em um próximo artigo): Na imagem, podemos observar o nome do pokémon, o seu ID, seu tipo e suas habilidades. Nesse primeiro momento, antes de entrar de fato em uma resolução de problema, vou lhe apresentar algumas informações importantes sobre agregação.   Explicando o conceito de Pipelines O pipeline de agregação no MongoDB é uma sequência de etapas que você pode usar para processar dados e realizar operações. Cada etapa do pipeline é representada por um operador de agregação, tudo o que precisamos fazer é montar a composição do nosso pipeline. Lembre-se, pipelines devem sempre estar em uma lista de estágios, e estágios são compostos por um ou mais operador de agregação ou expressões. Abaixo, um exemplo da própria documentação do MongoDB O exemplo de pipeline contém dois estágios e retorna à quantidade total do pedido de pizzas de tamanho médio, agrupados por nome de pizza. Esse retorno acontece devido as operações e expressões utilizadas, $match e $group. Principais estágios de um pipeline de dados $match:  ·       Livre para usar quantas vezes forem necessárias no seu pipeline; ·       É o primeiro estágio do seu pipeline, ·       $match usa a mesma consulta que find(). $project: ·       Passa os documentos com os campos solicitados para a próxima etapa do pipeline. As especificações do Project têm as seguintes formas: o   <campo>  : 1 ou true : Especifica a inclusão do campo. o   id: 0 ou false: Especifica a supressão do campo id. o   <campo>: <expression.>: Adiciona um novo campo, ou redefine o valor de um campo existente. o   <campo>: 0 ou false: Especifica a exclusão de um campo. Por exemplo, vamos supor que possuímos uma coleção de alunos que estão separados por setor de interesse. Estamos fazendo um filtro, no primeiro estágio, usando o $match de todos que estão alocados na turma de Engenharia de Dados, e a segunda parte desse pipeline é um $project onde vamos exibir somente o nome e se a matrícula está ativa. A agregação é uma ferramenta muito útil para realizar operações complexas. Outro operador que já apareceu aqui mas ainda não o expliquei é o $group. $group: ·       Essa etapa separa os documentos em grupos de acordo com uma “chave” Como no exemplo da pizzaria, em que foi feito um agrupamento de nome de pizza, e quantidades de pedidos. $sort: ·       Classifica todos os documentos de entrada e os retorna ao pipeline na ordem da classificação. ·       $sort pega um documento que especifica os campos para classificar e a respectiva ordem da classificação, sendo 1 ascendente, e -1 descrescente. $limit: ·       Limita o número de documentos passados para o próximo estágio no pipeline. $skip: ·       Ignora o número especificado de documentos que passam para o estágio e passa os documentos restantes para o próximo estágio no pipeline. $lookup: ·       O $lookup permite combinar documentos de duas coleções diferentes com base em um campo em comum, criando um resultado enriquecido com dados de ambas as coleções. ·       O $lookup tem a seguinte sintaxe: Operadores de um pipeline de dados: Abaixo serão apresentados alguns, de muitos, e para ter acesso a todos entre na documentação. Os operadores de agregação são usados dentro dos estágios de agregação para moldar o pipeline de agregação. $max: ·       O operador $max é usado para determinar o valor mais alto de um campo em uma coleção durante uma operação de agregação. Ele retorna o documento que possui o valor máximo para o campo especificado. $min: ·       Ao contrário do $max, este retorna o valor mínimo. $sum: ·       Calcula e retorna a soma coletiva de valores numéricos. Resolvendo o problema: Bom, nós temos a coleção “pokemmons” e os documentos são apresentados da seguinte maneira: Agora, nosso objetivo é apresentar o seguinte resultado: a contagem total de pokémons por geração (disponíveis nas gerações 1ª a 6ª) e a média de habilidades desses pokémons. Para isso, vamos iniciar com uma categorização, na qual reuniremos informações sobre: Geração, Contagem total de pokémons na geração e Média de habilidades entre as gerações. O campo _id é definido como $generation, o que significa que os documentos serão agrupados com base no valor do campo "Generation". O operador $sum é utilizado para calcular a soma de 1 para cada documento agrupado. Quanto à média de ataque, é feita a soma das habilidades e, em seguida, calculada a média entre elas. E essa segunda parte é o $project, o mais interessante é a forma como vamos projetor o _id como geração, e mostraremos a SomaDaGeracao e MediaAtaque. E o retorno é o seguinte: Muito bacana, certo? Assim, conseguimos ver a média de ataque de cada geração, até poderia dizer que por essas métricas a geração 4 tem a maior média de força de ataque, mas é interessante considerar que também estamos falando que tem uma diferença entre as quantidades de pokémons por geração. Para um próximo artigo, vamos trabalhar e mostrar mais explicitamente como a modelagem de dados é importante e faria diferença nesse banco. E para agregar a esse tema, vamos falar de $lookup. Mas, como disse, fica para uma próxima. REFERÊNCIAS MongoDB. Aggregation Pipeline Stages. Disponível em < https://www.mongodb.com/docs/manual/reference/operator/aggregation-pipeline/> MongoDB. Aggregation Pipeline Operators. Disponível em < https://www.mongodb.com/docs/manual/reference/operator/aggregation/> Udemy. Curso completo MongoDB 2022, Renan Palin. Disponível em < https://www.udemy.com/course/mongodb-curso-completo/> Dataset Pokemon. Disponível em <https://www.kaggle.com/datasets/terminus7/pokemon-challenge>

Uma das minhas recentes atividades foi treinar a configuração de um replicaset para fins de estudo, portanto, estou utilizando meu sistema operacional Windows, o que resulta em algum grau de dificuldade, tendo em vista que o SO do LINUX é mais comum para trabalhar com bancos que exigem alto desempenho e escalabilidade, principalmente MongoDB. Vamos começar por onde eu tive um pouco mais de dificuldade: Entendendo a importância da keyfile, e de controle de acesso ao nosso banco. Nós podemos fazer um implantação de replicaset com controle de acesso desativado, mas isso interfere diretamente na segurança, isso porque o uso de um keyfile é altamente recomendado em um replicaset no mongoDB, e abaixo, trago as razões pelo qual devemos utilizar uma keyfile. Segurança: O keyfile garante que apenas membros autorizados possam se conectar ao replicaset e acessar seus dados. Sem um keyfile, um invasor pode se conectar ao replicaset e manipulá-los. Autenticidade: Garante que os membros do replicaset sejam autenticados corretamente. Confiabilidade: O keyfile ajuda a garantir que o replicaset funcione de maneira confiável e consistente. Então, começaremos com a criação de uma keyfile. Bom, no meu caso, precisei fazer o download do openssl, e na sequência a criação da keyfile, seguindo o passo a passo do quadro 1. Após a criação do nosso keyfile, vamos para as configurações dos nossos nós. Nossa instância do standalone já está rodando com a porta padrão 27017, então, vamos para os próximos. Abaixo, as características dos nossos nós: 1) Criação dos nós e das pastas de ambos os nós, com database file, logfile, configuration file. Entre no prompt de comando (como super usuário). mkdir c:\data1\config c:\data1\db c:\data1\log mkdir c:\data2\config c:\data2\db c:\data2\log 2) Configuração do nosso arquivo do primeiro nó Na pasta do mongod, dentro da pasta bin, localizamos o arquivo TXT do mongo.conf, esse arquivo pode ser copiado e colado nas pastas do nó1 e nó2. Na figura 1, o exemplo do mongo.conf como standalone. Antes de prosseguir para o passo 2, é importante entender a relevância do arquivo mongo.conf na configuração e execução do MongoDB, especialmente em ambientes de produção. O mongo.conf é um arquivo de configuração de texto que contém diversas opções de configuração do servidor, como o diretório de dados, o nome do servidor e o número da porta. Essas opções podem ser personalizadas de acordo com as necessidades específicas do servidor. As alterações serão feitasda seguinte maneira, a edição dos arquivos de configuração de cada nó (lembrando de copiar o arquivo mongo.conf para todos os nós que foram criados acima). Figura 1 - Configuração mongo.conf Pontos a serem anotados: 1) A pasta do storage deve estar direcionada a um arquivo db0 (podemos usar o mesmo processo de criação da pasta1 e pasta2, e transferir o arquivo mongod.cfg para o config do db0). 2) A porta também é alterada a cada replica criado (como no exemplo da figura 2) 3) A pasta de log também foi criada com o comando do passo 1 anterior. E deve ser inserida no path do systemlog. 4) A inclusão de authorization: enabled no security e do keyfile (que é uma ferramenta de segurança). 5) Por fim, o nome do replicaset. Figura 2 - Configuração mongo.conf Perfeito, arquivos criados, devidamente configurados, na figura 2, mais um exemplo do nó2, para fixar as alterações que são recomendadas: Na sequência, vamos ao prompt de comando, como administrador, para iniciar nosso mongo. cd C:\Program Files\MongoDB\Server\6.0\bin mongod --dbpath C:\data0\ -port 27017 --replSet "testers0” mongod --dbpath C:\data1\ -port 27018 --replSet "testers0” mongod --dbpath C:\data2\ -port 27019 --replSet "testers0” Após acessar os seus nós através do prompt, vamos abrir o mongoshell e iniciar a nossa máquina: URI DE COMANDO: mongodb://localhost/ Com os comandos rodando, vamos ao mongoshell, conectamos com o nosso localhost, e damos o initiate. Na sequência, vamos conectar nossos nós, com o rs.add(): rs.add({_id:1, host: “localhost:27018”} rs.add({_id:2, host: “localhost:27019”} Para incluir novos nós, ou um árbitro é necessário seguir o mesmo passo a passo acima. Nesse caso, criei mais um nó, e um árbitro. A seguir, os próximos comandos feitos para mudanças no meu replicaset, serão feitos no próprio MongoShell. COMANDOS DO REPLICASET rs.isMaster(): Com este comando conseguimos ver quantos nós, e quantos árbitros possuímos: rs.remove(): Faz a exclusão de um nó. Fiz um rs.remove(“localhost:27021”), intencionalmente para apagar o árbitro, e transformar um nó em nó Hidden (usado como secundário que não é visível para a maioria das operações e é usado par fins de backup e recuperação) rs.isMaster() para mostrar como o árbitro não existe mais: Transformando um nó em Hidden: Transformando meu membro 3 em hidden rs.conf(): Podemos obter informações específicas dos nossos nós, como prioridade, e poder de voto. No caso dos Hidden, pode-se observar o poder de voto é 0, e que Hidden é TRUE. rs.status(): Retorna o status do conjunto de réplicas do ponto de vista do membro em que o método é executado. rs.reconfig(): Reconfigura um conjunto de réplicas existente, substituindo a configuração do conjunto de réplicas existente. Para executar o método, você deve se conectar ao primário do conjunto de réplicas. E então? Será que com esse passo a passo fica mais fácil para você estudar e praticar a implantação de um replica set na sua máquina? Recomendo que leia este artigo juntamente com o último publicado, Replicaset e Backup, pois ambos são necessários. Ao longo do texto, é explicado os tipos de nós e sua importância para proteger e garantir a disponibilidade do banco de dados. Todas as informações sobre os comandos podem ser consultadas na documentação do MongoDB. Todas as figuras e quadros foram feitas pela autora.

Olá, pessoal, tudo bem? Me chamo Joyci, e sou uma Acelera de DBA NoSQL, isso é, banco de dados não relacional. Visitando o blog da Dataside, encontramos um artigo muito bom falando sobre a importância do banco de dados, e como este é um serviço fundamental para o funcionamento das empresas. No artigo, é apresentado a estrutura de banco de dados relacional, em que os dados são armazenados em estruturas Pré definidas: nome, sobrenome, CPF, data de nascimento, etc. Agora, quando falamos de banco de dados não relacional, estamos apresentando uma forma diferente de armazenamento e performance dos dados. O banco de dados não relacional busca principalmente atender às deficiências de escalabilidade, performance, e disponibilidade promovendo uma alternativa de alto armazenamento com velocidade e grande disponibilidade (Uniasselvi, p. 12). A proposta do banco de dados NoSQL, não é extinguir o Modelo Relacional, mas utilizá-lo em casos em que é necessária uma maior flexibilidade na estruturação do banco de dados. Sintetizando, a principal diferença entre empresas que utilizam banco de dados relacionais ou não relacional está na natureza dos dados que precisam armazenar e gerenciar. Empresas que utilizam banco de dados relacionais tem uma abordagem mais estruturada e normalizada de seus dados, o qual atendem suas necessidades específicas como empresas que precisam gerenciar recursos empresariais (ERP) ou sistema de gerenciamento com clientes (CRM). Enquanto o banco de dados não relacional tem uma abordagem mais flexível e orientada a dados não estruturados, como imagens, dados de mídias sociais, logs de aplicativos, podendo lidar com uma variável gigante de informações, sem a necessidade de uma estrutura fixa. Um exemplo de empresa que utiliza banco de dados não relacional: Netflix, podendo armazenar e acessar rapidamente informações sobre o histórico de visualizações do usuário, preferências de gêneros, informações da conta, mesmo que em dispositivos diferentes. Hoje, meu contato está sendo diretamente com o MongoDB, um banco de dados orientado a documentos, onde os dados são armazenados em formato BSON (Binary JSON), uma representação binária do JSON, e sabendo que o modelo de banco de dados não relacional precisa lidar com grande volume de dados, o formato BSON é mais eficiente em diversos fatores, principalmente em espaço e desempenho. Quanto aos estudos sobre a estrutura do MongoDB ser orientado a documentos fiz algumas anotações importantes de serem mencionadas aqui: ⦁ O modelo de documentos torna mais fácil e mais rápido planejar como os dados do seu aplicativo corresponderão a dados armazenados no seu banco. ⦁ Modelo de documentos podem ser utilizados para modelar qualquer forma ou estrutura; ⦁ Altamente escalável, podendo lidar com grandes volumes de dados em tempo real; ⦁ Garante na performance, usando uma arquitetura de dados distribuída que permite que os dados sejam armazenados em vários servidores, resultando em consultas rápidas e eficientes, ⦁ Facilidade de desenvolvimento: Utiliza-se do conhecimento prévio dos desenvolvedores que trabalham com orientação a objetos, para um banco de dados que trabalha orientado a documentos. Mas, vamos para uma ilustração simplificada de como é a orientação a documentos? Nos artigos publicados pela AWS encontramos o seguinte, “A natureza flexível, semiestruturada e hierárquica dos documentos e dos bancos de dados de documentos permite que eles evoluam conforme as necessidades dos aplicativos. O modelo de documentos funciona bem com casos de uso como catálogos, perfis de usuários e sistemas de gerenciamento de conteúdo, onde cada documento é único e evolui com o passar do tempo. Os bancos de dados de documentos possibilitam uma indexação flexível, consultas ad hoc eficientes e análises de dados em grupos de documentos.” Vamos aprofundar no exemplo seguinte, suponha que você trabalhe em uma biblioteca e queira guardar informações sobre os livros, usuários e empréstimos: Primeiro, é necessário criar uma coleção de livros: Armazena então, as informações sobre os livros da biblioteca. Cada livro é um documento na coleção e contém campos como o título, autor, ano de publicação, editora, gênero, nº de cópias disponíveis, etc. Agora, partimos para uma coleção de usuários das bibliotecas: nome, telefone, e-mail, endereço. Onde cada usuário é um documento desta coleção. E, por fim, uma coleção de empréstimos: Essa coleção vai armazenar informações sobre os livros e sobre os usuários. Cada empréstimo é um documento na coleção e contém campos como o ID do usuário, o ID do livro emprestado. Então, retomando a nossa comparação com o banco de dado relacional: Em SQL o armazenamento é em tabela, que é composta por linhas e colunas. Cada linha representa um registro individual e cada coluna representa um atributo desse registro, e os relacionamentos entre as tabelas são realizados por meio da chave estrangeira. No caso de NoSQL orientado a documentos, a unidade de armazenamento é o documento, que pode conter múltiplos atributos e valores, que são armazenados em formatos de chave-valor. Isso é, em documento BSON, chave é uma string que identifica de forma única um valor podendo este, ser de diferentes tipos: string, número, booleano, objeto, array, e outros tipos de dados. Voltando ao exemplo acima, por exemplo na coleção de livros: As chaves “title” e “year” recebem tipos de valores diferentes. Mas ainda durante os estudos, uma dúvida surgiu, a chave primária que é importantíssima no banco de dados relacional, não existe no banco de dados não relacional? Bom, no MongoDB, cada documento é armazenado em uma coleção, e não em uma tabela como banco de dados relacional. Portanto, em vez de utilizar uma chave primária para identificar cada registro de uma tabela, o MongoDB usa o conceito de “_id”, que é um identificador único para cada documento em uma coleção. O “_id” é indexado automaticamente em um “ObjectId”, e por boas normas, a sugestão principal é não alterá-la, pois este é utilizado como identificador exclusivo para cada documento em uma coleção e é utilizado internamente pelo MongoDB para referenciar documentos em outras coleções, se o “_id” mudar pode quebrar referências e causar problema de integridade. Claro que essa é só a ponta do que é banco de dados não relacional e MongoDB. Espero ter esclarecido algumas dúvidas referente a diferença entre SQL e NoSQL, e como estes se aplicam a diferentes objetivos empresariais.Além de ter sanado dúvidas sobre como o banco de dados NoSQL se garante em performance, e ter deixado o leitor um pouco mais curioso sobre as mais diversas atuação de um banco de dados não relacional. FONTES: AWS. O que é banco de dados de documento? Disponível em <https://aws.amazon.com/pt/nosql/document/>. DATASIDE. Por que o serviço de banco de dados é essencial? Disponível em <https://www.dataside.com.br/post/por-que-o-servi%C3%A7o-de-banco-de-dados-%C3%A9-essencial>. UNIASSELVI. Banco de Dados Relacional. Edição 1.