Temos três famílias de banco de dados, os bancos de dados SQL, os NoSQL, não apenas SQL, e os NewSQL. Também falamos sobre cargas de trabalho transacionais, operacionais, e cargas de trabalho analíticas. E vimos que dentro desses dois grandes conceitos, os tipos de banco de dados e tipo de cargas de trabalho, nós vamos ter especializações para os bancos de dados que estarão atuando neste contexto, ou em contextos híbridos. Então, com isso, certamente você pode estar se perguntando qual é o repositório ideal de dados. E esta é uma pergunta que está rolando já há bastante tempo no mercado de tecnologia. Então, eu quero discutir com vocês um pouco sobre o repositório que eu chamei aqui de repositório ideal de dados. Então, nós vamos perceber aqui que é possível entender que um repositório de dados ideal tem essas características. Primeiro, escalabilidade, ou seja, começar do tamanho certo para a carga de trabalho que existe hoje, e ao longo do tempo, conforme a demanda cresce, este repositório aumenta de tamanho, e do tamanho certo para aquela demanda daquele momento, e caso a demanda tenha um recuo, este repositório diminua de tamanho. Vamos lembrar que em tempos de nuvem nós temos muito interesse em elasticidade. A computação em nuvem tem uma grande vantagem competitiva em relação à compra de hardware tradicional, que é justamente você começar do tamanho que precisa hoje e ao longo do tempo os seus recursos computacionais vão escalando conforme a sua demanda. Então, este mecanismo também é esperado e buscado nos repositórios de dados. E aí, sobre tudo que nós discutimos até agora da história de banco de dados, já começa a ficar bastante claro que, originalmente, o banco de dados relacional tem desafios de escalabilidade, sobretudo escalabilidade horizontal. Consequentemente, o posicionamento NoSQL já levou isso em consideração e trata muito melhor o tema de escalabilidade horizontal e vertical do que os bancos relacionais, os bancos SQL. Vou aproveitar aqui também para relembrar você que quando eu falar escalabilidade vertical, eu estou falando sobre aumentar o tamanho da caixa computacional aonde aquele banco de dados está. Ou seja, é colocar mais memória RAM, é colocar mais CPU, ou seja, aumentar o processador, e colocar mais disco. Estou falando da instância, possivelmente da máquina virtual onde estava dando aquele serviço. Então, quando eu aumento estes elementos, memória RAM, processador, eu estou falando de escalar verticalmente. Quando eu falo de escalar horizontalmente, eu me refiro a colocar uma outra instância, um outro nó, que vai justamente distribuir, vai repartir a carga de trabalho com o nó inicial. Então, historicamente, o banco de dados relacionais tem mais um desafio, algumas limitações, inclusive, para essa escalabilidade horizontal. Ainda falando sobre o nosso repositório ideal de dados, nós também temos a expectativa de desempenho. Então, vamos resgatar que estamos em tempos de quarta revolução industrial, transformação digital, e que isso traz requisitos de agilidade, de tempo de resposta a um usuário final extremamente rápido, de outra personalização. Então, tudo isso é esperado que um banco de dados moderno entregue alto desempenho para que a gente não tenha uma experiência fragmentada para as pessoas que estão usando as aplicações que usam, por consequência, aquele determinado banco de dados. Um outro ponto importante, que nós vamos nos aprofundar cada vez mais, são as transações ACID. Tenho certeza que você já percebeu que eu tenho falado sobre ACID nas últimas aulas, e aqui não vai ser diferente. Então, é esperado de um repositório ideal de dados capacidades de transação ACID. Vamos relembrar brevemente a atomicidade, consistência, isolamento e durabilidade. Tudo isso pensando na integridade dos dados. Também temos como expectativa de um repositório ideal de dados diversos formatos. Então nós falamos primeiramente de dados estruturados, e aí nós vamos relembrar que bancos de dados relacionais têm uma estrutura fixa pré-definida, que são as tabelas, compostas por linhas e colunas. Nós também teremos formatos semi-estruturados que já trazem algum nível de flexibilidade porém ainda assim existem algumas definições de estruturas então o semi-estruturado corresponde a um arquivo XML a um arquivo do tipo JSON e também comentamos bastante do mundo não estruturado e aí tem tudo a ver com um big data com a validade volume velocidade então quando eu falar de áudios vídeos imagens estamos falando de não estruturados da mesma forma como documentos em pdf planilhas coisas que a gente não consegue ter uma pré definição de estrutura então repositório ideal de dados precisa ter capacidade de lidar com esses diferentes formatos. Consequentemente, também falar de cargas mistas. Nós já entendemos que existem cargas transacionais e cargas analíticas, então, este misto é necessário para um repositório de dados e também que seja possível realizar consultas com uma linguagem rica que o SQL para o BI que consiga trabalhar em lote, em streaming, ou seja, com esse fluxo de dados em tempo real ou de maneira escalonada, a cada hora, de dia em dia, e também capacidade de trabalhar com inteligência artificial e machine learning. E um último elemento, mas não menos importante, é que o repositório ideal de dados entrega acessibilidade ou abertura. Quem for olhar essa referência que eu coloquei aqui no rodapé do slide, vai encontrar em inglês este termo como openness. Então aqui a gente entra na discussão sobre o formato de dado aberto e fechado. Então quando nós falamos de banco de dados Oracle ou SQL Server, estamos falando de um formato de dados fechado. Fechado. Quando nós falamos de JSON e outros tipos de arquivo, como o parqueiro, o orc, o avro, estamos falando de arquivos abertos, acessíveis.