Agora vamos nos aprofundar sobre os bancos de dados não relacionais, bancos de dados noSQL, pelos seus tipos mais populares. Então eu comentei que nós temos os bancos de dados noSQL do tipo documental ou bancos de documento, nós temos os bancos de dados noSQL de chave valor, NoSQL de chave e valor. Nós temos os bancos colunares, ou orientados à coluna, ou ainda coluna larga. E os bancos de dados NoSQL de grafos. A palavra grafo aqui, fiquem atentos, não é relacionada a gráficos, e sim ao conceito de grafo matemático. Esses são os nossos quatro tipos. esses são os nossos quatro tipos antes de aprofundar mais aqui em cada um desses tipos eu queria destacar o seguinte falamos bastante na nossa aula sobre os bancos de dados relacionais sobre os sql sobre escalabilidade vertical então lá nos relacionais nós precisamos aumentar o tamanho do computador que está rodando esse banco de dados para crescer e uma arquitetura multinó é uma arquitetura de cluster é acaba sendo mais complexa de colocar em funcionamento e de obter valor por negócio dessa estrutura que tem geralmente um nó primário e um nó de stand-by, aquele nó que fica guardando algo dar errado. Estou comentando isso porque aqui no NoSQL nós vamos nos aprofundar muito com o conceito de escalabilidade horizontal. Então nós vamos falar muito sobre clusterização. Não é comum a gente encontrar bancos NoSQL stand-alone, numa única instância, exceto talvez num ambiente de prova de conceito, um ambiente de desenvolvimento, mas idealmente ambientes produtivos NoSQL sempre vão ser clusterizados, ou seja, multinós. E você com certeza vai encontrar três nós ou mais nesse tipo de arquitetura. Então, para a gente falar de banco NoSQL e aprofundar, vamos gravar escalabilidade vertical como aumentar o tamanho do computador, que nós estamos utilizando para usar esse banco de dados, para operar este banco, e a escalabilidade horizontal, nós estamos colocando para usar esse banco de dados, para operar este banco. E a escalabilidade horizontal, nós estamos colocando mais nós. Eu estou colocando mais computadores do mesmo tamanho, um do lado do outro, para dividir, para distribuir essa carga de trabalho. Consequentemente, falar de NoSQL também é falar de sistemas de dados distribuídos, sistemas distribuídos. Dito isso, vamos focar nos quatro tipos de bancos NoSQL. Primeiro deles, banco de dados NoSQL de documento, popular MongoDB. Aqui, gente, nós vamos prestar atenção no seguinte. Primeiro ponto de atenção. Um banco de dados NoSQL de documento, geralmente vai persistir as suas informações numa estrutura de sistema de arquivos, que vai utilizar o JSON, que é o JavaScript Object Notation, padrão de notação de objeto em JavaScript, ou a sua variante binária, que é o BSON, Binary JSON, o padrão de notação de objeto JavaScript binário, ou ainda o XML, tradicional, mas conhecido, já está no mercado há bastante tempo, o Extensible Markup Language. Então, quando a gente olhar para um banco no ciclo documental provavelmente o projeto deste banco de dados escolheu gravar informação em um desses três formatos por exemplo mongodb que o banco de dados número um no ciclo em geral grava os dados no formato binary jason o bison esses arquivos podem ser indexados, então o índice, tanto no relacional quanto no não relacional, é um artifício técnico para você ter um acesso rápido às informações que estão na sua base de dados. Então, de uma maneira em geral, o nosso problema com banco de dados é ingerir informação constantemente, com alto volume, com alta variedade, com alta velocidade e também entregar essa informação, realizar essas consultas também de maneira ágil, de maneira rápida. O índice é um mecanismo que faz isso. Nesse primeiro momento, vamos associar indexação ou índice de banco de dados como um mecanismo que permite você acessar qualquer registro que você tem em sua base no mesmo espaço de tempo. Esse é o objetivo de um índice, não importa o tamanho de uma base de dados. Uma coisa interessante para destacar aqui no documento é que o formato é muito mais próximo dos objetos que nós abstraímos lá na aplicação. Eu já falei que quando a gente está codificando atualmente, nós codificamos sob um paradigma de programação que é orientação em objetos. Então nós entendemos o caso de uso, entendemos quais são as entidades de negócio que estão interagindo e essas entidades de negócio serão representadas por objetos na nossa aplicação. E no NoSQL documental é muito tranquilo de fazer esse depara, porque na verdade não existe aquele trabalho de fazer um mapeamento de um objeto para uma tabela, uma ou mais tabelas que existem para um relacional. Aqui, basicamente, um objeto é um documento. Então, você tem muito mais aceleração na hora de desenvolver, porque você não tem que fazer uma camada extra de mapeamento, ou utilizar uma camada extra de mercado que faça esse mapeamento para você, que são os famosos ORMs, que a gente às vezes importa essas bibliotecas nas nossas aplicações. Então, aqui a gente tem esse ponto que a forma de pensar e de usar esse banco de dados acaba sendo muito intuitiva. Um objeto geralmente é um documento. Então, isso é o menos tradução necessária para a gente usar e acessar os nossos dados. Outra coisa interessante aqui é que como nós estamos nessa era de transformação digital com requisitos que mudam constantemente, nós temos o paradigma de projetos de agilidade, que nós temos que ir rapidamente para o mercado, provar conceitos, aí surgem os MVPs, que são os produtos mínimos viáveis que você já quer testar. E isso, na prática, aqui no banco de dados, significa o seguinte, a estrutura de dados vai mudar com frequência e vai ser sempre atualizada conforme um novo caso de uso for sendo adicionado. Quando a gente trabalha esse tipo de situação ágil num relacional, a cada mudança que você faz no seu modelo de dados, você tem uma parada obrigatória na aplicação. Por mais rápido que você seja em fazer um comando de alteração de uma tabela, para quem já conhece a SQL, eu estou falando do Alter Table, este comando sempre indisponibiliza a estrutura de dados. Aqui no NoSQL, o modelo de dados é flexível e ele vai conviver, se você pessoa desenvolvedora ou pessoa DBA assim desejar, com versões diferentes. É como se eu tivesse a capacidade de ter documentos da release 1 com um determinado conjunto de atributos e documentos da release 2 com aqueles atributos mais a minha modificação. E isso acontece a quente. Você faz o deploy do seu código novo e pode continuar trabalhando dessa maneira. Com isso, não tem parada para o usuário final da aplicação, você ganha mais agilidade e a estrutura é muito mais fácil de ser provada, ser testada. Consequentemente, a gente tem a sensação de trabalhar, de desenvolver como se os dados se tornassem como parte do código. Aqui no documental, na hora de codificar, basicamente o seu papel é importar o driver da aplicação e você vai perceber que o driver atua como se fosse uma extensão natural da sua linguagem favorita. Então, seja você programar em Java, em Go, em Python, você tem essa sensação. Outra coisa interessante para as pessoas DBA que estão aqui conosco, essa intervenção para alterar uma estrutura de dados, não requer um DBA presente, só se você quiser. Mas você pode deixar a flexibilidade, delegar essa flexibilidade completamente para as pessoas desenvolvedoras e o banco de dados não vai quebrar, não vai parar de funcionar por conta de uma evolução do modelo de dados. Muito oposto ao que a gente viu aqui no relacional. Segundo tipo dos bancos de dados NoSQL, chave e valor. Aqui nós temos um tipo mais simples, um tipo onde nós vamos ter os elementos sendo armazenados como um conjunto de chave e valor, que é um atributo identificador mais o respectivo conteúdo. Então a gente pode imaginar esse modelo de dados aqui como se fosse um banco relacional com uma tabela que possui duas colunas. Ou ainda a gente pode entender um chavevalor como um banco de dados documental, mas de um documento simples, um documento curto, que você tem um identificador, o seu atributo e um conteúdo. Os casos de uso mais comuns desse tipo de banco de dados são carrinhos de compra. Então, sabe o seu e-commerce preferido? Quando você faz lá o seu carrinho de compra, então sabe o seu e-commerce preferido, quando você faz lá o seu carrinho de compra, muito provavelmente você está persistindo num chave-valor, numa estrutura de dados chave-valor, preferências do usuário, perfis de usuário. Aqui a gente pode destacar o seguinte, o que é o precursor desse modelo de dados? É você fazer uma operação de leitura que não precisa de junção. fazer uma operação de leitura que não precisa de junção. O paper original, que começa a falar sobre chave-valor e os motores que vão trabalhar sobre chave-valor, traz um número interessante, para endereçar um caso de uso em que mais de 70% das leituras não requerem junção de dados, o famoso join que existe lá no relacional. Então, chave-valor tem essa aderência muito grande. Colunar. Os colunares, gente, são uma classe interessante para a gente conversar. Então, a gente vai falar de banco colunar, que também é denominado como orientado à coluna ou coluna larga. Os dados aqui estão organizados como um conjunto de colunas e aqui o caso de uso é muito pensado em consultas que estão sendo relacionadas naquele grupo de colunas sem consumir memória com dados indesejados e que vai permitir uma agregação muito rápida de toda essa informação então quero saber quais são os produtos mais vendidos aqui no Brasil naquele determinado período de tempo. E essa agregação em grandes volumes acontece de maneira muito rápida. E também existe aqui um caso de uso muito interessante, que é para escritas muito intensas. Ou seja, do lado das leituras, eu tenho agregações intensas, essa sumarização intensa, e a ingestão de dados aqui é muito intensa também. Os colunares, e pensando especificamente no Cassandra, que é um grande banco colunar, nós vamos perceber a característica de inserção em paralelo massiva. Basicamente, a cada nó que você coloca em um cluster de castandra, você está aumentando linearmente a capacidade de escrita daquele seu cluster. Aqui a gente tem desafios de consistência de dados. Existe uma maneira, como o banco trabalha, que é sempre fazendo append, que é a inclusão das inserções. Então, quando você tem um registro atualizado 200 vezes, significa que você escreveu 200 vezes e tem isso persistido 200 vezes em disco. E em algum momento vai rodar um processo de consolidação disso. Mas até isso acontecer, você abre mão aqui de consistência coluna é um banco num ciclo é muito popular cassandra é um grande nome e também a gente tem que estar muito atento com o caso de uso lembra que o nosso um dos nossos direcionadores da da cloud nate e confio de foundation é pensar no caso de uso que a gente quer para endereçar o quarto caso de banco de dados no ciclo são grafos e aqui nós vamos ter uma diferença de paradigma que é o foco no relacionamento entre os elementos de dados cada elemento está contido em um nó, as entidades estão em um nó, só que agora nós vamos ter maior atenção, maior foco nos relacionamentos entre essas entidades. Então, aqui a gente quer muito capturar e pesquisar conexões em elementos, então a estrutura de dados vai favorecer esse detalhamento deste relacionamento e, consequentemente, também vai favorecer a análise, a leitura desses relacionamentos. Então, os casos de uso muito populares são detecção de fraudes, mercado financeiro. Você consegue plotar, inclusive, visualmente, de maneira bem intuitiva, os fluxos de dinheiro de uma conta para outra, de um cartão para o outro. Então, detecção de fraude é um caso de uso muito popular. E outro também é rede social. Nas redes sociais, nós temos ali muito interesse de entender o relacionamento das pessoas que estão naquela rede social. Então, o banco de dados NoSQL de grafo tem essa característica. o banco de dados NoSQL de grafo tem essa característica. O nome mais popular de grafos no universo NoSQL é o banco Neo4j.