Yellow - Módulo

Receita Federal · Auditor Fiscal

Modelos NoSQL conforme o edital, trabalhados sobre o modelo orientado a documentos: arquitetura, terminologia, tipos de dados, replicação, particionamento e consistência.

Fluência em dados

Modelos NoSQL

Tecnologia da Informação EmÁudio: Introdução ao MongoDBFala galera! Beleza? Bem-vindo a mais um módulo do nosso curso de Tecnologia da Informação EmÁudio. Neste módulo, turma, conversaremos e aprenderemos sobre o MongoDB. Já ouviu falar dele? Não? Então aperta o play e se surpreenda! MongoDB é um sistema de gerenciamento de banco de dados (SGB) classificado como NoSQL. Armazena dados no formato de documentos. Assim como outros bancos de dados, no MongoDB, é possível armazenar registros de dados sem uma estrutura fixa. A estrutura pode variar de registro a registro e evoluir facilmente ao longo do tempo. No MongoDB, os dados são armazenados na forma de documentos, similares ao formato JSON (JavaScript Object Notation), que é um formato que permite a representação de dados semi-estruturados. Os documentos são autodescritivos, contendo não somente os dados em si, mas também informações sobre a sua estrutura. Tranquilo até aqui, né? Vamos começar a colocar a mão na massa. Então foca em mim, vem aqui oh jovem. O MongoDB oferece duas versões do sistema: MongoDB Community Edition e MongoDB Enterprise. A versão Community Edition é gratuita e de código aberto. A Enterprise é uma versão mais completa, voltada para usuários corporativos, mas que é paga. Os usuários precisam realizar uma assinatura para usá-la. Além disso, o MongoDB oferece serviços de nuvem, como o MongoDB Atlas, que não requer que o usuário instale o servidor em seu computador. Beleza até aqui! Ótimo! Tudo certo? Jovem, eu fiz uma breve introdução para você sentir como está nosso módulo. Ok, este áudio foi rapidinho, mas já já tem mais. Te encontro no próximo play. Faz assim, valeu.

01 - Introdução MongoDB

Tecnologia da Informação EmÁudio - Arquitetura e TerminologiaFala pessoal, estamos de volta aí, claro, chegou a hora de falarmos sobre arquitetura e terminologia. Som na caixa, então. Cada registro de dados no Mongo DB é um documento. Em cada documento, cada dado é apresentado numa estrutura do tipo campo: valor.  O campo é o nome do atributo que está sendo representado e o valor é o valor para esse atributo. Os valores podem ser dados comuns,  de tipos escalares, como números ou cadeias de caracteres, mas também podem ser dados compostos, como always, outros documentos ou até always de documentos.Vamos conferir mais sobre isso? Mais à frente, tá bom? Por exemplo, imagine um documento que traga dados sobre uma pessoa que se cadastrou em um aplicativo de cursos à distância, como nosso querido EmÁudio e deseja adquirir algum material. Todo documento no Mongo DB, assim como no formato Jason será representado por um conjunto de campos e seus valores delimitados pelos símbolos de chaves. A primeira chave a que abre marca o início do objeto e a última chave a que fecha marca o fim do objeto.Presta atenção que para cada campo e um documento do Mongo DB é dado pelo nome do campo separado de seu valor pelo símbolo de dois pontos. No nosso exemplo, vamos registrar o documento em questão com a pessoa de nome Juliana, que tem vinte seis anos de idade e tem interesse na aquisição dos cursos de TCU e da PF - Campo curso_interesse,  nome Juliana, vinte seis anos de idade, na aquisição dos cursos TCU e da PF, campo cursos_ interesse.Os documentos no Mongo DB são organizados em coleções - collections, que ficam dentro de bancos de dados - data bases. As coleções servem para agrupar documentos que tenham algum propósito ou significado similar. Um detalhe é que as coleções no Mongo DB, ao contrário das tabelas em um SGB, não têm esquema definido. SGBD relacional, não tem esquemas definidos, o SGBD não irá impor restrições quanto ao esquema dos documentos como aquelas relativas a tipos de dados e valores nulos.Mas jovem, isso tem algumas consequências importantes que diferenciam o Mongo DB dos SGBD relacionais. Preste atenção. Documentos diferentes em uma mesma coleção podem ter conjuntos de campos diferentes entre si, ou seja, turma, um campo pode aparecer em um documento e não aparecer em outro. Não há restrição de tipo, então dois campos com o mesmo nome em documentos diferentes podem ter tipos diferentes. A característica de poliformismo é muito forte no Mongo DB, tá bom pessoal? E outra, não há restrição de vazio. Ou seja, você não tem como dizer que um campo é not no. Qualquer campo poderá receber valores nulos. Beleza, deu pra pegar, aí? Grave isso, tá bom? Te espero no próximo EmÁudio para darmos continuidade então aos nossos estudos, até daqui a pouquinho. Valeu.

