Vamos falar agora sobre os bancos de dados do tipo NewSQL. E para isso, gente, eu vou começar com vocês comentando um pouco mais sobre a Cloud Native Computing Foundation. Dentro do site da CNCF, nós vamos encontrar este mapa, que é o Lands de cloud native e na seção específica de banco de dados nós vamos encontrar todos esses projetos que estão com algum nível de maturidade alguns muito mais outros um pouco menos mas aqui a gente enxerga muito bem o que o mercado tem de banco de dados é uma referência muito boa adicional àquela referência que eu comentei com vocês do DB Engines. Aqui é uma outra referência que eu pessoalmente uso muito e recomendo vocês darem uma olhada. A Cloud Native Computing Foundation, no seu conceito, também comenta com a gente o seguinte, que com a ascensão com a popularização de kubernetes ea capacidade de você ter uma escalabilidade horizontal suportando as aplicações do tipo stateful nós temos uma nova geração de banco de dados que visa aproveitar essas vantagens da contêinerização então esses bancos de dados nativos em nuvem, de uma maneira geral, querem trazer os benefícios de escalabilidade e disponibilidade do Kubernetes para os bancos de dados. Lembra que eu comentei aquele desafio de escalabilidade horizontal com os relacionais? Está aqui a resposta, a contra-ação sobre esse movimento que o mercado nos faz aqui nos projetos que estão rolando de banco de dados. Então, a gente pode entender o seguinte. New SQL, uma nova classe de sistemas gerenciadores de banco de dados relacionais que buscam, de alguma forma, fornecer a escalabilidade dos não SQL, dos NoSQL, para cargas de trabalho de transação, o famoso OLTP, e mantendo garantias de atomicidade, consistência, isolamento e durabilidade. Então, o NoSQL visa você ter a capacidade de interagir via SQL, que você já conhece, e conseguir escalar e estar disponível da mesma forma que um NoSQL está pensando aqui nas cargas de trabalho transacionais. Então, esse aqui é o paradigma dos bancos de dados NewSQL. Se a gente aprofundar um pouco mais esse conceito, nós vamos perceber que linguagem SQL aparece como meio de interação entre aplicação e sistema gerenciador de banco de dados. Isso aqui, na minha leitura, representa a fortaleza que é, e a zona de conforto que é, o SQL para a gente, pessoa desenvolvedora. A gente trabalha muito mais tempo com SQL e com o modelo tabular do que com os modelos mais recentes, seja documental, colunar, grafo ou chave-valor. Um outro ponto interessante também, que a gente encontra na literatura, como concorrência não bloqueante, ou seja, leitura e escrita tem que funcionar de maneira íntegra, não pode concorrer entre si, não pode ter conflito. Maior desempenho por nós, então, quando a gente olha as estruturas dos SQLs tradicionais, que tem um nó primário e o outro standby, na verdade aquele standby está sendo subutilizado, ele só entra em operação quando a gente tem algum problema no nó primário. Então o número 4 aqui é para contornar esse tipo de coisa, esse maior desempenho por nó de processamento. E como já falei, o tema de escalabilidade horizontal, mais nós, memória distribuída e maneira de trabalhar clusterizada ao invés de ser um single instance. Então aqui a gente tem o paradigma principal de New SQL. Aqui a gente vai ver nomes populares como Yuga Byte nessa categoria. Aqui a gente vai ver nomes populares, como o Yuga Byte, nessa categoria. Quero aproveitar e falar também com vocês sobre outros tipos de banco de dados. Então, é impossível a gente não falar, numa aula de banco de dados, sobre os bancos de dados hierárquicos. E aqui estou propondo para a gente uma viagem no tempo. Então, nós começamos falando de SQL, de relacional, que é 1970. Antes disso, nós tínhamos um paradigma de persistência de dados por hierarquia. Então, por isso, banco de dados hierárquicos. E a ideia foi persistir os dados de uma maneira que fosse similar a uma árvore genealógica. Então, um objeto tem um pai, um pai tem muitos filhos. E essa estrutura, apesar da idade, tem um alto desempenho. Ela tem a sua complexidade de interação, para a gente desenvolvedor é desafiador trabalhar nesse modelo, mas uma vez que a gente domina essa técnica de modelagem, os métodos de inserção e acesso, existe um alto desempenho. Um banco hierárquico muito popular está no seu computador que usa o Windows. O registro do Windows é um tipo de banco de dados hierárquico e também os sistemas de arquivo. Então, seja o seu NTFS ou o seu querido FAT, são bancos de dados do tipo hierárquicos. Outro banco de dados interessante de comentar é o banco de dados orientados a objetos. Falei bastante nas nossas aulas sobre SQL e NoSQL, não SQL, sobre paradigma orientado a objetos na nossa programação. Então, o banco de dados orientado a objetos, ele tem essa característica de armazenar os objetos no disco de um servidor. Então, aqui a gente tem um favorecimento de consultas com relacionamentos complexos. A modelagem em objeto trabalha com isso muito bem, facilita a vida das pessoas desenvolvedoras nessa abstração. E um exemplo muito popular é o MongoDB Realm, que é um banco de dados que você coloca nos dispositivos móveis. E a linguagem de consulta vai justamente construindo esses objetos por meio do SDK. Então, aqui eu tenho um trecho em JavaScript de como é uma construção e uma persistência de um registro orientado a objetos. Percebo que a gente tem uma similaridade com o banco documental, mas falando especificamente dessa classe, essa classe é focada em gravar os dados como objetos. O banco Realm tem essa característica, um dos muito populares orientados a objetos. E para a gente fechar essa jornada incrível que fizemos de SQL, não SQL e novo SQL, eu quero deixar uma linha do tempo com vocês para a gente viajar rapidamente, onde a gente observa a maneira como os dados são armazenados, a evolução dos bancos de dados desde 1960 até agora. Então, a gente vai ver ali nos anos 70 e 80, principalmente Oracle, que foi o precursor, e demais tecnologias relacionais ganhando bastante relevância aqui no mercado, com as possibilidades de trabalho, com as triggers, com as stored procedures, que são formas de você enriquecer e trazer responsabilidades da aplicação para dentro do banco de dados. da aplicação para dentro do banco de dados. A gente vai ver a evolução desses bancos de 2000, 2005, com o começo das discussões de NoSQL, com seus white papers, propondo alternativas ao estado relacional do mercado de banco de dados. De 2005 a 2010, a gente vê diversos projetos open source sendo popularizados e ganhando maturidade. MongoDB chama muita atenção nesse cenário, assim como Cassandra, como Redis, como CouchDB. Aparece o esquema flexível, o uso de memória distribuída, um banco de dados chamado de poliglota. Ainda mais a evolução de 2010 a 2015 com a computação em nuvem. Então, a gente vai enxergar os três grandes provedores de nuvem daquele momento, que é a AWS, a Azure e o Google, posicionando bancos empoderados pelas capacidades em nuvem. Logo em seguida, em 2016, a gente vê a Oracle fazendo esse mesmo movimento com a Oracle Cloud e disponibilizando o banco Oracle em sabores em nuvem também, porque surge o Oracle Autonomous. A evolução adicional de 2015 a 2022 de banco de dados para o posicionamento como plataforma de dados. Então, a gente destaca o MongoDB Atlas, o Databricks, o Snowflake, que se posicionam claramente como plataforma de dados para você desenvolver as aplicações e estar empoderado pela computação em nuvem. E de 2023 para frente, aqui em 2024, a gente fala muito de generativa e AI, inteligência artificial generativa e, consequentemente, banco de dados de vetores e busca de vetores. Então, uma passada geral do que significa falar na linha do tempo sobre SQL, não SQL e novo SQL, temos toda essa jornada histórica. essa jornada histórica. E eu queria fechar também o seguinte, tudo isso que a gente falou sobre tipos de banco de dados, o porquê daqueles modelos, daqueles motores, e essa jornada de evolução dos bancos está muito atrelado, na verdade, aos requisitos do caso de uso. Então, eu falei de requisitos lá no relacional muito atrelados a alto custo de armazenamento em disco e a necessidade de gravar a maior informação possível no menor espaço em disco. Depois eu comentei sobre possíveis requisitos em que o padrão de consultas não exige junções em mais de 70% dos casos. Então, esse tipo de comentário são coisas que representam casos de uso e que nortearam a evolução dos bancos de dados nessa linha do tempo que a gente acabou de ver, que vai de 1960 até 2024. Pontos principais para destacar dos casos de uso então nós temos que levar em consideração do lado esquerdo, desempenho qual é o tempo de resposta necessário como é o nosso padrão de concorrência quantidade de leituras necessárias por segundo e escritas por segundo natureza dos dados, eu tenho dados estruturados tenho dados semi-estruturados tenho dados não estruturados, tenho dados semi-estruturados, tenho dados não estruturados, o que estamos fazendo é um post, é uma foto, é uma imagem, é uma estrutura mais ou menos definida, é um arquivo PDF. Qual é a disponibilidade que nós precisamos ter e, consequentemente, se eu estou disponível, eu tenho que estar íntegro ou eu vou estar íntegro sempre, mas não necessariamente todo o tempo disponível. Out estar íntegro ou eu vou estar íntegro sempre mas não necessariamente todo tempo disponível outro requisito super importante confidencialidade segurança da informação eu tenho criptografia em trânsito criptografia em repouso criptografia em uso volumes e formatos então esses elementos queria fechar esse ponto gente que são os grandes norteadores dessa jornada toda, dessa evolução de banco de dados e por isso que a gente tem tanta oferta de banco de dados específica para diferentes casos de uso. Então, aqui um ponto importante é a gente fechar essa aula sabendo que, para escolher de maneira adequada o banco de dados para a sua aplicação, nós temos que entender os requisitos da aplicação. O que estamos resolvendo, como estamos resolvendo um problema para o nosso usuário final na nossa aplicação e qual é a real necessidade dessas pessoas que estão usando os nossos aplicativos.