Tipos comuns de banco de dados. Vamos falar sobre os bancos de dados do tipo SQL, do tipo NoSQL ou não SQL e NewSQL, novo SQL. Para a gente começar esse papo, gente, vamos pegar algumas referências importantes que nós temos no mercado. Primeiro eu quero destacar a Cloud Native Computing Foundation, Fundação para Computação Nativa em Nuvem. Vamos dar uma olhadinha no que a CNCF fala para a gente sobre isso. Então, primeiro ponto. Talvez, nesta aula, já seja uma novidade para você a gente falar de New SQL, novo SQL. Mas vamos por partes. Vamos pelo princípio. Em geral, nós vamos falar sobre dois tipos muito comuns de banco de dados. Primeiro deles, banco de dados de linguagem de consulta estruturada estrutura quer language sql provavelmente sua zona de conforto também a minha zona de conforto durante muito tempo na minha carreira segundo tipo deos de dados do tipo NoSQL ou NãoSQL. E aqui a CNCF traz para a gente um comentário bem interessante na própria definição dos tipos de banco de dados, que o banco de dados de uma aplicação deve ser determinado por suas necessidades e restrições. Mantenha isso em mente. Olha que interessante como o critério de decisão para a gente adotar um banco de dados em uma aplicação deve considerar necessidades da aplicação e restrições a serem contornadas no caso de uso. Perceba que o papo aqui não é escolher um banco de dados, e sim resolver os problemas que nós temos na aplicação. Ok, SQL, não SQL. Vamos aprofundar isso um pouco mais. SQL é os nossos conhecidos e queridos bancos de dados relacionais. Um pouquinho de história. Década de 70 surgem como uma resposta ao modelo até então de armazenamento fortemente baseado em arquivos e mainframes, que são os computadores de grande porte. Já naquela época, computação e armazenamento eram algo extremamente caro, custoso para as organizações, para os governos. Então, o paradigma dos bancos de dados relacionais com a modelagem de dados na terceira forma normal, que a gente vê aqui nesse exemplo clássico de tabelas representando entidades e relacionamentos, fez com que fosse possível armazenar a maior quantidade de informações no menor espaço em disco. Essa é uma das belezas da modelagem de dados em terceira forma normal, que é extremamente alavancada aqui pelos bancos de dados relacionais. aqui pelos bancos de dados relacionais. Ok. Adicionalmente, sempre aqui o comentário que nós utilizamos uma linguagem de consulta para essas operações. E aqui vamos entender consulta não apenas como leitura, mas também como a escrita dessas informações, que é o SQL. E o modelo de dados, ele preconiza a gente gravar as informações em tabelas. E essas tabelas estão organizadas em linhas que representam os registros, as ocorrências, aquela instância do que você está armazenando, que vão possuir características ou atributos distribuídos em colunas. ou atributos distribuídos em colunas. O ponto crucial aqui é que essa estrutura tabular de colunas e linhas é pré-definida. Então, antes da gente começar o uso deste banco de dados com uma aplicação, nós previamente precisamos conhecer o modelo de dados que será persistido. Considerando o nosso paradigma atual de desenvolvimento, que é a orientação a objetos, significa que nós vamos fazer uma operação chamada mapeamento objeto relacional, que é pegar um objeto que nós abstraímos no nosso código, abstração de algo da realidade que foi colocada em código pelas pessoas desenvolvedoras, que foi colocada em código pelas pessoas desenvolvedoras, em um conjunto de uma ou mais tabelas. E, frequentemente, são mais tabelas para representar um único objeto. Adicionalmente, os relacionamentos que nós temos entre as tabelas são representadas por chaves estrangeiras, que é o identificador que você tem em uma tabela de outra tabela do seu modelo. Exemplos populares que nós temos de bancos de dados relacionais ou SQL ou SQL tradicionais são o Postgres, o PostSQL, o MySQL, o Microsoft SQL Server e o Banco Oracle. SQL, o Microsoft SQL Server e o Banco Oracle. Aqui tem uma coisa interessante para comentar com vocês, também um ponto de vista histórico. Lá em 1970, o Edgar Colt, que é um dos pais, se não o pai da abordagem relacional, ele deixou essa frase aqui que eu acho muito marcante para compartilhar com vocês. Que usuários futuros de grandes bancos de dados devem estar protegidos de ter que saber como os dados são organizados na máquina. Então percebam que eu tive que explicar aqui para vocês que um banco de dados relacional armazena as informações, fazendo com que entidades de negócio sejam representadas por tabelas. Tabelas têm atributos que são colunas, têm os registros que são as linhas e estão relacionadas entre si. Esse mecanismo, idealmente, deveria ser abstrato. A gente não deveria se preocupar. Nossa preocupação, enquanto pessoa desenvolvedora, deveria ser ir até o driver na aplicação e parar por aí. Então, lá em 1970, nós já temos aqui esse comentário, essa dica do Edgar Code. Mantenha isso aqui em mente, porque nós vamos perceber que outras gerações de banco de dados vão tentar trabalhar com isso em mente. Mas não é um assunto novo, é lá do mundo relacional. Ok, primeiro ponto SQL. Segundo ponto, bancos de dados não relacionais, NoSQL. Primeiro ponto de destaque, NoSQL não significa excluir SQL, não significa o não SQL no sentido de não ter SQL. Ou seja, a ideia aqui é ser capaz de atingir coisas que não são possíveis de serem feitas exclusivamente nos bancos relacionais. Vamos entender um pouquinho mais do que isso significa. Grandes dificuldades conhecidas dos bancos SQL tradicionais são a dificuldade do modelo de dados atender os requisitos atuais. Então, vamos lembrar que o modelo de dados relacional, que utiliza a técnica de modelagem de dados na terceira forma normal, que separa as informações em tabelas organizadas em colunas e linhas, é algo que nasceu lá nos anos 70, numa era muito distante do Big Data que nós vivemos hoje. Então, a era de Big Data significa que nós temos velocidade de dados, variedade de dados e muito volume. Então, com essa popularização das aplicações web e, consequent do big data nós precisamos de formas mais sofisticadas para lidar com toda essa variedade e volume de informações e nesse ponto o modelo de um banco de dados relacional nos apresenta mais complexidade então você imagina capturar dados de uma rede social, seja posts de texto, posts de foto ou posts de vídeos curtos, que são dados não estruturados, que nós vimos na aula anterior, e colocar isso em uma tabela de banco de dados. Tecnicamente, isso até pode ser possível, você usa tipos nos seus atributos de tabela de campos binários, mas com certeza você vai ter desafios para fazer isso performar bem na sua aplicação. Então, a gente quer trabalhar agora com mais capacidade de modelagem, permitir receber esse mundo com grande variedade, que é o Big Data, e com grande volume. Então, a gente começa a ter o posicionamento dos bancos no ciclo. Outro ponto adicional é escalabilidade. Então, tradicionalmente, um banco clássico relacional nos traz desafios de escalabilidade. Ou seja, começamos a operar, o negócio está funcionando, está tudo bem, só que a carga de trabalho aumentou. Então, nós vamos precisar de mais capacidade de processamento, de memória RAM, interface de rede e, com certeza, de disco para armazenamento. O banco de dados relacional tradicional escala de um jeito que nós chamamos de escalabilidade vertical. Trocando isso em palavras simples, você aumenta o tamanho da sua máquina. Você tem que comprar mais disco, mais memória RAM, mais processador. É uma instância. Então, o banco relacional tradicional trabalha em uma instância. Aí, claro que vocês vão me falar que existem soluções de alta disponibilidade da Oracle, que é o Oracle Hack. Existe a mesma coisa do lado da Microsoft, com o SQL Server, com o Always On. Mas ainda assim, essa arquitetura multinó dos relacionais ainda é desafiadora. E o modelo base desse tipo de arquitetura é um nó primário e um nó de leitura que a gente chama de Standby, que ele fica ali aguardando alguma coisa dar errada com o nó primário. Então, essa arquitetura para um crescimento horizontal no mundo do Big Data, volume, principalmente alto volume, variedade de dados, acaba ficando mais difícil de ter esse crescimento. Então, a gente vai encontrar o posicionamento dos bancos de dados não relacionais no SQL e vamos encontrar como os mais populares. MongoDB, que é um banco de dados documental, Cassandra, que é um banco de dados do tipo colunar, DynamoDB, Redis, que são dois bancos de dados do tipo chave-valor e o Neo4j, que é um tipo gráfico. E continua aqui comigo que nós vamos falar mais sobre esses quatro tipos de bancos NoSQL na próxima aula.