02 - Arquitetura e Terminologia

Tecnologia da Informação EmÁudio: Campo, ID, Bson, Tipos de DadosOlá, meu jovem amigo! Olá, minha jovem amiga! Beleza, concurseiros! Voltei, tá? Oh, bora aprender mais um pouquinho. Som na caixa e cola em mim, hein.Bom, meu querido, minha querida, no Mongo DB todo documento tem um campo chamado underline id (_id) que serve como chave primária. Esse campo deverá ter valores únicos dentro da coleção, assim como as chaves primárias em um SGBD relacional. Se o usuário não especificar o _id na hora de inserir um documento, o Mongo DB irá criar o campo e atribuir um valor a ele automaticamente. O _id é imutável. Então, você não poderá alterar esse valor após a inserção do documento. Se liga, ele poderá assumir qualquer tipo, com a exceção de array.Quando é o próprio Mongo DB que gera o valor do campo de forma automática, o SGBD cria um valor do tipo ObjectId. O Mongo DB mantém a ordem dos campos em cada documento, da forma como eles foram criados, a não ser que o usuário posteriormente altere essa ordem através de um comando de atualização de dados.Uma exceção a esse princípio é o campo _id, que sempre será armazenado como o primeiro campo de cada documento. Mesmo que o usuário defina em outra posição. O Usuário pode adotar várias estratégias para armazenar os valores do _id. Ele pode utilizar alguma chave natural, como o CPF para pessoas, utilizar números com o comportamento de alto incremento, gerar valores únicos através do programa de aplicação, ou mesmo usar o tipo ObjectId do Mongo DB, que costuma ser uma solução mais simples.Além disso, turma, os documentos do Mongo DB são armazenados em um formato chamado, vou soletrar: B de bola, S de sapo, O de ovo, N de navio. Bson - Binary Jason , Bison é um formato baseado no JSON, só que armazenado em uma representação em código binário, que adiciona alguns recursos ao JSON puro. Os documentos JSON convencionais são representados em formato de texto com codificação UTF-8, por isso seus dados são compreensíveis tanto para humanos quanto para máquinas. Já no caso do BSON, a codificação binária torna os documentos nesse formato compreensíveis somente para a máquina. Assim, toda vez que você estiver vendo uma representação de um documento em um cliente do Mongo DB, ela será meio que uma tradução do formato binário para que você possa ler e compreender os dados que estão ali armazenados. Deu para entender? Ótimo. Bom, as aplicações clientes do Mongo DB irão exibir os dados no formato tradicional de documento, ou seja, abre chaves campo dois pontos Valor, vírgula campo dois pontos Valor, reticências fecha as chaves, mas por debaixo dos panos, os dados estão armazenados no formato binário. A ideia por trás da utilização desse formato Bison é permitir que o Mongo DB ofereça mais alguns recursos que não seriam possíveis se ele armazenar documentos no formato JSON puro. O Bison armazena informações de tipo e tamanho de dados, permitindo que o Mongo DB utilize tipos de dados mais avançados. Esses tipos incluem datas e objetos binários, além de permitir a diferenciação entre tipos numéricos. O JSON puro não diferencia números inteiros e decimais, por exemplo, percebeu? Enquanto o formato JSON só oferece suporte aos seguintes tipos. Vamos conferir:Stream, Booleano, Número e Array representam os seguintes tipos na especificação mais recente, ok? Double, Stream, Objectid, Array, Binary Date, Dados binários, Object, Booleano, Date new, Regular Expression, Expressão regular, JavaScript, inteiro de trinta e dois beats, inteiro de sessenta e quatro bits, Long, Time Stamp, disse, Cem, vinte e oito. Mink e Max.Bison permite que o Mongo DB utilize estratégias mais avançadas de indexação e consulta aos dados, permitindo que ele seja um SGBD completo e com uma boa performance para grandes volumes de dados. Fique tranquilo. Ao longo do nosso curso, nós estudaremos alguns detalhes a respeito dos índices e consultas. Vamos em frente, como o JSON e o Bson são similares. Muitos dos comandos e funcionalidades do Mongo DB vão dar suporte à utilização de JSON. Você pode inserir documentos no formato JSON em uma coleção, por exemplo, o Mongo irá converter esses documentos automaticamente para o formato BSON. Um último detalhe aqui, oh! Presta atenção. É que o tamanho máximo de um documento Bson é de dezesseis megabytes. Então, esse será o tamanho máximo de um documento no Mongo DB. Beleza, bom, anote aí, pois as bancas às vezes gostam de cobrar essas bobagenzinhas. Gente, fico por aqui até o próximo áudio. Te espero lá. Valeu.

