 E tem que aumentar a tecnologia aqui para apertar o botão. Opa, o pau que até. Está aqui, acho que agora beleza. Boa tarde. Queria agradecer, antes de mais nada, aos organizadores, ao evento, a quem está aí participando, é uma grande honra estar aqui nesse evento gigantesco para o KCD. Uma pessoa de dados aí para falar com vocês um pouquinho sobre bancos de dados em contém, que está ok, né? O slide está tudo certo. Bom, então, o que a gente vai falar aqui, sobre o que a gente vai falar, a gente vai falar sobre Vitas, que é o Vitas. É um banco de dados distribuído nativamente para Kubernetes, né? Ele é um participante da CNCF, é uma dos projetos que a CNCF em Cuba, tá? E a gente vai ver um pouco sobre ele hoje, tá? Vai entrar um pouquinho a estrutura e ver como que a gente pode utilizar esse cara. Antes de mais, me apresentar aqui rapidamente, meu nome é Willian, sou do DBRE hoje no C6 Bank. Eu trabalho ali em uma sala de SRS, apoiando na parte de bancos de dados, administrando dados em cloud, tá? Tentando gerenciar, quanto o modelo on-premise, também para modelos distribuídos, tá bom? Então, minha função lá, eu trabalho como principal cloud solution architect em empresas que eu aljudei a cofundar, que é a Flapper e a Data Tuning, né? Flapper com marketplace de aviação executiva e a Data Tuning, uma custoria de dados, voltado a Big Data, performance e afins, tá? Meu Twitter, redes sociais, geralmente eu e o Nucis me acham, LinkedIn está aí, o Inelina Oliveira, tudo junto. E os blogs, aonde eu estou, estou começando a publicar, e o Data Tuning também, tá? Então, alguns posts e também sobre VITES, eu sei saber um pouco mais, eu vou estar postando aí nos plots, tá? Então, um pouquinho da agenda, vou dar um overview aqui do que é o VITES em si, para que que ele serve, o que ele é, tá? Para a gente, vocês se enterarem sobre essa tecnologia, tá? Que bicho que é esse? Casos de uso, né? Passar alguns casos rápidos e a gente vai fazer uma demozinha subindo um cluster no Kubernetes aqui, demonstrando para vocês rapidamente. E a gente discutindo aí por que de utilizar VITES, em quais cenários e a forma simples de a gente provisorar ele, tá bom? Então, o que é o VITES, né? O VITES ele é um... uma camada, né? Um sistema desenvolvido para clusterizar, podemos... um ambiente mais cinco, o barra MariaDB, né? Ele tem ali compatibilidade com o mais cinco, o sete e oito, MariaDB a partir da dez, ponto cinco, se não me engano, tá? E ele torna possível a escalabilidade horizontal desses bancos de dados, porque o mais cinco de MariaDB são bancos de dados relacionais. Tradicionalmente, para os dados relacionais, tem uma escala vertical. Muitas vezes a gente tem que trabalhar no crescimento da máquina e não do ambiente. Ah, mas sem... Com essa probabilidade, eu consigo trabalhar com replicação de dados. Eu tenho ali modelos de... de trabalhar, formas de trabalhar com por exemplo, Percona, né? Galera cluster de mais cinco, por exemplo, trabalhar ele mais ser mais... Tem formas de fazer. Mas no fim do dia, não é uma escalabilidade tão natural assim, porque você tem ali que replicar o dado, dependendo do tamanho do dado, isso se torna algo moroso, da característica do seu ambiente, a administração desse ambiente acaba sendo bastante pesada, tá? E o VITES, ele vem tanto para trazer a parte de charging de dados, né? Que é algo que não é tão comum para ambientes de bancos de dados relacionais. Você vai ver essa característica em bancos de dados no cycle, principalmente para quem já trabalhou, trabalha com MongoDB, você tem ali um charging nativo há bastante tempo, das primeiras versões, você tem outros bancos de dados no cycle que trabalham da forma do charging de dados, a gente vai falar um pouquinho do que é o charging, tá? É... Vou primeiro passar para alguns conceitos e componentes do VITES, aí a gente cai na questão do caso de uso e a gente discute estratégias de utilização dele, tá? O VITES, ele é composto, trouxe... ele tem bastante coisa, a gente pode passar aqui para a documentação depois ver alguns outros componentes, mas o grosso mesmo está aqui, tá? O que é o space? O que é o que é o space? É o banco de dados lógico, então, imagina que você tem ali, você loga na insta, então a gente vai ver isso na demo e você vai ter ali um banco de dados. O VITES, aquele é um key space, tá? Entenda. O VITES, ele implementa em cima de um banco de dados nacional uma espécie de banco de dados no cycle, tá? Para quem trabalha, por exemplo, fazendo... com caçandra, com bancos de dados DynamoDB, por exemplo, Cosmos, que trabalham mais com Partition Key, o VITES ele vai mais nessa linha, quando você vai fazer o char de dados, você vai replicar, quebrar o seu da instâncias de banco, você acaba criando ali tabelas e você tem que ter a sua chave de particionamento, que aqui no caso, aqui Space ID, tá? Que também você pode implementar um primary index, que ele chama não é primary index, é primary index, tá? E tem os temas que seriam secundários, índices secundários, índices a mais ali para apoiar no seu Vindex, tá? Então, assim, você tem ali no caso VITES, você tem o Key Space, não um banco de dados propriamente dito. Quando você fala do banco de dados lógico, você está subdividindo esse banco de dados em várias instâncias de mais cycle, por exemplo, agora em várias instâncias. Entenda uma instância igual a um processo. Então, você tem lá o MySQLD, que é um processo onde você está rodando seu banco de dados. Normalmente, em casos bem pequenos, no dia de dia corriqueiro, você tem ali o seu banco de dados local, desenvolvimento, até mesmo sistemas menores em produção, você vai ter uma instância que é um processo de MySQLD, rodando seus bancos de dados, por seus esquemas e afins, tá? O VITES o que ele faz? Ele pega várias instâncias, né? Vários processos de MySQLD e distribui os dados entre esses processos, tá bom? Por isso, você tem aí a quebra de chaves ou dados replicados em vários processos. Esse é o grande sacada do VITES. Ele faz essa quebra em instâncias, né? E ele não trabalha dentro de uma instância só de MySQLD, ele utiliza as outras instâncias para amplificar esse dado, tá? E ele também tem estruturas de chaves compostas e outras estruturas muito parecidas com os bancos de dados relacionais padrão, tá? Ele se beneficia disso por conta da Indine, MySQL, MariaDB Tá? E você vai ter o VITTablet, né? Tablet, que você é o back-end que controla os processos de MySQLD, é como se fosse um site que ele vai ficar junto, por exemplo, dentro, ali do dos do seu container, ali do seu pod, você vai ter outros processos do VITTablet compondo, ali entregando os dados para o VTGate. O VTGate é o próximo de comunicação. Quando você tá se comunicando, né? Quando você manda uma query pedindo os dados, né, um result set você tá mandando isso, comunicando com o VTGate. O VTGate vai receber aquela query e vai passar para o VTTablet processar. Então ele vai saber onde tá o dado, né? No caso, se você estiver fazendo o chart, ele vai saber qual que é o processo VTTablet que tem aquele dado, vai passar essa query para ele e vai recuperar o dado e trazer de fome. Então o VTTablet é o que controla o processo do MySQLD e armazena o dado. O VTGate é o cara que recebe as equições, as queries em si. O VTGate fala protocolo MySQL. Então quando você estiver fazendo as queries, é como se estivesse entregando query para o MySQL então ele é muito parecido e traz essa facilidade na gestão, tá? Aí você vai ter o topology, né, que é o processo ou o componente que armazena o estado, as configurações do seu ambiente vites, tá? É onde estão os esquemas, chargens, estados e afins configurações, mapeamentos do seu ambiente que é armazenado dentro de algum componente. Por default tá? Essendim de armazenamento é o ETCD. Como muitas coisas ali que utilizam Kubernetes, né? O vites utiliza ETCD para poder armazenar as suas configurações assim como o Kubernetes, por exemplo. Posso usar outros? Posso. O Quipper é uma outra opção também, tá? O Quipper é mais do pessoal que trabalha com Kafka, por exemplo, já deve ter ouvido falar. Tá? Aí você tem o vtcontroller, né? Como se fosse ele ali opera, praticamente você controla todo o ambiente vites a partir dele, tá? Se tem ali as ações ad-hoc, você tem o control plane, você tem o API server, tá? Ele acaba controlando bastante coisa, bastante do funcionamento do vites, fica dentro desse processo. Vtctld. Tá bom? E aí você tem o control plane, né? Que é composto por vários componentes geralzão, proxy, backup restored que é o extra backup, percona failover automático, charging praticamente tudo aí faz parte do control plane, tá bom? Aqui tá mais ou menos uma foto, né, de da arquitetura do vites em si, tá? Você tem ali os vtgates aqui no meio, né? Você tem esses vtgates recebendo as equições a partir do load balancer em ambientes maiores principalmente ambientes produtivos você vai tender a trabalhar com vários vtgates, porque o vtgate ele é o próprio, certo? Ele recebe as equições. Ele também pode cachear dados a partir das consultas. Então, se a consulta não for algo gigantesco, que traz bilhões de distos, muitas vezes são resulto sets menores, ele vai tender também a fazer o cache daquela consulta, tá? Então, a primeira vez que você for executar ele vai demorar um pouquinho mais a próxima ele já vai tá cachado o vtgate você já vai ter uma maior eficiência, tá? Então, você vai ter um load balancer na frente você pode ter um ou mais vtgates então, conforme o seu ambiente for escalando também os vtgates para ter maior vazão e esses vtgates vão se comunicar com os vttablets que controlam o serviço mais SQLG. Então, você vai ter vários charges, né? Como tá escrito aqui e cada charging é composto por um ou mais componentes geralmente você vai trabalhar aí com um master, um primary, né? E uma réplica. Essa réplica pode ser somente leitura a gente pode ver. Vai passar por isso na implementação rapidamente, tá? Pode ter uma réplica de big data, por exemplo, ou ser servidados analíticos e ser mais eficiente nessa parte de separar esses dados, né? Num perfil mais estático enfim. E aqui de canto você tem ali o controller, né? E os topo servers que vão cuidar aí de toda essa infraestrutura também. Beleza, gente? Tá bem simplificada a arquitetura, tá? É caso de uso, tá? Quando você fala de utilizar o VITES, né? Por que que eu abriria mão do banco de dados relacional tradicional como MySQL para eu começar aí para um VITES, tá? Você vai utilizar o VITES num caso de você da sua aplicação começar a crescer demais, né? Todo banco de dados relacional, quando ele começa a ficar muito inflado, quais são os primeiros problemas que você começa a sentir? Perda de performance, certo? As queries que executavam em segundos, muitas vezes milisegundos, agora demoram minutos, né? Por que? Estabelas crescem, tem mais dados, muitas vezes você não tem ali uma route de mantensão. Ok, ou até mesmo tem, mas suas tabelas estão com bilhões de registros. Qual seria o próximo passo? Você particionar essas informações, certo? Você já vai ter, no VITES você já vai tender a fazer isso, tá? Então, você já vai tentar operar particionando seu dado em pedaços menores, que são chargers. Logo você pode também prover esses dados de forma regional, tá? O VITES você pode trabalhar por zona, então imagina, você tá aqui no Brasil matriz em São Paulo mas você tem ali filiais em outros estados, né? Imagina que você vai poder distribuir esses dados pelo Brasil e cada filial você pode poder entregar um determinado charge em um determinado estado próximo. Então, ah, vou atender o norte, eu entregue um charging que atende o norte. O nordeste, eu entregue um charge que atende o nordeste assim por diante, então eu tenho ali uma disponibilidade maior do meu dado mais direcionada ao meu cliente de uma determinada região. Tá entendendo. Cada charging vai ter sua alta disponibilidade. Então, você vai ter ali uma segurança pra cada nível de dado que você tá querendo entregar. Tá? Pode ser executado local, Kubernetes. Enfim, geralmente você vai ver você vai tentar usar ele dentro do Kubernetes e aí vem mais a vantagem, né? Ah, porque que eu vou executar um banco de dados em container, né? Usar o Kubernetes como um banco de dados que é muito mais que é melhor executar aplicações stateless pra uma agora passar a executar uma uma aplicação stateless por conta da escalabilidade natural dele você tá trabalhando com ele em cloud native, né? Então, se sua aplicação já está resiliente bastante sobre 12 fatores e consegue trabalhar em cloud native você pode trabalhar em Kubernetes totalmente com esse sistema porque ele vai te facilitar a parte de escalabilidade do seu dado. Vocês vão ver, é muito simples, né? Eu altero uma questão ali um número no meu no meu IAMO, eu já consigo instalar a minha infraestrutura. Tá bom? Então, aqui alguns casos de uso em termos de arquitetura, vamos pra uma demo rápido aqui. Você deve estar vendo a minha tela. Eu tenho aqui um minicube, tá? Acho que tá meio pequeno. Deixa eu ver se eu consigo aumentar um pouquinho aqui. Parecinho Fio Beleza, acho que já dá pra ver melhor. Beleza. Eu não tenho nenhum pódico, como vocês podem ver. Vamos provisionar aqui um Vittes, tá? Tô aqui na documentação. Então, eu vou vir aqui no operador. Eu já tenho esse operador aqui comigo, tá? Já baixei aqui a parte do GitHub e iniciei o minicube, né? Então, pra você que quer simular aí no seu pc não tem tanto segredo, tá bom? Então, eu já vou executar aqui o IAMO Operator, criar o Operator em si, tá? Sem muito segredo. Eu já criei aí toda a parte é necessária para o inicial, pra eu poder já em Cluster do Vittes, tá? Esperar ele só terminar de criar aqui, tá? Enquanto isso, rapidamente, né? A gente tem aqui a documentação. A gente tem guidelines, tá? Que eu queria deixar aqui pra vocês conceitos. Aqui é legal, tá? Ah, putz, eu quero saber que é cada coisa? Um tablet, um topology service, um vizkima, o control, o controller, né? Com o que ele funciona, o meu vtgate como ele funciona, eu tenho aqui na documentação vasta aqui bem detalhada do Vittes, tá? Deixa eu ver aqui se já foi. Beleza, já tá rodando. Vamos para a outra parte que é iniciar o nosso cluster. E aí, quando inicie o cluster aí a gente vai discutindo aqui as outras coisas. Então, olha, ele já... O que que ele criou aqui, tá? Mostrar aqui pra vocês no nosso YAML, tá? O que que o inicie é o cluster que cria, tá? Ele pega algumas imagens basicamente o controller, o gate, o tablet, né? Então, controller pra controlar tudo, o próprio de comunicação, tablet que controla o nosso MySQLD e um vtbackup aqui pra gente fazer backup restore, tá? É... Ele trabalha por zona, lembra que eu falei? Você pode ter mais de uma zona disponibilidade e trabalhar com regiões diferentes, beleza? Aqui você pode declarar essa zona, tá? Então, eu tô declarando aqui ela com uma réplica. Então, um controller por zona. Então, no caso aqui só vai ter 6 mega o que mais que é interessante eu mostrar. Eu tenho um dashboard, a gente vai abrir esse dashboard. Se você tiver tudo do ar, ele é bem simples, tá? O problema dele é não tem muito segredo. E aí a gente tem aqui um key space. Lembra que eu falei que o key space é um backup de dados lógico? Eu já tenho que criar aqui na concepção do nosso cluster. Então, eu criei o key space. E aí eu já tô aprovisionando algumas coisas, né? Então, eu tenho o script SQL aqui que ele sete algumas variáveis, criei o usuário, tá? Se ele existir, eu dropo, depois eu recrio, né? Criei alguns metadados, tá? Para que tudo isso funcione, né? Tudo funciona com tranquilidade. Ele tá declarando aqui que esse key space vai ter duas réplicas, tá? Então, a gente vai ver aí que na parte de escalabilidade, eu escalo muitas vezes aqui dentro do meu key space, tá? É super tranquilo. Deixa eu ver aqui se já criou. Beleza, ó. Tá tudo rodando, tá? Só o meu vtgate que já tá aqui que precisa funcionar, talvez. Beleza. Deixa eu ver agora. Então, aqui tá tudo no ar. Vou fazer alguns ordens, tá? Para facilitar a utilização. O Vittes, ele trabalha com portas altas na casa dos 15 mil, tá? 15 mil processo do Vittes. 15.999 é o último. Você tem aí o 15306, que é o processo do MySQL, tá? Então, ele vai fazer alguns redirects aqui, né? Então, ele do 1500, ele setoa a própria porta 1500, né? Tem a 999 e você tem a 306 indo para a porta default do MySQL 30306, tá? Puts, quero me conectar daqui. Já posso me conectar como vocês podem ver, eu já estou dentro de um Vittes, tá? Se eu ver aqui, Cubes, não, né, gente? Show Vittes key space. Opa, key space. Aqui meu key space, tá? Então, já estou dentro de fato de um Vittes, já estou conseguindo me comunicar com o nosso cluster, tá? Também tem os tablets, né? Esses são os nossos processos, então ele está servindo, eu tenho um Primer em uma réplica, servindo dados aqui, tá? Com os espécies de host dele, que são os pods, tá? Puts, olha, brisando aqui. Aqui não vai funcionar. Beleza. Agora com vocês, né? Basicamente como eu tinha dito, né? Puts, eu quero escalar meu tablet, né? Meu key space. Vamos que eu escalo. Simplesmente eu seto aqui quatro réplicas, por exemplo, e faço o apply de novo. Eu vou lá, quando for ver catpods, daqui a pouco vai aparecer mais dois ali, acredito eu, né? Daqui a pouco aparece. Acredito. Eu salvei, deixa eu ver. Acho que eu não tinha salvo. Beleza, não tinha salvo. Beleza. Agora ele começou mais dois aqui. Provisando a mais dois servidores, tá? Então tem mais dois pods subindo com o nosso MySQLDI, nosso tablet e o VBK, o VTBK. Então eu tenho três, por conta desses três containers que eu tenho aqui dentro. Daqui a pouco sobe, já vai ver. Voltando para a documentação o que eu queria deixar para vocês, tá? Como o dica. Aqui, basicamente é essa primeira documentação. Vocês podem ver que não tem muito segredo, né? Vou até aqui mostrar para vocês que é só criar os componentes. É um MySQL padrão, create table normal, tá? O que eu tenho que me preocupar aqui quando eu estou usando Vitas, tá? Se eu for para uma estratégia de charging, ele tem aqui um guia de boas práticas ou um guia, um guideline de como trabalhar ele tem um guideline de como trabalhar com charging, tá? Charging não é algo trivial, tá? Como eu disse, você só vai começar a se preocupar com charging enquanto você estiver crescendo ou você já estiver muito grande. Justamente se você estiver inclusive trabalhando de forma altamente escalada, tá? Ou como eu posso dizer, né? Você estiver crescendo uma vertente muito grande. Então se você for ali precisar diminuir o tamanho dos seus dados para atender os seus clientes de forma direcionada. Se você quiser reduzir contenção, né? Que ele fala aqui vou reduzir contenção como? Trabalhando em pedaços menores. Então aumenta a quantidade de charging, entrega uma porção menor de dados por serviço, né? Então consigo aí com facilidade escalar cada space meu, consequentemente eu vou entregar dados mais em pedaços, tá? Se a gente vier aqui dá um show Vitesse Tablets. Lembra que a gente escalou? Já escalei o meu um tablet meu e eu tenho aí mais duas réplicas aqui, tá? Que no caso ele tá só como réplicar a outra disponibilidade. Eu tinha falado pra vocês, né? Como que eu posso trabalhar ainda? É bacana. Como eu ainda posso trabalhar com essa capacidade de replicação, tá? Se eu vier aqui tablet eu tenho outras formas de trabalhar aqui disponibilizando meu o meu tablet, tá? Meus key spaces. Eu tenho Primeman, que é quem tá de fato rodando ali o nosso MySQL. Eu tenho um app que é a mesma coisa do Primeman e é deprecado. A réplica em si é só uma HA, tá? É regionally. Eu posso entregar uma réplica só regionally. Então imagine aqui ele dá alguns cases, por exemplo, de backup dump processos analíticos pesados map reduce, tá? Ou recharge. São casos de usar regionally. Ah, eu quero deixar uma réplica só para backup tá ali. Imagina que operações de backup podem impactar sua produção. Ah, eu não quero, eu quero entregar então pods, né? Que façam só essa entrega de backup. Ou que só recebam o restore. Eu posso trabalhar dessa forma. E eu também tenho drainage. Então eu posso reservar ali em background, né? É, para fazer ali um recharge em alguma coisa do tipo. Então tem várias formas de eu trabalhar com as regras, tá? E enfim, basicamente era isso que eu queria mostrar para vocês aqui com o nosso VITES. Deixa eu ver se tem mais alguma coisa na apresentação. Que tem algumas partes da documentação que eu acho interessante ver o lab em si do Kubernetes que a gente utilizou a parte de charge in guard lines, né? Em uma olhada. E em termos de lábis um pouco mais desenvolvidos, eu estou trabalhando em alguns lábis com stress test. Então fiquem de olho aí, principalmente no meu blog aqui, Code Data Ops. Eu devo trazer aí alguns lábis, trabalhando com VITES e live-scale. Tentar estimular aí, construir uma aplicação que faça ali um stress test, trabalhando com dados já replicados em multi-região. Então vou ter um cluster de Kubernetes na aplicação do Brasil, por exemplo, ou de Maclaud. E eu vou replicar esse dado dentro do meu cluster Kubernetes e a minha aplicação vai acessar o dado direcionado, por exemplo, tá? É um caso de uso aqui que eu quero trazer para vocês, que aí com tempo aqui a gente não ia conseguir discutir sobre isso. Beleza gente? Vamos ver as perguntas. Deixa eu ver aqui. Acho que o primeiro é do Leonardo, né? Mas os dados ficaram gravados em um pbc comum ou todos os pods? Ou existe outro mecanismo melhor? Tá? Boa pergunta. Se a gente olhar do nosso partilho aqui de novo, deixa esse cara para cá. Então se a gente for olhar aqui, ó, ele tem um storage, tá? Ele tem um pbc aqui. Então eu tenho um read-write 11. Não tem jeito. O Vittes, ele é um state full set. Beleza? Isso daqui é um state full set. Então eu vou ter um storage direcionado para ele, para cada pod, por exemplo. E aí eu posso unir ainda esse cara a outros componentes. Puts, eu quero deixar ainda mais resiliente o meu ambiente. Aqui no caso, ele tá usando um pbc local. Puts, eu quero deixar ele mais resiliente. Eu trabalho com storage OS, por exemplo. Eu trabalho com Port Rocks para poder entregar um pv, um persistent volume replicado. Então eu consigo ainda aumentar essa parte de exiliência de storage. Tá? Você usou o crocote db? Cara, crocote db é lindo demais. Seria a segunda palavra que eu ia tentar entregar aqui. Né? Eu tava fazendo uma alusão com os meus brothers do tranfo hoje, né? O crocote a gente tava discutindo também de utilizar, né? E o Vittes, ele é interessante, tava fazendo a seguinte alusão, né? O Vittes é um cara que pega o banco de dados relacional e transforma no no-sipo, na forma de concepção dele de trabalhar com shard, chaves partitionadas e enfim, né? O crocote db, ele vem do no-sipo, se você olhar o indine dele, é uma indine no-sipo que vale o store, diferente do mais-sipo que é uma indine tradicional relacional. E na camada de cima dele, na hora de você entregar um protocolo de comunicação, o Vittes implementa o mais-sipo, que é um protocolo que você consegue ali comunicar, se você tem uma aplicação que fala linguagem mais-sipo, maravilha. O crocote db entrega um protocolo dele, então ele implementa em cima de um no-sipo, um banco de dados relacional, também de escalabilidade horizontal. Ele usa indine no-sipo para fazer escalabilidade horizontal, que a dele é super mais simples do que o Vittes, pelo menos eu achei mais simples de escalar um crocote db por ele ter essa indine um pouco mais especializado, mas o no-sipo não tem essa capacidade de escalabilidade horizontal, é o Vittes que implementa isso, então essa é a alusão que eu faço, se eu puder comparar o Vittes é um banco de dados relacional que implementa no-sipo e o crocote é um banco de dados no-sipo que implementa relacional, mas ambos entregam banco de dados altamente distribuídos. Muito bom, o crocote db é excelente, multicloud é com ele, a facilidade dele de escalar multi-região é insana. Como é relacionado esse realizado de siparticionamento? Apenas os dados siparticionados permanecem nos volumes ou eles permanecem no volume de forma integral? Quem particiona no fim do dia, o Vittegate recebe e você tem ali a chave de siparticionamento, né? Se eu tentar ver aqui na documentação, eu não perdi muito tempo, mas na documentação aqui a gente consegue ver na parte de Key Space ID em conceitos, né? Ele fala que ele pega pelo Key Space ID. Então imagina que você tenha uma tabela, tá? Essa tabela tem um ID em si, sei lá, ID de funcionário. Ele vai tender a particionar por esse ID, tá bom? Os dados vão estar armazenados dentro do Key Space. Esse Key Space, ele está replicado de um ou mais pods. No caso aqui, a gente está esse Key Space comércio, ele está replicado em quatro pods, certo? Quatro processos de mais cinco. Ele fica armazenado dentro do pod ou no volume que aquele pod está acessando. Beleza? E aquele pod, né? A query vai pelo Vittegate direcionado ao Tablet que possui aquele Key Space, então ele vai retornar a algum desses caras e ele vai retornar ao dado. Escrita, vai para o Timer. Beleza? Consiga substituir o DynamoDB pelo Vittegate? Faz sentido isso? Boa pergunta. Consegue? Consegue? São casos parecidos, tá? Se eu faria isso, depende do caso, tá? Se você quiser ter mais controle sobre sua arquitetura do seu banco de dados em si eu iria para o Vittegate. Também o DynamoDB ele é bem mais limitado, eu acho. A chance de você ocasionar um throttling dele por você não ter esse controle de infraestrutura, né? Crescer mais um Key Space do que outros, né? Você acabar tendo um controle de throttling é grande se você errar o partition Key, por exemplo. Pode o que acontecer no Vittegate, pode mas você tem um controle maior da sua arquitetura. Você vai conseguir ali escalar mais aquele cara pelo menos para dar uma vazão, redistribuir o dado fazer recharge você vai ter esse controle maior. Então vai depender muito da maturidade do seu time enquanto a escolha mesmo. No fim do dia eu acho que seria mais uma opção da escolha do time em si. Mas ambas as soluções são fantásticas, o próprio Dynamo é fantástico. Como o banco de dados Key Veluids, né? Altamente partitionado. Mas já tive problemas de throttling com ele, tá? Tenho minha base da app em um MySQL hoje. Como seria o processo para migrar para o Vittegate? Boa pergunta. Na documentação também tem esse caso de migração e também tem vídeos no YouTube é migrando de um banco MySQL para o Vittegate, tá? Basicamente você faria ali um dump, tá? Você consegue subir um dump. Eu não fiz nenhum caso grande. Geralmente eu fiz com dumps pequenos e ele funcionou super bem, reallocou as coisas. Entende-se que você está indo para um modelo de banco de dados diferente. O Vittegate é diferente do MySQL e usa MySQL. Mas a concepção dele de gestão do dado é diferente. Então, por mais que você migra o seu banco de dados relacionado hoje, está dentro dele. Ah, eu quero usar Sharding. Você vai ter que re-migrar ele de estrutura dentro do próprio Vittegate para você conseguir tirar o máximo desse participamento. Então você vai fazer um dump restaurado dentro dele e distribuir os dados ali. Mas muitas vezes ele pode direcionar um key space só dentro de uma máquina só. Então, para você de fato colocar em um particionamento, você vai ter que fazer um Sharding desses dados e você pode talvez ter que mexer na sua estrutura de tabelas, tá? Por essa característica. Cada réplica do key space corresponde a um shard. Cada réplica depende. Cada que spaces pode ter vários shards, tá? E cada shard, pelo que a gente tem aqui na nossa arquitetura aqui, cada shard ele tem vários pods, né? Ele é composto de vários pods. Então sim, cada que spaces pode estar dividido em vários shards, tá? Shards n e cada shard ele tem que distribuir de uma infraestrutura única ali, de primary réplica e afins, tá? Posso trocar a SQL e server o caçada para usar apenas o Vitsmart? Pergunta difícil, hein? Se é que eu estou imaginando que é, é só codifício de responder. Não, cara, depende. É mais uma que depende do caso, tá? É um banco de daço nacional como o próprio MySQL. Se você realmente precisa de uma escalabilidade horizontal, sim, vá para VITES, tá? É, agora, caçandra. O caçandra já é um banco de daço que escala muito horizontal. É, só se você estiver usando ele muito errado, eu indicaria ir para ele, tá? O caçandra é um banco de daço orientado à query, né? Então, ele já escala muito horizontal, tem um modelo de ring. É diferente, tá? Ele já é um banco de daço do SQL feito para escalar. Então, depende do caso, entendeu? O que é muito grande? Um banco de 100 GB já é grande e suficiente? Não. Eu acho que não, tá? A gente vai estar falando de grande aí, a partir de para VITES 500 GB é OK, a gente já está se preocupando. O que acontece com um dado em caso de perda de instância no cloud? Ele vai estar replicado, né? Então, numa estrutura de banco de daço de um Qubes, por exemplo, um cluster Qubes, você vai tender até um node em cada zona, né? E talvez um cluster multi-master. Então, você vai ter ali o seu banco de daço replicado desse cluster. A tendência é, pô, você perde uma região ou tem uma outra região com a equilidade em si. Ele vai fazer todo o processo de remanejamento do dado e disponibilização naquela região. É baseado em cima da infraestrutura do Qubes, lembrando é o que está servindo o serviço de banco de dados ao Qubes. Ele tem que estar saudável também. Cara, é uma das questões. Opa, fala aqui. Eu ia só pedir pra gente ver se a gente consegue responder mais duas perguntas e já ir pra próxima porque a gente já está em cima do horário. É, eu já estou... Vou responder as últimas duas aqui. Achei viável trabalhar com o banco de dados pra utilizar Long-Horn em produção. Long-Horn é a replicação, né? De... Se eu não me engano. Acho que sim, cara. Boa tarde por acaso realizou teste pra remover o Name Space e restaurar novamente essa estrutura. É tranquilo? Não, nunca fiz esse teste. Você chegou a falar de upgrade versão MySQL? Como ocorre isso? Tendal Time? Não tendal Time se você estiver trabalhando com múltiplas répidas. Mas você consegue fazer upgrade dos MySQL diesel. Eles que têm a versão. Também na documentação é a forma de fazer upgrade. Obrigado, gente. Desculpa tomar muito tempo de vocês. Nada que isso. Obrigado você aí. Aí eu acho que se você quiser tentar responder mais algumas questões que faltaram aí leva lá pro chat, né? E continua respondendo por lá por enquanto. Perfeito. Mas obrigadão aí, muito, muito massa. Quem falou que não dá pra rodar banco de dados em Kubernetes, né? É, pois é, tá aí. Obrigado. Deixa eu puxar o giracinho aqui. Uma. Intermold. Mas eu juro assim que você consegue entrar aí. Você vai... Se ele não tá no Mac, se ele estiver no Mac também e não liberou, aí você vai continuar respondendo perguntas enquanto isso. Ah, como fica a questão de consciência de dados quando utilizado o modo charging? Cara, isso é uma outra palestra. Difícil de responder que era errado. O impacto na performance é insano. Se você estiver usando charging do modo certo... Olha ele aí. Beleza, William. Obrigadão.