Olá pessoal, eu sou o Ronaldo Lanielas e nessa aula eu vou falar para vocês sobre o que são streamings, tables, view materializadas e queries no Cacique ODB. Então vamos começar com o streaming. Quando a gente está falando de Cacique ODB, a primeira coisa que geralmente a gente começa a fazer são os streamings. Então imagina aqui que você tem um tópico, certo? E aí esse tópico aqui está recebendo todos os clientes que são criados no seu sistema. Então cada cliente que você cria vai chegar nesse tópico. E aí você quer fazer um streaming. Um streaming nada mais é do que vou fazer uma analogia aqui como se fosse um consumidor. Então é um consumidor que vai ler todos os eventos desse seu tópico e deixar disponível para que você consiga aplicar o que? Filtro, consiga fazer queries, que a gente vai já ver como faz queries, mas a ideia do streaming é que você tenha aqueles eventos, aqueles tópicos disponíveis de alguma forma para que você consiga aplicar filtros e fazer outros mecanismos naquele streaming. Aí você pode perguntar, tá, mas eu poderia simplesmente criar um consumidor em Golang e fazer o consumo desse tópico diretamente e aplicar um filtro. você pode perguntar, mas eu poderia simplesmente criar um consumidor em Golang e fazer o consumo desse tópico diretamente e aplicar um filtro. Poderia, é verdade. Mas a vantagem aqui de usar o Cacico é que você poderia tirar, por exemplo, a responsabilidade desse consumidor de pegar a cliente que só tem ID maior que 10 e deixar isso para o cacico. Então, o cacico poderia usar o streaming para aplicar um filtro onde os clientes são maiores que 10 e a sua aplicação em Golang, ela vai ler apenas esse cliente maior que 10 já no, como é que eu posso dizer? Já no evento final. Então, a gente não precisa aplicar mais nenhum tipo de filtro. De uma forma muito mais otimizada, o streaming do Cacique é bem otimizado, etc. Então, eu coloquei alguns pontos aqui, como o streaming mantém o histórico de todos os eventos. Ele aprende only, então, vai sempre ser inserido novos eventos a esse streaming. Você usa o comando createStreams. A gente vai ter uma aula só de hands-on, onde a gente vai botar a mão na massa e criar streaming, criar table, etc. Mas o comando para criar um streaming é createStreaming. E a gente pode criar streaming de um tópico, que é como está aqui no desenho, ou de outro streaming. Então, eu posso criar um chain, uma cadeia de streamings, onde eu posso ter, ah, eu começo de um tópico, eu tenho um streaming plugado nesse tópico, que faz um filtro de cliente maior que 10, aí eu tenho outro streaming plugado nesse streaming, que agora pega clientes que têm mais de 50 caracteres no nome e aí eu vou aplicando streaming em cima de streaming até eu ter, por exemplo, um resultado final é claro, você tem que pensar em performance etc só dei um exemplo aqui, mas nesse caso não faz muito sentido o ideal seria você ter um streaming com esses dois filtros, a não ser que você tenha dois UZQ separados, onde cada um precisa de cliente maior que 10 e outro com o caractere maior que 50, mas enfim, vai de casa a casa. Aí a gente fala de tabelas e view materializadas. O streaming, como eu falei, ele deixa o resultado disponível para você on the fly. Então, ele está lá no CACICO disponível para você plugar no streaming através de uma query e pegar aquele valor. A view materializada, por outro lado, ela vai escrever o resultado em um tópico com uma função de agregação. Como assim? Vamos imaginar que a gente tem um tópico de cliente de novo. Na verdade, eu vou até mudar. Vamos imaginar que a gente tem um tópico de venda. E nesse tópico de venda, a gente tem o nome do cliente. Cada vez que aquele cliente faz uma compra na loja, eu crio um novo item de venda que a gente tem o nome do cliente, certo? Cada vez que aquele cliente faz uma compra na loja, eu crio um novo item de venda que tem o nome dele. Então, imaginando que o Ronaldo realizou 10 compras, ele vai ter 10 vendas naquele tópico, vai ter 10 linhas naquele tópico, tá? 10 registros, né? O Cacico Streaming, como eu falei, ele vai manter aqueles 10 registros on the fly, prontos para mim conseguir fazer algum tipo de consumo. Por outro lado, a minha View Materializada, que usa uma tabela, por isso que eu coloquei junto tabela e View Materializada, a minha View Materializada está consumindo desse streaming, está agregando e gravando num tópico. Como assim agregando? Eu poderia, por exemplo, fazer uma agregação pelo nome do cliente. Então eu poderia colocar uma agregação que diga o seguinte, faça um group by pelo nome. E aí eu consigo dizer exatamente quantas vezes aquele cliente fez uma compra na minha loja. Porque eu estou aplicando um group by igual como você aplica lá numa base relacional. E aqui começa a aparecer um primeiro conceito que é o persistent query. Esse é um dos tipos de query. Quando você cria uma view materializada de um streaming ou um streaming de um streaming, por exemplo, você está fazendo uma query, porque a view materializada precisa fazer uma query no streaming para poder ter aquele dado e filtrar e agregar etc. E nesse caso o nome dessa query é persistent query, porque é uma query que vai ficar rodando lá por um longo período de tempo em um background e ela origina uma vima trinizada, uma tabela, um streaming. Por isso que o nome dela é persistent query. Como eu já estou falando de query, vamos só fechar aqui. A primeira que eu expliquei, que é o persistent query. Aí tem o pull query e o push query. O pull query é praticamente igual a quando você faz uma query num banco relacional. Então você vai lá, SELECT, Arterístico, From, nome da tabela, e ele vai te retornar todos os dados. PULL query é isso. Você manda um comando de PULL, que é um SELECT FROM, e ele te retorna naquele exato momento os dados que tem naquela tabela para você realizar algum tipo de análise, etc. Por outro lado, o push é um pouco mais diferente a alguma coisa que geralmente você não vê em uma base relacional. Que é assim, você faz o mesmo select, aterístico, from, alguma coisa, só que no final você coloca uma palavra reservada Chamada emit changes Quando você bota esse emit changes Você transforma aquela query em Post query Que nada mais é do que Todo tipo de registro novo que chegar Vai ser avisado pra você É como se fosse um post notification No seu smartphone Então quando você tem lá o seu celular E chega uma mensagem no Instagram Você recebe um post notification D seu smartphone, né? Então, quando você tem lá o seu celular e chega uma mensagem no Instagram, você recebe um post notification dizendo que chegou uma mensagem. É a mesma ideia. Só que aqui você está usando para receber uma notificação de um evento que chegou, talvez de um tópico, de um streaming, de uma view materializada, tá? A post query você pode aplicar em streamings, pode aplicar em view materializadas, você só não vai conseguir aplicar em tabela, mas tanto em view como em stream você consegue aplicar. Tá bom? E era isso, pessoal. Espero que vocês tenham gostado e até a próxima.