03 - Campo, ID, Bson, Tipos de Dados

Tecnologia da Informação EmÁudio - ReplicaçãoOlá, tudo certo? Bora aprender mais um pouco, agora falaremos da replicação, tá bom pessoal? Cola em mim aqui. Gente, o MongoDB oferece suporte à replicação de modo a prover redundância de dados e alta disponibilidade no sistema. O que é isso aí? A replicação consiste em se ter várias instâncias do serviço Mongod -  Servidor do MongoDB, que permite manipular os dados, controlar o acesso e realizar atividades de gerenciamento com cópias dos mesmos dados. Dessa maneira, se o serviço principal falha, uma das réplicas pode assumir o seu lugar, o que previne o sistema contra perda de dados e permite que o sistema se recupere rapidamente, voltando ao ar e permitindo que os usuários continuem utilizando.Bem, no MongoDB um conjunto de instâncias do Mongod que armazenam réplicas dos mesmos dados é chamado de réplica set (cojuntos de réplicas). Uma réplica set pode ter vários nós (instâncias do Mongod), que armazenam dados e, opcionalmente, somente um nó árbitro. Uma réplica set pode ter até 50 membros. Dentro de uma réplica set, o nó primário (Primary) é aquele que recebe todas as operações de escrita de dados. Os comandos enviados pelos clientes são direcionados a esse nó. O nó primário escreve todas as alterações nos dados no log de operações no MongoDB, que é conhecido como OP log. A partir dessas escritas do nó primário, os nós secundários leiam o OP log do primário checam quais foram as operações de escrita de dados que foram realizadas e replicam essas alterações nos seus próprios bancos de dados para que estes permaneçam idênticos aos do primário.Essa replicação, turma, é assincrona por natureza, pois os nós secundários precisam esperar o primário realizar suas alterações e escrevê-las no log, para então perceberem a necessidade de atualização e aplicarem as modificações nas próprias bases. Como eles têm cópias dos dados, os secundários também podem ser configurados para receberem leituras dos dados por parte dos clientes, de modo a prover o balanceamento de carga no sistema. Tá dando pra entender? Beleza jovem, vamos continuar.No caso de falhas no nó primário, um outro nó secundário é eleito para assumir seu lugar. Essa eleição se dá através de uma votação que ocorre de forma automática pelos nós participantes do réplica set, de acordo com o protocolo de eleição do MongoDB. Os nós permanecem em constante comunicação através de heartbeats, batimentos cardíacos em português, que são sinais enviados por cada nó aos demais para dizer que estão ativos. O MongoDB tem um parâmetro de configuração chamado Election Times, que define o tempo máximo que um nó pode ficar sem ter um heartbeat detectado. Se esse valor de timeout é de dez segundos, por exemplo, após dez segundos sem que as réplicas detectem um heartbeat do primário, ele é considerado inacessível, e a réplica que detectou esse problema convoca uma eleição para que seja iniciado o processo de failover.Em sistemas distribuídos, failover é o processo que ocorre quando o nó primário falha e um nó secundário assume seu lugar. Em alguns casos, como por exemplo, no cenário em que há somente um primário e um secundário, mas não é possível adicionar outro secundário por algum motivo, como o custo de se ter outro nó funcionando, esse esquema de eleição fica prejudicado, já que somente um nó secundário poderia votar no caso de falha do primário. Nesse caso, turma, pode-se criar um árbitro, que é um nó que não armazena dados, mas que pode votar na eleição. A partir da eleição de um novo primário, os demais secundários irão começar a replicar a partir dele. Daí, se o antigo primário voltar a responder, ele irá perceber que há um novo primário e entrar de volta no sistema, agora como secundário. Nesse processo todo, um primário pode se tornar um secundário e um secundário pode se tornar um primário, mas um árbitro sempre será um árbitro, já que ele não tem a replicação dos dados dos demais. Uma eleição pode ocorrer em outras circunstâncias também, não somente na falha do primário. Esse processo pode ocorrer quando o réplica set é criado, quando entra um novo nó ou de forma manual, como parte da manutenção do conjunto. Assunto entendido? Posso me despedir então? Beleza, fico por aqui, tá bom. Até daqui a pouquinho, no próximo áudio!

04 - Replicação

Tecnologia da Informação EmÁudio - ShardingOpa, Voltei! Bora aprender sobre a técnica de Sharding. Técnica do  que Professor?  Sharding, jovem. O MangoDB, dá suporte para prover escalabilidade horizontal. O que é isso aí? A escalabilidade horizontal consiste em dividir o conjunto de dados do sistema e a carga de operações de leitura/escrita através de vários servidores, adicionando novos servidores quando necessário. Sharding, em português, às vezes é chamada de fragmentação ou Particionamento Horizontal.Quando aplicamos a técnica de Sharding, nós dividimos os dados do sistema em fragmentos - Shards. Em um sistema distribuído de banco de dados, um conjunto de servidores é chamado de cluster. Um cluster em que há a utilização de Sharding é chamado de Sharding cluster. Em um Sharding cluster teremos três componentes: Shards, Mongos e servidores de configuração, vamos entender cada um. Shards são os servidores que contêm partes dos dados do cluster. Mongos é o roteador que serve como interface entre os clientes e o Sharding cluster. Em um Sharding cluster no lugar do servidor mongob, que é um servidor padrão do MongoDB, os clientes vão se conectar aos Mongos. E finalmente, servidores de configuração são servidores que armazenam metadados e parâmetros de configuração do cluster.Gente, nesse cenário, os clientes vão enviar as consultas para o roteador, mongos e ele vai encaminhar a consulta para o Shad apropriado. Assim, o Mongo é que vai decidir qual Shad deverá receber a inserção de um documento ou onde está um documento que está sendo buscado na consulta. Em um Sharding cluster algumas coleções podem estar alocadas em Shards diferentes e outras não. Um outro detalhe importante é que um Shard pode ser uma réplica set e não um servidor único. Assim, cada Shard pode ser armazenado em vários servidores distintos.Deu para entender só uma coisinha, jovem? Para fazer o Sharding é necessário definir uma chave de Sharding, essa chave será um campo ou um conjunto de campos nos documentos que servirá para o Mongo determinar qual Shard irá receber quais dados. Daí ouve aí, há duas maneiras de se fazer essa divisão: Hashed sharding ou Range sharding.Entendi nada, professor. Calma, meu querido, vou explicar, tá bom? Na estratégia Hashed Sharding, ou particionamento por Hash é utilizada uma função de hash que irá receber o valor da chave de sharding e com base nele calcular o valor que vai se encaixar em algum dos pedaços. O chunk que você acompanha na ilustração dos valores possíveis, pedaço ou intervalo em que o valor calculado se encaixar vai determinar o Shard em que o documento irá ficar. Agora a turma, já a estratégia Range Sharding, também chamada de Particionamento por Intervalo, é mais simples. O sistema verifica o menor e o maior valor para a chave de Sharding e parte esse intervalo entre eles em vários pedaços. Cada pedaço então é atribuído a um Shard. As duas estratégias são similares, mas o particionamento por Hash costuma resultar em uma divisão mais igualitária dos dados entre os shards. No partionamento por intervalo, a eficiência vai depender da escolha da chave. Tá legal? E aí, conseguiu entender tudo? Que bom, fico por aqui. Obrigado pela companhia. Áudio que vem tem mais.

05 - Sharding

Tecnologia da Informação EmÁudio - Consistência versus Disponibilidade e BackupsE aí jovem, bem-vindo de volta! Hora de falar da consistência versus a disponibilidade, vamos conferir?Bom gente! O MongoDB tem duas propriedades, tá legal,  e  Right Concer, que permitem ao usuário configurar os comportamentos relativos à consistência e ao isolamento das transações de leitura e escrita de dados nos réplicas sets. Elas permitem que o usuário ajuste o comportamento do SGBD para prover mais consistência, garantir que as replicas estejam consistentes entre si ou maior disponibilidade, quer dizer, maior tempo que o SGBD está disponível para receber operações.Além disso, turma, o MongoDB oferece uma série de opções para se fazer backup dos dados para o caso de falhas ou outros problemas que ocasionem perda de dados. As estratégias são as seguintes: Anotem aí primeira estratégia: usar o Atlas. Jovem, o MongoDB Atlas é o serviço de nuvem do MongoDB. Você pode utilizá-lo para fazer backup dos seus dados na nuvem.Segunda estratégia, turma, é usar o MongoDB Cloud Manager ou o MongoDB Ops Manager. Eles são sistema de gerenciamento da infraestrutura do MongoDB, que tem uma interface gráfica e que permite o agendamento e execução dos backups do sistema. Agora, outra estratégia é fazer o backup do sistema de arquivos, ou seja, copiar os arquivos que o MongoDB usa para armazenar dados no sistema de arquivos do computador. E por fim, a quarta e última estratégia: usar o mongodump. O mongodump é um utilitário que gera um arquivo BSON que contém todos os dados armazenados no servidor, com exceção do banco de dados local, que é um BD do sistema. Um backup nesse formato pode ser então restaurado com o auxílio do utilitário mongorestore.Finalizo mais um EmÁudio por aqui. Mas calma, ainda precisamos conversar sobre as propriedades das transações e sobre a segurança. Até daqui a pouco, até o próximo áudio.

06 - Consistência versus Disponibilidade e Backups

Tecnologia da Informação EmÁudio - Resumão EmÁudio Sobre MongoDB - Parte IE aí meus alunos queridos. Bem-vindo ao nosso super resumão da aprovação, o resumão em áudio. Aqui nós abordaremos os temas mais relevantes para o seu concurso. Preparado? Então aperta o play aí e se surpreenda. Vamos relembrar, né jovem?Quero começar nossa revisão lembrando que o MongoDB é um sistema de gerenciamento de banco de dados (SGBD), classificado como NoSQL, que armazena dados no formato de documentos. No MongoDB os dados são armazenados na forma de documentos similares ao formato JSON, que é o formato que permite a representação de dados semiestruturados.  Além disso, você precisa sempre ter em mente que o MongoDB oferece duas versões do sistema: MongoDB Community e MongoDB Enterprise.A versão Community é uma versão gratuita e de código aberto do sistema. A Enterprise é uma versão mais completa voltada para usuários corporativos, mas que é paga. Os usuários precisam realizar uma assinatura para usá-la. Gente, O MongoDB também tem um serviço de nuvem, o MongoDB Atlas, que não requer que o usuário instale o servidor no seu computador.Tudo bem até aqui, vamos em frente. Vou fazer algumas observações rapidinho para que você não esqueça, ok? Bancos de dados se dividem em coleções, análogas a tabelas, que contêm documentos, análogos a linhas das tabelas. Não há esquema fixo nas coleções. Documentos da mesma coleção podem ter estruturas diferentes e não há restrições de tipo ou vazio. Os documentos contêm objetos BSON delimitados por  abre chaves e fecha chaves e  com os campos no formato chave: valor. Campos podem ter valores de tipos escalares ou compostos (objetos e arrays). E campo _id é a chave primária dos documentos.Na hora da sua prova, você também não pode esquecer de como inserir, consultar, atualizar e remover documentos. Para inserir documentos em uma coleção do MongoDB, podemos utilizar os métodos insertOne e insertMany. O método insertOne insere um só documento na coleção. Alternativamente, se queremos inserir vários documentos na coleção de uma vez, podemos usar o insertMany, nesse caso passaremos um array de documentos como argumento e não um documento só.Para consultar dados, podemos usar o método find ou o findOne. Para atualizar os valores de documentos, podemos utilizar os comandos UpdateOne e UpdateMany. Eles funcionam de forma quase idêntica ao insertOne e InsertMany. Por fim, para remover um ou mais documentos da coleção, basta usar o (deleteOne) ou o (deleteMany). O deleteOne remove somente um documento, enquanto o deleteMany remove todos os documentos retornados pelos filtros.E os índices, jovem lembra deles? O Manual do MongoDB define os índices como estruturas especiais de dados que armazenam uma pequena parte dos dados da coleção em uma forma fácil de se navegar. Essa definição captura bem o espírito dos índices, que são métodos de acesso alternativos, que representam uma forma de atalho para se encontrar os dados no banco de dados mais rapidamente. Além disso, o MongoDB tem vários tipos de índices.Vamos conferir comigo, ouve aí:- Índice de campo único: Single Field - indexa somente um campo da coleção. - Índice composto: Compound Index - indexa Múltiplos campos da coleção. - Índice Multi Chave: multikey index - indexa os conteúdos arrays.- Índice geoespacial: geospatial index - indexa dados de coordenadas geoespaciais. - Índice de texto: Text Index - indexa o conteúdo das strings em uma coleção, permitindo a busca eficiente no texto da strings como na atividade de identificar a presença de uma palavra ou parte de palavra, entendeu? - Índice de hash: Hash Index - indexa o hash dos valores de um campo e não os valores do campo em si. Esse tipo de índice só pode ser usado para operações de  igualdade tá pessoal, não suportando consultas que envolvam intervalos de valores.Assunto revisado até aqui. Lembrou de tudo? Que bom, vou dar uma pausa pra você beber uma água, dar uma esticada, mas daqui a pouquinho eu tô de volta! Tá, não me abandona, não hein? Tchau! Tchau até o próximo áudio com mais resumão da aprovação.

07 - Resumão Em Áudio sobre MongoDB – Parte 1

Tecnologia da Informação EmÁudio: Resumão EmÁudio sobre MongoDB - Parte IIOlá! E aí jovem, muito bem, vamos lá pra fechar esse super resumão. Hora de falar da replicação! Vamos lembrar isso aí. Gente, o MongoDB oferece suporte à replicação de modo a prover redundância de dados e alta disponibilidade no sistema. A replicação consiste em se ter várias instâncias do serviço mongod, o servidor do MongoDB que permite manipular os dados, controlar o acesso e realizar atividades de gerenciamento com cópias dos mesmos dados. No MongoDB, um conjunto de instâncias do mongod que armazenam réplicas dos mesmos dados é chamado de réplica set - Conjunto de réplicas - um réplica set pode ter vários nós, instâncias do mongod que armazenam dados e, opcionalmente, somente um nó árbitro. Um réplica set pode ter até 50 membros. Dentro de um réplica set o nó primário (Primary) é aquele que recebe todas as operações de escrita de dados. Os comandos enviados pelos clientes são direcionados a esse nó. O nó primário escreve todas as alterações nos dados no blog de operações do MongoDB, que é conhecido como OP log. A partir dessas escritas do nó primário, os nós secundários lêem o OP Log do primário, checam quais foram as operações de escrita de dados que foram realizadas e replicam essas alterações nos seus próprios bancos de dados, para que estes permaneçam idênticos aos do primário. Essa replicação é assíncrona por natureza. Tá bom, pois os nós secundários precisam esperar o primário realizar suas alterações e escrevê-las no log, para então perceberem a necessidade de atualização e aplicarem as modificações nas próprias bases. No caso de falhas no nó primário, um outro nó secundário é eleito para assumir seu lugar. Essa eleição se dá através de uma votação que ocorre de forma automática pelos nós participantes do réplica set. De acordo com o protocolo de eleição do MongoDB, tudo bem até aqui? E a técnica de Sharding, lembra dela? Então o MongoDB dá suporte à técnica de Sharding, para prover escalabilidade horizontal. Escalabilidade horizontal consiste em dividir o conjunto de dados do sistema e a carga de operações de leitura e escrita através de vários servidores, adicionando novos servidores quando for necessário. Sharding, em português, às vezes é chamada de fragmentação ou Particionamento horizontal. Quando aplicamos a técnica de Sharding, nós dividimos os dados do sistema em fragmentos, sharts, em um sistema distribuído de banco de dados, um conjunto de servidores é chamado de cluster. Um cluster em que há a utilização de Sharding é chamado de Sharding cluster. Em um Sharding cluster, teremos três componentes: Shards, Mongos e servidores de configuração. Ah! Vamos para um detalhe importante: o Shard pode ser um réplica set e não um servidor único. Assim, em cada Shard pode ser armazenado em vários servidores distintos. Bora para o próximo ponto. Além disso, tudo que nós conversamos, o MongoDB oferece uma série de opções para se fazer backup dos dados para o caso de falhas ou outros problemas que ocasionem perda de dados. As estratégias são as seguintes, presta atenção: Primeira estratégia. Usar o Atlas. Jovem, o MongoDB Atlas é o serviço de nuvem do Mongo DB. Você pode utilizá-lo para fazer backup dos seus dados na Nuvem, show. A segunda estratégia é usar o MongoDB Cloud Manager ou o Ops Manager.  O Cloud Manager ou o Ops Manager sistemas de gerenciamento da infraestrutura do MongoDB, que tem uma interface gráfica e que permitem o agendamento e execução dos backups do sistema. Outra estratégia é fazer o backup do sistema de arquivos, ou seja, copiar os arquivos que o MongoDB usa para armazenar dados no sistema de arquivos do computador. Por fim, a quarta e última estratégia. Usar o mongodump. O mongodump é um utilitário que gera um arquivo Bson que contém todos os dados armazenados no servidor, com exceção do banco de dados local, que é um DB do sistema. O Backup nesse formato pode ser então restaurado com o auxílio do utilitário mongorestore. E por fim às transações e a segurança, gente, no MongoDB qualquer operação em um só documento é atômica. Isso é suficiente para vários casos de uso, pois no Mongo DB costumamos representar todos os dados associados a um determinado conceito em um só documento, no lugar de usar várias tabelas ligadas entre si por relacionamentos. Para os casos em que é necessário se ter atomicidade de operações em múltiplos documentos, isso também é suportado pelo MongoDB ao se utilizar transações multi documento, gente, é possível estabelecer transações distribuídas que funcionam até mesmo em múltiplas coleções, bancos de dados ou partições sharts diferentes. Essas transações terão as propriedades esc garantidas. Tranquilidade até aqui? Tá chegando o final já, hora de revisarmos rapidinho a segurança, vamos comigo. Galera, o MongoDB fornece algumas opções para garantir a segurança dos dados armazenados. A segurança i nclui alguns métodos diferentes de autenticação que pode ser do tipo Scram ou  X.509, além de LDAP e Kerberos na versão Inter Price. O Controle de acesso aos dados no MongoDB é do tipo RBAC - Role-Based Access Control, mesmo mecanismo empregado em vários SGBD relacionais. Turma, o MongoDB também tem suporte à criptografia. Toda a comunicação com o servidor pode se dar de modo criptografado com a utilização dos protocolos TLS/SSL, para que somente o cliente autenticado possa enxergar os dados, sendo comunicados com o servidor. Bom como recurso adicional de segurança, o MongoDB Inter PriCe também fornece suporte nativo à auditoria de dados que permite registrar no log do sistema ou em algum outro formato, todas as operações que foram realizadas no banco de dados ao longo do tempo. Grave Isso tá. Muito bem assunto, é entendido e revisado. Beleza, oh, obrigado pela sua companhia e paciência, tá. Espero que você tenha aprendido e gostado. Bons estudos, foco e até a próxima, até o próximo módulo.

08 - Resumão Em Áudio sobre MOngoDB – Parte 2

Receita Federal · Auditor FiscalFluência em dadosModelos NoSQLReceita Federal

Receita Federal

01 - Introdução MongoDB

02 - Arquitetura e Terminologia

03 - Campo, ID, Bson, Tipos de Dados

04 - Replicação

05 - Sharding

06 - Consistência versus Disponibilidade e Backups

07 - Resumão Em Áudio sobre MongoDB – Parte 1

08 - Resumão Em Áudio sobre MOngoDB – Parte 2

Receita Federal · Auditor Fiscal

Fluência em dados
Modelos NoSQL

Receita Federal