Discutindo sobre Banco de Dados - Dos primórdios a Big Data

Olá pessoal Fábio Akita desde que eu comecei o canal banco de dados é um dos temas que eu mais queria discutir mas eu vim postergando para poder explicar fundamentos antes o objetivo não é ensinar SQL ou mongo DB nem nenhum outro em detalhes é da perspectiva para quem está iniciando entender porque diabos existem tantos tipos diferentes de bancos de dados quando se deve considerar um em vez do outro vai ser um vídeo mais alto nível sem tanto código em si mas sim dá em sites para vocês pesquisarem nas respectivas documentações depois eu vou começar nos

primórdios e só na metade vamos começar a cair em SQL no SQL Então vamos lá infelizmente se você tava esperando um vídeo sobre modelagem modelo entidade relacional ou RMS design pátrias e coisas assim ainda não é esse vídeo objetivo é falar mais o que acontece por baixo dos panos as tecnologias que formam um banco de dados eu acho que modelagem só é efetiva se você sabe como a plataforma por baixo realmente funciona se não modelagem vira sua superstição e você só acha que sua modelagem é boa sem realmente saber o que ela causa por baixo

tudo que você não sabe como realmente funciona vir a superstição eu sempre falo que uma das vantagens que eu tive foi conseguir testemunhar as versões 1.0 de Quase tudo que surgiu nos últimos 40 anos se você pegar um banco de dados moderno como montar uma DB na WS ou tigres eles têm dezenas de funcionalidades que não são imediatamente óbvios para que que foram criados sem saber isso você acaba tentando usar os lugares errados Ou acha que são ruins ou acha que você que é burro e não consegue usar Pense por um segundo o que é

um banco de dados a primeira Poderíamos dizer que é um programa que facilita e gerencia o armazenamento de dados estruturados Pense um armário com gavetas cada gaveta com um tipo de formulário as gavetas seriam nossas tabelas e o armário seria o banco de dados eu acho que é parecido com que a maioria de vocês devem imaginar para iniciantes acho que vale a pena retornar aos fundamentos por isso sempre falo tanto que é importante aprender a fundação como algoritmos estruturas de dados O problema é que a estrutura mais simples de aprender por causa disso comum de

usar são listas essas seriam as gavetas em particular listas ligadas ou arreios puros e se escolher a partir desse ponto vai ter problemas vamos entender o banco de dados mais simples de todos um armário só com uma gaveta é um mero a rei em memória com registros como strect ou uma Instância de uma classe ou objeto lembra como uma reestruturada em memória uma rede interes com 10 elementos Provavelmente tem 10 vezes 64 bits ou 8 bits ocupa 80 bytes no total todo a rei tem elementos de mesmo tamanho fixos sempre se eu quiser pegar O

Quinto Elemento desse arreio basta contar que tenho quatro elementos antes vezes 8 bytes então 32 b para frente eu vou achar O Quinto Elemento se eu souber qual posição do Arreio eu quero encontrar independe se tá no começo ou no fim o tempo de acesso é o mesmo tempo constante o arreio pode ter 10 elementos ou 10 mil elementos leva mais ou menos o mesmo tempo para acessar qualquer posição quando todos os meus dados cabem na memória RAM toda a operação é simples mesmo se eu não souber a posição na pior das hipóteses eu faço

força bruta via um loop do primeiro até o último elemento até encontrar e isso seria de longe um jeito mais Tosco de se procurar alguma coisa numa lista mas para conjuntos de dados pequenos quase ninguém nota a diferença mas deixa eu repetir Procurar dados numa lista com um grande loop e que dentro é o jeito mais absurdamente correndo e inaceitável e eu vou repetir de novo para ficar claro se você tá fazendo loop para procurar itens numa lista você é insano isso porque todo programadores especialmente iniciantes sempre lidam com poucos dados é muito difícil entender

complexidade de algoritmos e diferença nos tempos de processamento Você só tem 100 mil elementos só quando começar a lidar com centenas de milhares milhões de elementos que vai começar a fazer diferença eu já vou chegar nisso enfim Imagine que lá no começo da Computação todo mundo lida com poucos dados comparado com hoje por isso as primeiras soluções são simples um arreio com elementos de tamanho fixo é a forma mais fácil de pensar e quando acaba a memória digamos uma lista de produtos ou lista de clientes Não e-commerce obviamente não cabe tudo em errando Aí temos

que pensar em gravar esses dados em disco e a forma mais simples de fazer isso é o bom e velho arquivo atende onde onde vamos adicionando novos elementos no fim do arquivo é fácil pense num registro com uma estresse de ser ou uma classe de Java script ou Python só garantindo que todos os elementos têm o tamanho fixo Eu determino uma estante com o primeiro campo sendo o nome completo como a sem letras onde cada uma representada por um código utf8 de 8 bits sem bytes no total Depois temos um número de telefone com DDD

de três caracteres um prefixo de três números como era antigamente e um sufixo de quatro números mais parentes e hífen total de 13 letras ou 13 bytes temos um total de 100 bytes mais 13 ou 113 bytes O Primeiro Registro vai ocupar o começo do arquivo começando do endereço zero e indo até o endereço 112 bites o segundo registro começa em baixa 113 vai até 225 e assim por diante eu posso abrir o arquivo e até o final e gravar mais um registro e assim fica fácil sair cadastrando novos registros de curiosidade eu queria aproveitar

para mostrar a segunda linguagem em ambiente de programação que eu aprendi depois do base que quando eu era pré-adolescente acho que era 1990 e tinha uns três ou 14 anos meu pai tinha pedido para o meu tio trazer um PC lá do Paraguai era um PC até 28 seco 1 MB de Ram 10 ou 20 mega de HD veio instalado com ms-dos 3.0 e meu tio tinha deixado também o programa que ele usava para trabalhar o The base 3 Plus ainda da antiga empresa Ashton Tate e era só isso que tinha Instalado não tinha internet

naquela época eu não tinha livro nem nada por acaso um outro primo meu tava estudando isso e me emprestou uma apostila do curso que tava fazendo foi meu primeiro PC então só de ver ligado e tem um teclado que eu podia usar em vez de uma máquina mecânica de datilografia eu já achava incrível Minha Primeira ideia foi copiar apostila do meu primo eu digitei tudo do zero acho que no World Star Este é o World Star ele tem um aspecto esquisito porque tá configurado no modo de 50 linhas que eu vejo já permite em vez

de 25 linhas de CCA essa versão é uma das últimas que saiu pra dose eu acho que a 7.0 daí tem ajudas que as versões iniciais não tinham com o menu completo com todas as opções senão a única forma de usar ela lembrar dos atalhos como control + p e b para iniciar modo daí repete com controle para voltar para o modo normal control py para Itálico e assim por diante era tão moderno que tinha até um Preview em modo gráfico para mostrar como ficaria na impressora Essa época estavamos na transição do modo texto de

doz para o mundo gráfico de Windows 3 muitos editores de texto atuais com o próprio vs code ou obsidian da vida tem modo de ficar focado que deixa o texto no centro e esconde toda a distração são inspirados em editores antigos como esse wordstar esse é o editor que o George armarketing diz que usa para escrever o Game of Thrones enfim pequena tangente para mostrar como eu copiei a apostila de bebê e mais para frente eu consegui comprar livros de verdade eu acho que nenhuma linguagem eu comprei tantos livros para aprender quanto DBS e seus

sucessor o Creeper olha só os que eu ainda guardei e a Razão de tanto livra que antigamente não tinha Google nem está coverflow lembre-se depois que surgiu a web já não precisei de tanto livro assim abrindo o The base tem um braple um interpretador de comando nem quando se digita node ou Python e dá para começar a digitar comandos mas também tem um sistema de menus aqui para facilitar Olha só eu posso escolher a opção de criar um novo banco de dados digita o campo nome tipo queracter com 100 letras depois do Campo telefone tipo

keracter também com 13 letras eu vou aproveitar e adicionar um campo de empresa com 100 letras e pronto daí quando eu salvo já me deixa começar a cadastrar vamos lá eu quero me cadastrar aqui Fábio aqui tá telefone blá blá blá empresa coldman 42 agora eu vou cadastrar se se o Wayne o criador do The base que depois se tornaria vice-presidente da Ashton Tate finalmente vamos cadastrar Brian Russell que criou o compilador Creeper para nantucker de Corporation nenhuma dessas empresas existe mais as tontage foi adquirida pela borland que depois viraria em prize depois embarcadeiro e

a divisão com o de guia quem ainda mantém o delfie Se não me engano a Nan Tucker iria para CIEE ou computers que desde 2018 faz parte da Brother com todo o sucesso que eles tiveram 80 e 90 desapareceram ao ponto que hoje ninguém mais lembra é um bom lembrete que nada dura para sempre enfim eu terminei de cadastrar meus contatos Eu posso salvar e sair com o control end agora eu tô na tal linha de comando do interpretador eu posso abrir o arquivo do banco fazendo youse contatos digital comando list e olha só lista

o que eu acabei de registrar Esse é o avô de todos os Croods o cru de original no mundo dos microcomputadores não o primeiro mas possivelmente um dos mais populares o formato de arquivo que se o inventor foi o famoso DBF literalmente data base quando eu era novo antes de pular para tecnologias mais novas como se conserva da Microsoft na minha cabeça banco de dados é o que você chama de tabela o The base gravava uma tabela por arquivo e chamava isso de banco de dados hoje banco de dados é um servidor com conjuntos de

tabelas no único que vão no fim dos anos 80 banco de dados para mim era um arquivo como uma tabela esse arquivo tem um espaço reservado nos primeiros preços para metadados informações como total de registros e coisas assim mas os registros em si tem todos o mesmo tamanho fixo no exemplo dos contatos são 100 bytes para o nome 13 por telefone e sempre a empresa então cada registro sempre vai ocupar 213 bites basta ir pulando de 213 em 213 para ir avançando para o próximo registro Como programar dor você precisa entender essa estrutura Digamos que

eu queira encontrar o telefone do Brian como que faz como anos 80 vamos começar Do jeito mais simples ou seja Tosco podemos escrever um programinha besta que eu vou chamar de list.prg eu abro o arquivo com youse limpa a tela e começa a fazer um loop checando que não estamos no fim do arquivo and of file e o f como tá aqui daí eu fico comparando o campo o nome do registro atual com Brian e não acharia nada e isso porque eu preciso procurar pelo nome exato então Brian rossel e claro eu posso só pesquisar

as primeiras letras também mas é uma operação a mais por agora eu vou simplificar da linha de comando nós podemos chamar o The base usando esse programa nesse exemplo idiota começa pesquisando o Primeiro Registro que é Fábio não achou e não é o fim de arquivo então vai para o próximo com o comando skip que é cicio ainda não é fim de arquivo então é para o próximo e acha o Brian daí é só pegar o campo empresa e imprimir na tela com esse comando sei e sair do loop com Exit Esse é o pior

caso onde o que eu quero achar é o último registro imagine um arquivo muito maior com 1000 registro precisaria aí um a um mil vezes todas as vezes por isso esse é o jeito mais Tosco que mais primitivo de procurar num banco de dados e agora que entendeu isso prometa que nunca vai fazer desse jeito num computador moderno esse programa vasculhando milhares de registros e ia demorar menos de um segundo mas nos anos 80 poderia levar alguns segundos dependendo de quantos registros eu tenho mas claro nem nos anos 80 a gente era ruim de fazer

desse jeito Tosco em bebês mesmo dava para criar um segundo arquivo um índice Basta fazer o muito em de nome e vai criar um arquivo separado de índice com extensão ndx e podemos abrir o banco de dados com use contatos index e indique nome como já tá aberto podemos só fazer 7 indics que podemos ficar mudando de índice dependendo de que Campo queremos procurar eu tinha digitado errado o nome da empresa do cisso Então vamos fazer se que se o n e fazer o replace a empresa wi-fi Ashton Tate pronto É assim que procuramos e

Depois modificamos um registro o comando Sic vai usar o índice em vez de fazer um loop com comparação Como Eu Fiz antes aliás Esse comando replace serve para mudar dados dos Campos do registro atual conscie que podemos encontrar um registro mas para criar um novo teremos que fazer aprende Blank antes para tentar ou anexar um registro vazio no fim do arquivo e daí o replace gravaria os dados nesse registro novo e esse é o básico esse tipo de índice eu já expliquei no episódio de árvores e também nos de armazenamento é uma variante de uma

bitre Lembra que eu falei que árvores são as estruturas mais importantes da Computação o arquivo DBF de banco de dados é mais ou menos como se fosse uma redestrucks em disco mas um arquivo ndx de índice é uma estrutura de árvore B daí em vez do tempo de procura ser linear em força bruta com Lupi 1 a 1 com o índice passa a ser logarítmico que é uma ordem de grandeza mais rápido e eficiente Ou seja no meu programa de procura tosca via Lupe comparação se cada comparação e Skip levasse Digamos um mini segundo e

eu tivesse r$ 10.000 registros e o que eu procuro tivesse no último registro então no pior caso levaria 10 milissegundos 10 segundos inteiros mas se eu usar um índice em bitre com complexidade logarítmica levaria talvez pouco mais de 10 milissegundos mesmo se eu dobrar essa quantidade de registros o tempo de pesquisa não iria aumentar muito mais que isso dado à natureza logarítmica dependendo do que eu tô fazendo ganho de performance poderia ser 100 vezes ou mais usando o índice certo e por isso falamos tanto no mundo de bancos para sempre garantir que tenham índice correto

preparado Mas e se eu quisesse Agora procurar pelo telefone ou pelo nome da empresa bom podemos criar um índice para cada Campo como index ou um telefone e index ou empresa entre note como o nome do índice eu tive que truncar um pouquinho em ms-dos nomes de arquivos podiam ter no máximo 8 letras era uma limitação do Fat 16 antigo o sistema de arquivos fat que você usa para formatar esse de cards para câmera é ou FAT32 ou mais moderno e x fat não fat 16 antigo são compatíveis mas com limites muito maiores e por

isso dá pra ter nome de arquivos longos normalmente voltando para o dócil podemos listar os arquivos criados Como eu disse antes cada registro vai ocupar aproximadamente 213 eu tenho três registros então teremos pelo menos 639 bites E no caso o formato DBF grava mais coisas como cabeçalho de metadados por isso faz sentido ser 986 bites mas veja cada de índice um kilobyte cada acho que é o tamanho mínimo para um índice eu fiz um programa besta para adicionar mais registros falsos só para aumentar o tamanho dos arquivos Olha a listagem aqui a chatice de uma

linguagem tão rudimentar quanto dbz3 é que eles sequer tem função para gerar números aleatórios nem coisas triviais como calcular o módulo de um número então eu tive que fazer um gerador de números usando só segundos não tem nem função para pegar milissegundos então eu tenho muitas letras repetidas mas tudo bem Olha só como eu tive que fazer para calcular o módulo na mão daí eu vou pegando letras da tabela Ask e com o catenando é super rudimentar gerando 40 novos registros e rendexando vamos ver o tamanho dos arquivos o banco de dados a tabela de

contato em si com 43 registros agora ficou com quase 10 kg um pouco mais de 240 bits por registro em média já os índices o de nome ficou com quase 8 kg e telefone que é um campo menor ficou com um pouco mais de 2 kg empresa é o mesmo tamanho de nome então ficou com uns 8 kg também Pense por um segundo os arquivos de índice estão ocupando quase o dobro do espaço da tabela em si muita gente pode não entender isso mas índices ocupam espaço E não é pouco espaço mais importante que isso

num banco moderno Digamos que a operação de inserção na tabela de um novo registro leve um milissegundo mas agora Digamos que temos esses três índices e atualizar cada um dos índices leve mais um mini segundo cada agora é um total de 4 milissegundos para inserir um novo registro e atualizar os índices o tempo de inserção ficaria quatro vezes maior índices é uma faca de dois gumes por um lado podemos acelerar a pesquisa em 100 vezes talvez mais mas por outro lado operações com inserção atualização ou deleção vão demorar duas vezes mais quatro vezes mais dependendo

da quantidade de índices que tivermos entendeu aliás índices em bebês ou mesmo em clipe eram super instáveis Vira e Mexe ficavam desatualizados e por isso todo o programa que fazemos naquela época colocava no menu uma de manutenção ensinavamos o operador do cliente rodar de vez em quando era operação para rendexar tudo do zero para garantir que a pesquisa ia funcionar quanto maior a tabela mais demorado ficava rendexar felizmente bancos de dados modernos são bem mais estáveis para atualizar os índices e fazer isso sem precisar de intervenção manual na maior parte do tempo mas não é

só isso até agora eu só falei sobre adicionar novos registros nesse arquivo isso é fácil é só ir apendando com catenando os bytes do registro no fim do arquivo atualizar também não é tão difícil é só dar Sic para encontrar o registro pelo índice e dar replace para substituir com o dado novo por cima do campo desejado mas e para apagar o que que acontece pensa uma rein e memória é uma sequência contínua se você quiser deletar um elemento no meio não tem outro jeito precisa criar um novo Arreio e copiar todos os elementos de

novo para não ficar buraco no meio por isso que em memória usamos outras estruturas como listas ligadas daí é só mudar o ponteiro do elemento anterior para apontar para seguinte mas listas ligadas são super ineficientes comparados com a Reis são mais difíceis de Navegar porque não tem endereços contínuos então não tem como só calcular o offset e direto para o elemento no fim tem que ir navegando ponteiro a ponteiro é muito lento um arquivo DBF é parecido com a rei não tem como apagar um registro no meio o que acontece que cada Registro tem um

bit separado só para dizer se é válido ou não quando manda apagar Ele só grava esse bit de zero para um daí quando tentar da SIC ou navegar para frente com skip ele vai ignorar se esse beat estiver marcado como apagado isso torna a operação simples contra edoff o espaço no disco vai continuar sendo ocupado o arquivo não diminui de tamanho por isso que além de rendaxação que é regenerar os arquivos de índice Natal a opção de manutenção também tinha outro comando pack o que o pack vai fazer é a mesma coisa que com uma

rei ele vai gerar um novo arquivo DBF do zero e copiar todos os registros não apagados para e no final apagar o arquivo antigo Esse é o único jeito de recuperar espaço do disco mas para isso precisa ter quase o tamanho do arquivo original de espaço livre sobrando para fazer a operação e isso existe até hoje em bancos de dados modernos quem já mexeu com sicoot 3 ou push deve ter esbarrado no comando vaquio tem até a opção de Alto Vaqueiro para ele fazer isso sozinho sem termos que enviar o comando manualmente mas em essência

é a mesma ideia do comando pack de d-base recuperar espaço em disco e de fragmentar os dados no disco para ficar mais eficiente ocupando menos espaço falando em si colete três ele seria o sucessor Espiritual do d-base e Creeper é provavelmente o banco de dados relacional mais usado no mundo ele tá em todo lugar se você tem dispositivos Smart com Android da vida os aplicativos rodando dentro certamente usam esse colar de três roteador da sua casa sua Smart TV ser o Alexa seu smartwatch tudo tem esse colite três qualquer aplicativo que precisa armazenar qualquer tipo

de da normalmente usa-se colete 3 a razão disso é por ser extremamente pequeno altamente eficiente flexível e portável o código fonte dele é em C super Limpo que pode ser facilmente portado para rodar em qualquer sistema operacional seja Lino que seja Mac e para qualquer arquitetura seja x86 no seu PC seja a arma na sua Smart TV ou console de videogame cabe tudo no único arquivo de c com poucos page de downs e oferece uma linguagem compatível com SQL é muito bem feito um dos melhores e mais úteis projetos de código aberto de todos os

tempos e se você é estudante de ser vale a pena explorar o código fonte não é tão difícil assim de entender isso me leva ao episódio onde eu mostrei o que seria uma introdução de como fazer uma linguagem similar SQL e eu usei justamente um trecho da gramática de SQL do ciclo light3 só que por baixo eu fiz ele acessar uma estrutura em memória de Java script poderia ser um arquivo DBF como de d-base e clipe que eu acabei de mostrar a diferença é que em vez de como apange replace use skip que eu mostrei

até agora poderíamos oferecer uma versão com select insertw update o formato DBF é usado até hoje em muitos lugares um pandas de Python tem capacidade de carregar e manipular DF a linguagem R para cálculo numérico também consegue entender DBF linguagens como JavaScript Java C Sharp todos têm bibliotecas que conseguem carregar DBF é um formato legal que ainda é usado por ser super simples e por ter sistemas legados em indústrias antigas e obviamente ninguém deveria iniciar um novo sistema dependente desse formato para isso existem coisas mais modernas Como o próprio ciclo Light 3 se colar de

três como the base ou clipper não depende de ter um servidor de rede para servir os dados e nem clientes complicados ele abre o arquivo e você manipula diretamente por isso é tão pequeno e eficiente existem opções para oferecer esse chocolate três em rede mas o foco dele sempre foi rodar localmente eu acho que exige menos de 1 MB de Ram para rodar talvez faixa de meio mega site O que é ridiculamente pequeno muitos programas de creeper dos anos 90 precisava mais que isso the base clipper Fox pro é o que chamamos da família de

linguagens x-base que suportam o formato de bf existe uma versão mais moderna de creeper de código aberto que é o Harbor isso é o forte o x Harbor eu não sei se alguém usa mas serviria para portar antigos programas x-base para rodar em plataformas mais modernas além de adicionar funcionalidades modernas como orientação objetos e capacidade de se conectar em bancos SQL modernos e de novo eu não recomendo começar nenhum novo projeto neles qualquer Python da vida conectando não se coloque 3 ou post que eles vai ser melhor tecnologias dos anos 80 eram limitados pelos poucos

recursos que a gente tinha os processadores eram super lentos comparados com hoje estamos falando de milhares de vezes mais lento os programas precisavam ser Super eficiente Porque qualquer operação fora do lugar roubava recursos escassos CPU seja de Ram eles precisa incomodar em menos de 640 kg de Ram em 15 MHz ou menos qualquer processador porcaria de hoje em dia tem dois ou mais núcleos cada um com pelo menos um GHz Olha a diferença Eu mencionei que o sistema de arquivos fat 16 do ms-dos da época só suportava arquivos de oito letras mais três de extensão

não tinha memória suficiente para suportar estruturas de dados maiores que isso e mais importante não tinha processamento sobrando para garantir a integridade dos dados coisas como calcular resto dos arquivos para os anos 80 seria muito pesado por isso disquetes em fato de 16 costumavam falhar arquivos ficavam corrompidos e dados se perdiam mesma coisa para o formato DBF era comum esses arquivos se romperem backup era essencial e backup naquela época era mandar fazer uma cópia uma disquete no fim do dia toda lojinha da esquina que tinha um programa incrível para controlar estoque fornecedores quantos a pagar

é receber coisas assim sabia que precisava fazer isso Fiz alguns programas desse tipo no começo dos anos no sicolete 3 o formato de arquivos reflete essa diferença para começar não é um arquivo apendione como DBF onde vai simplesmente gravando o registro na frente do outro e navegando via offset de endereços ele adota uma estrutura de árvores B uma bitre não só no índice Mas no banco de dados em si e aliás no caso você colete 3 tem um único arquivo que contém várias tabelas em vez de cada tabela tem um arquivo separado internamente não vai

alocando registros e sim páginas páginas são como Rangers ou intervalos de endereço por exemplo a página um pode ser do endereço 1 até 500 página 2 do endereço 501 até 1001 páginas contém registros ou linhas de uma tabela as páginas são organizadas numa árvore b e os registros São nas folhas lift dentro das páginas nos Episódios de árvore de sistemas de arquivos e de SQL eu falei sobre suas variantes como bip Plus que sistemas de arquivos modernos como os FS o butterfs utilizam tudo no seu sistema operacional é alguma variante de árvores em particular árvores

B por isso eu falei que era importante saber como funcionam E no caso do sicoot 3 tanto o banco de dados propriamente dito quanto seus índices são variantes de árvores B elas são muito eficientes vamos recapitular primeiro de tudo o b não é de binário a árvore binária é um tipo de árvore mas não é bitre o b não tem uma definição definitiva Mas pense como balanceada uma característica importante esse alto Balancear todos os nossos folhas têm a mesma profundidade Isso significa que não importa qual chave está procurando leva mais ou menos o mesmo tempo

para acessar qualquer nó isso é importante porque o tempo de sik ou procura no HD mecânico custa tempo uma árvore bem minimiza a quantidade de operações de procura árvores B tem alto fenalti ou seja são feitas para Cada nó Interno tem um número grande de nós filho que é a ordem da árvore isso ajudar armazenamento em disco porque uma grande porção dos dados ser escrito tudo numa única página o jeito antigo do DBF dialoga no registro de cada vez no fim é bem ineficiente e gera muita fragmentação alto fenalte significa que muitas Chaves podem ser

acessadas de uma só vez numa única operação de procura em disco É melhor pegar uma chave que não precisava junto do que ficar procurando aleatoriamente por todo o disco operações de inserção e deleção são muito eficientes o algoritmo que mantém a árvore balanceada e eu mostro uma versão disso no vídeo de árvore é Super eficiente quando uma nova chave é inserida ou apagada a árvore é rebalanceada para garantir a propriedade dos nossos folhas Tem sempre a mesma profundidade e é muito estável mesmo com a árvore crescendo muito um banco de dados discórdia três que é

super pequeno aguenta um arquivão que pode Teoricamente atingir até 280 terabytes operações que pegam vários registros de uma só vez Tipo um select asterisco da vida ficam mais eficientes pela propriedade de vários registros estarem juntos numa mesma página com poucas operações de disco dá para pegar todas elas ordenadas de uma só vez Então coisas como listagens e montar arquivos tende a ser muito mais eficiente do que não DBF antigo tudo que você pedir que seja ordenado e sequencial tende a ser eficiente pelas propriedades de páginas que eu expliquei eu sempre ouvi que ninguém deveria tentar

fazer um banco de dados do zero sem ter visto como um de verdade funciona por baixo e esse é um dos motivos operações em disco especialmente mecânico custam caro hoje custam caro mas nos anos 80 90 era absurdo um HD moderno como o meu Iron Wolf de 12 terabytes vem embutido com 256 MB de memória RAM não tinha PC nos anos 90 com tudo isso de Ram sem Cash as operações são mais custosas porque realmente precisa colocar a cabeça em cima do disco de verdade aqui eu tô especulando porque eu realmente não me lembro se

era bem esse o caso mas por exemplo eu reservaria espaço no começo do disco para colocar coisas como e os dados em si começariam a ser gravados depois Como se eu tivesse uma partição C mas perto do centro do disco físico onde as operações são mais rápidas do que perto das bordas dos discos daí numa partição B ficariam os dados em si aliás eu acho que é por isso que antigamente a gente particionava o HD no C2 pontos ficava o sistema operacional para garantir que no boot o disco trabalhe menos e seja mais rápido daí

os dados e programas ficam no D2 pontos mas longe do centro do disco mesmo a razão de hoje em dia deixarmos o boot não é SSD ou NV que é muito mais rápido mais sua biblioteca do estímulo colocamos num HD mecânico separado sempre é um trade off entre mais performance ou mais espaço e não só se colete três Claro qualquer banco de dados modernos uma postura e até bancos não relacionais com o mongo DB Fire base Dynamo Cassandra e não só bancos de dados como sistemas de arquivos como os ffutterfs que eu já mencionei Todos

usam alguma variante de árvore B exatamente por todas essas propriedades tudo que lida com gerenciamento de dados usa árvores B Olá aqui tá mais um longo DB não grava tudo em Jason eu mando Jason e ele me devolve Jason portanto Jason deve ser o formato mais eficiente não sério se você for bem iniciante eu deixo isso passar mas algum programador pensa assim realmente não entende nada de programação Jason é um formato de consumo não um formato de armazenamento é um formato de tradução para facilitar a vida mas é altamente ineficiente eu explico isso no episódio

que eu falo do código do Twitter primeiro não é Jason internamente os nossos filhos são gravados em bison ou baison que ele chama de bayner e Jason é um formato binário como protobofs do Google segundo é internamente organizado numa bibliostri ou árvore b-plus onde os valores propriamente dito são gravados direto nos nas folhas no fim da árvore diferente de uma árvore bem pura que só tem os ponteiros o objetivo primeiro episódio onde eu fiz um SQL em cima de uma rede java script foi para demonstrar que ter SQL não descreve nada de como é o

banco de dados por baixo mesma coisa no longo DB a linguagem e o formato de dados como Jason que se usa por cima não diz nada sobre como é a arquitetura por baixo tanto que um postres via SQL pode devolver os dados em formato Jason se você quiser é só uma tradução Jason ensina um significa nada para nenhum banco de dados ele só precisam escolher exportar ou importar dados nesse formato é só um formato como XML ou csv ou Excel todo formato de dados de consumo como esse vai exigir um passo de importação pro formato

interno binário de verdade ou exportação para esse formato então se você faz um select de asterisco da vida num banco primeiro ele vai puxar todos os registros no formato binário dele isso vai ocupar um X de memória daí você escolhe que quer em formato Jason então ele vai precisar de mais um tanto Y de memória maior do que X para fazer essa tradução é um processo de serialização e desodialização e sempre vai exigir o dobro de memória para ter essa conveniência por isso que comunicação de um serviço com outro serviço deveria ser sempre utilizando protocolos

binários compatíveis entre eles por exemplo protobuffs evitando ao máximo fazer tradução de dados especialmente em formato texto o formato de dados do si colete 3 não tem nenhuma relação com ele ter capacidade de receber comandos em SQL não existe um banco de dados SQL existem bancos de dados que entendem a linguagem SQL só isso internamente todos são implementados de formas diferentes para determinados cenários e casos de uso ou se cola de três é ótimo para usar no mais Smart TV já é um postal mongo DB da vida nem tanto eles foram feitos para rolar em

servidores existem até projetos para rodar circular de três em servidores mas de novo não foi feito para isso use a ferramenta certa no lugar certo só porque você consegue arrancar um parafuso da parede com Alica não quer dizer que deveria acha a da chave correta internamente todo o banco de dados vai ter um formato de arquivos de armazenamento como um DBF ou mais corretamente como formato de um círculo Light 3 e formato de arquivos de índice todos vão ser alguma variante de árvore B ou árvore B Plus Além disso temos coisas modernas no caso do

chicote 3 vai ter um outro arquivo com nome terminando em UOL de White a Red log isso é outra coisa que sistemas de arquivos como fat não tinham mas todo o sistema moderno como ntfs ou e xt4 tem um jornan para economizar recursos aquele comando replace que eu mostrei lá no começo com de base escreve por cima do registro antigo no arquivo DBF diretamente isso é péssimo porque Digamos que estamos fazendo uma atualização em massa em todos os registros do arquivo colocando o prefixo 9 em todo o telefone que é de São Paulo lá em

2012 agora Digamos que no meio dessa atualização acabou a luz e o computador rebuta fodeu isso era comum antigamente significava que Muito provavelmente o arquivo ficou no estado corrompido E eu perdi algum dado hoje em dia não se faz mais isso existem diversas estratégias mas o ciclo Light 3 escolheu um log de escrita para frente ou White a Red log ele primeiro escreve as modificações nesse arquivo separado de log depois que termina troca um pelo outro bem simplificado É como se eu tivesse um arquivo chamado contatos daí eu tenho uma cópia dele chamada contatos UOL

e as atualizações eu faço nesse segundo arquivo se tudo correu bem até o fim agora eu troco um arquivo pelo outro é um pouco mais avançado que isso mas só para ter na cabeça a ideia se acabar a luz e o segundo arquivo estragar ainda tem um original intacto Além disso você precisar fazer pesquisas eu posso pesquisar no original enquanto a transação não acaba no segundo arquivo em vez de ficar travado tendo que esperar até todas as operações acabarem todo o banco de dados tem algum mecanismo desse tipo mais sofisticado para ter o menor tempo

de trava quanto possível e garantir que nenhum dado vai ser corrompido é um tipo de mecanismo de cal ou como o sistema de arquivos Butter é fezes também tem Linux por isso que é bem incomum hoje em dia perder dados mesmo o Windows tem ntfs que protege razoavelmente bem Qualquer Linux mais vagabundo usa pelo menos estes T4 que tem suporte a Journey para perder dados hoje você precisa estar usando um hardware muito do vagabundo como um SD Card de câmera SD Card é um hardware de armazenamento que foi feito para ter grande capacidade e ser

super barato ele foi feito para tirar foto gravar vídeo logo em seguida transferir para um computador não foi feito para deixar lá guardado para sempre não é confiável e podemos perder dados do nada Especialmente nos modelos mais baratos ssds baratos de Aliexpress a mesma coisa mas nesse caso porque são fraudes mesmo fabricados para falhar cuidado com isso outra característica que bancos relacionais trouxeram foi esse conceito de transação e esse de atomicidade nas operações ou todas acabam com sucesso ou nenhum acaba e de consistência por exemplo regras de honestidade estrangeiras e tudo mais os dados precisam

sempre seguir essas regras sem exceção isolamento ou seja se tem um conjunto de transações que rolem paralelo o resultado tem que ser o mesmo se eles tivessem rodado sequencialmente o banco não pode ficar no estado inconsistente e durabilidade que se a transação diz que gravou o dado podemos acreditar que realmente está fisicamente no disco caso um erro aconteça com uma famosa falta de luz o banco precisa voltar para o Último estado consistente conhecido nunca pode continuar operando no estado inconsistente cada banco implementa isso de formas diferentes Mas no geral significa que podemos confiar nos dados

num banco de dados relacional sejam mais rico ou oposto ou se conserva no geral eles implementam bem essas características mesmo o pequeno circular de três faz isso um dos jeitos mais Tosco é simplesmente bloquear o arquivo todo para cada operação esperar completar com sucesso e só ir liberar para outras operações mas claro isso seria altamente ineficiente mas era assim que bancos de dados x base DB funcionavam em rede nos anos 90 quando começamos a usar placas de rede em ms-dos e fazer pequenas redes usando ferramentas da antiga novel ou Windows 3.1 for work groups ou

venerado o S2 da IBM na prática um computador era elegido como um servidor de arquivos e esses arquivos dbfmdx eram compartilhados em rede e todos os outros computadores na rede enxergavam os mesmos arquivos cada computador tinha a mesma versão do programa indebase ou clipper ou Fox pro instalado se algum tivesse uma versão mais antiga era caos a consistência as regras dependiam totalmente da versão do programa instalado em cada máquina atomicidade era mais ou menos garantida pelo sistema de lock quando um programa quisesse inserir um registro novo ele travava o acesso aquele arquivo se o segundo

computador tentasse ler recebia um erro que o arquivo estava ocupado e precisava esperar isso nem sempre funcionava isso o arquivo DBF sozinho numa única máquina tem dia se corromper porque não existia nenhum sistema de como journalds imagine em rede corromper arquivos era rotina Experimente esquecer de fazer backup no fim do dia certeza que no dia seguinte ia dar pau e corromper alguma coisa sistemas de arquivos em rede como novela Era uma gambiarra feita em cima do doss com tecnologia super imaturas hoje usamos Protocolos de internet como TCP e p mas naquela época usavam os protocolos

mais rudimentares como ipxspx e net Bills da Microsoft verdadeiras porcarias e mesmo a tecnologia de redes em si hoje usamos a internet de um gigabit para cima antigamente era um cabos coaxiais que nem de TV a cabo que Maré malha faziam 10 megabits perdia um pacotes corrompiam dados e assim vai com a migração de ms-dos para Windows e dar arquitetura de 16 bits para 32 bits ganhamos até 4 GB de Ram para trabalhar sem precisar fazer gambiarras de memória em dólares como eu explico no episódio do 640 kg e com isso em vez de cada

programa em cada máquina da rede tentar acessar os arquivos de dados eles passaram a conversar com o software servidor dessa forma só um software tinha acesso direto aos arquivos e todos os outros programas clientes conversavam com esse servidor usando algum protocolo com alguma linguagem no caso o SQL Essa foi a era de programas feitos em visual base que ou Delphi conversando com bancos de dados servidores mais modernos Como surge que tinha tsql ou orco que tinha plsql ou alguns mais de nicho como Inter base da borland que era o padrão para quem usava Delphi em

vez de cada Programa cliente ter que controlar a integridade dos arquivos melhor terceirizar isso para um servidor os clientes Só falam ô grava isso para mim ou ou pesquisa isso para mim e o servidor se vira E só aumentou muito não só escalabilidade mas também é estabilidade se um cliente Manda uma operação não suportada o servidor pode só recusar em vez de tentar executar e corromper arquivos se colete três oficialmente não tem um servidor mas tem gente tentando fazer um sei lá porque projeto chamado Valentina DB que faz isso eu não vejo nenhuma vantagem se

você quer um banco de dados SQL formato cliente servidor use um de verdade que é maduro com mais seco Ou postics use esse colete 3 para programas que precisam de dados localmente como seu roteador de Internet relógio que eu já dei de exemplo quando temos o formato de um servidor temos algumas vantagens e algumas desvantagens A primeira é que a velocidade vai depender da qualidade da rede tudo que roda localmente sempre é mais rápido em rede você precisa pegar o resultado quebrar em pacotes rotear esses pacotes e recebendo processando um buffer e só aí vai

ter os dados podemos escolher e recebendo e já processando os dados localmente ou podemos escolher esperar receber a resposta toda e só depois fazer alguma coisa é a diferença de receber tudo de uma vez ou usar técnicas de streaming E aí depende da sua pesquisa se for tosca e mal feita e mandar tipo select de asterisco para uma tabela de 10 GB sem usar streaming boa sorte vai o toda a memória da sua máquina e mais o Suape em disco Isso é o que iniciantes tem mais dificuldade de entender os dados que pedem precisam ir

para algum lugar nada é de graça em computação o trabalho principal de um programador é justamente administrar os recursos da máquina da maneira mais eficiente possível por exemplo Digamos que eu preciso montar um relatório em PDF de todas as vendas do mês vou fazer tipo um select asterisco from hordas com arco e Jet maior quedate menos 30 essa é uma pesquisa rudimentar que filtra todas as ordens criadas nos últimos 30 dias faz de conta que vai devolver mais 500 ordens Digamos que cada uma dessas linhas consuma 500 bites Só meio quilo bike se eu puxar

tudo de uma vez do banco e colocar numa Rei memória vai ocupar 250 MB é bastante coisa daí abrimos uma biblioteca qualquer pra montar PDF e converter essas linhas em um documento PDF em memória para simplificar o exemplo Digamos que cada linha no pdf também use 500 B significa que no fim da operação eu vou estar consumindo 500 na memória meio Gigabyte metade com os dados que vieram do banco e metade com PDF e qual o jeito certo depende Talvez seja esse mesmo existem técnicas se quiser otimizar um dos jeitos é escolher uma biblioteca de

PDF que suporte escrever direto para o disco em vez de acumular tudo em memória por exemplo em Java até a biblioteca PDF box da Apache podemos ir salvando incrementalmente uma página de cada vez por disco Digamos que cada página tenha 20 ordens Então eu só vou precisar de aproximadamente 10 megabytes na memória por vez Além disso podemos ir recebendo uma linha de cada vez do banco e montar uma linha no pdf e descartar essa memória daí eu recebo a próxima linha e faça a mesma coisa sem acumular tudo em resumo significa que de memória de

trabalho precisaria no máximo tem uns 10 megabytes para montar uma página de PDF e mais meio megabyte por linha que eu recebo do servidor de banco de dados um total de 10 mega e meio aí não importa o relatório vai ter sem ordens ou Mil ordens sempre eu vou usar o máximo de mega e meio de cada vez e não 500 mb para 500 ordens ou 1 GB se for meio de natal e tiver mil ordens Esse é o seu trabalho com o programador encontrar o teto máximo que realmente precisa e limitar o uso de

recursos só assim é possível escalar o jeito amador é ir usando cada vez mais memória a medida que os dados vão aumentando de volume sempre pensa em jeitos de usar um teto fixo de memória e processamento Independente de quantos dados vai processar quando falamos que é importante entender SQL Direito primeiro é para aprender a fazer queres ou pesquisas selects que devolvam a menor quantidade de dados quanto possível porque cada dado Extra que vier e não usar vai desperdiçar memória e processamento mas também precisamos entender algumas noções como se vamos escrever ou atualizar dados é melhor

mandar os comandos todos de uma só vez do que mandar um de cada vez espera um por um terminar e confirmar antes de mandar o próximo aquele exemplo que eu falei de adicionar um número 9 na frente de todo o número de telefone de São Paulo em 2012 Digamos que tenha 100 mil usuários na minha tabela o jeito mais Tosco possível fazer um programa que conecta no banco e primeiro faz um select asterisco e devolve todo mundo para o seu programa de novo se cada registro ocupa meio kilobyte você deu asterisco Mandou voltar todos os

campos da tabela São 50 mil megabytes 50 gigabytes de dados estão entendendo porque isso de puxar tudo para memória é ruim é o jeito mais fácil de pensar primeiro mas é o pior jeito Digamos que você tá no servidor parrudo na Amazon PC igual o meu com 64 GB e depois de um bom tempo carregou a tabela inteira e memória agora você faz um loop nessa tabela e manda dar um update no servidor pra cada registro uma update é uma transação separada 100.000 vezes 100 updates semi alterações individuais de índices 100.000 comentes 100.000 esperas de

retorno ok do Servidor lá se vão mais algumas horas esperando e qual é o jeito certo você não ficou óbvio não precisa dar select de nada é só fazer um único todo mundo de update algo como update 7 telefone igual 9 + telefone o arcity igual São Paulo and de blá blá um único comando que vai mexer em todos os milhares de registros tudo de uma só vez como a única conexão de rede um único comitil uma única espera não precisa puxar todo mundo para memória depois fazer update 1 a 1 separado Entenda esse conceito

a melhor operação traz zero dados do Servidor e opera tudo lá do jeito Tosco Programa cliente digamos só aplicação web ou mobile mandou individualmente um comando de update para cada usuários esperou a resposta e mandou o próximo 100 mil vezes do jeito certo seu programa só se conectou uma vez e só mandou um comando e afetou os mesmos 100.000 registros e a diferença de tempo aqui vai ser na ordem de centenas ou milhares de vezes mais rápido e usando ordens de grandeza menos recursos de memória e processamento isso é entender SQL programadores iniciantes aprendendo Hoje

não tem desculpa o pessoal das antigas que fazia DBZ eu até consigo entender porque naquele formato rudimentar de DBF não tinha outra forma tinha que iniciar um loop do Will fazer uma condição com if E aí fazer replace no registro atual da skip para pular para o próximo pedir 100.000 vezes não tinha um servidor que fazia isso sozinho pra gente mas pelo menos naquela época tava tudo rodando localmente na mesma máquina modificando diretamente o arquivo é o que o servidor de SQL vai ter que fazer no lado dele mas um cliente de banco de dados

não tem que fazer loop nenhum se comunicando com um servidor registro a Registro quase nunca se você tem um loop para processar dados vídeos dos servidor de banco de dados provavelmente tá errado no mínimo é um red Flag que precisa ser revisto pelo menos lembre disso como regras se tem um loop pode estar errado pense de novo outra coisa que o formato antigo não permitia fazer você tem que aprender como fazer não é SQL são constranges as Tais regras de consistência por exemplo um campo que nunca pode ter valor vazio ou um campo que é

uma chave estrangeira que é um campo uma tabela com aí de primário de Outro registro e outra tabela Chaves estrangeiras garante que você está escrevendo aí diz que realmente existem e no formato DBF não existia isso você como programador precisava garantir essas regras manualmente no código com um monte de IFES para lá e para cá em SQL se tem um monte de gifs provavelmente deveriam ser construintes no mundo moderno de clientes servidor significa que muitas vezes essas regras vão ser duplicadas no cliente para poder mostrar para o usuário que ele digitou dados em vários por

exemplo e no servidor para garantir que nas tabelas só tenha dados realmente corretos muita gente acha essa redundância ruim mas eu acho o contrário a gente tem nada pior que dado inconsistente é melhor checar duas vezes do que não checar cheias de consistência que só existem e no lado do banco de dados aceita tudo e não checa nada é a maior porcaria de todas as porcarias sempre desses bancos de dados estão em estado inconsistente e sempre vai dar problema cria a tabela no esquema com as Friends e validações todas validação de tipos de dados validação

de tamanho validação se pode ser vazio ou não validação de Chaves tudo daí faça uma classe do lado cliente que reflete as tabelas usando o RM como hypernate em Java ou o modo em circolagem script ou modo de jumping não importa repita as mesmas validações daí faça um componente em react para o front-end repita as mesmas validações sim repita três vezes e faça testes unitários para cada uma delas e teste de integração que chegue todos ao mesmo tempo esse é o seu trabalho é que nem médico achar que lava a mão toda hora eles a

cirurgia perde de tempo lave de novo Beleza tem que estudar skele não só saber se em táxi de SQL mas o uso de recursos e processamento no servidor e como otimizar nenhum RM biblioteca ou Framework vai fazer isso para você na verdade é muito fácil fazer encerrado assumindo que o Framework vai cuidar de tudo sozinho muitos tutoriais no intuito de serem didáticos vão te ensinar o jeito menos eficiente porque o jeito mais eficiente costuma ser mais difícil de explicar E demonstrar e quando você testa com poucos registros 10 100 mil não faz nenhuma diferença só

quando realmente coloca em produção que vai entender o impacto Essa é a diferença de crianças e adultos quem já teve experiência de perder dados de cliente ou ficar tudo lento que a loja para de funcionar só aí que entende Ah eu tava entendendo errado pois é tente evitar ter que chegar nesse ponto nem todo mundo pensei enfiar o dedo na tomada para saber que toma choque num sistema grande de verdade numa equipe com vários desenvolvedores é difícil de checar todo o código foi bem feito ou não e mesmo sendo experiente na pressão alguém deixa passar

um código que vai usar a memória sem precisar ou que vai deixar tudo lento Porque botou um loop no lugar que não deveria por isso que todo sistema recebem produção precisa ser monitorado existem diversos ferramentas de monitoramento seja usando os antigos nagios ou usa bicks ou serviços mais modernos como spank datadog é pior Angel monitor e vários outros não tem desculpa de não usar pelo menos um honestamente eu não sei dizer qual é o melhor hoje em dia mas na dúvida eu sempre usei e continuo recomendando no mínimo instalar o newer qrpm alguns deles são

passivos Como os antigos najas ou logiteio porque medem coisas fora da aplicação como uso de CPU memória análise os arquivos de log mas os melhores exigem que você instale uma biblioteca que haja como um agente dentro da aplicação como tem acesso a memória da aplicação dá para fazer análises muito melhores sem entrar em detalhes podemos avaliar logo depois de um depoimento de produção e ver se o uso de memória Aumentou e fica constante por exemplo ou você continua lentamente subindo até uma hora cachear ou podemos monitorar uma campanha de marketing entra no ar e vem

um volume maior de tráfego o aumento do uso de recursos está proporcional mais importante podemos avaliar quais partes do código costumam consumir mais recursos com isso podemos focar em melhorias bem mais precisas só nas partes que realmente precisa em vez de ficar no achismo de mexer no código todo sem saber quais reais impactos está causando depois que uma aplicação entre produção Toda a manutenção deve ser feita ao redor de métricas sempre medir o antes e o depois seu objetivo for construir menos infraestrutura sempre atacar os principais ofensores segundo as métricas se você não consegue medir

certamente não consegue consertar no lado de banco de dados nenhum consegue crescer infinitamente Como eu disse Por Causa Geral de empresas pequenas ou médias leva muito tempo para começar a entrar no território de Big Data dezenas centenas de terabytes de dados um banco de dados relacionados tradicional costuma ter os seguintes problemas escalabilidade Primeiro as tabelas simplesmente estão grandes demais e quando eu digo grandes eu quero dizer centenas de gigabytes ou terabytes por mais que você tenha índices lembro que eu mostrei no caso do DBF seus índices ndx o arquivo de índice vai crescendo também quanto

mais dados for inserindo maior vai ficando seus índices também vai chegar uma hora de pesquisar índices estão pesados vai excelente a primeira estratégia para lidar com esse problema se chama arquivamento o certo é ter ou um segundo servidor de banco de dados usados só para pesquisa e relatórios mas fora do acesso para usuários Digamos que você tenha um e-commerce se você tiver sucesso e vender muito sua tabela de ordem vai ter milhões de vendas Mas pensa para que que serve guarda dados de ordens antigas ordens de usuários que cancelaram contas ou que não entram faz

muito tempo morra para um segundo banco de dados assim você tem um banco de dados com dados que realmente seus usuários precisam mas sem os dados que ninguém nunca acessa digamos que sua empresa é uma multinacional com dezenas de filiais dezenas de de funcionários e seu sistema controla tudo de RH folha de pagamento benefícios fés documentação e tudo mais para que tem dados de funcionários de cinco anos atrás arquive mova para um segundo banco de dados ou morra para um backup frio mesmo como fita ou para uma WS glauncher da vida que é tipo um

S3 mais barato em qualquer empresa média ou grande com sistemas de controle internos vai ter tabelas com dados antigos que não precisam estar lá é uma prática que de tempos em tempos todo ano talvez todos semestre se faça essa manutenção de limpeza arquivar mover dados mortos para outro lugar que se acessa menos não é apagar é mover nunca é uma boa ideia apagar nada nunca se sabe quando vai precisar especialmente sua área jurídica mantenha dados no mínimo em backup por no mínimo cinco anos por causa da Lei A grande maioria das Pequenas Empresas peca em

você quer ter um backup que funciona quanto mais se preocupar com o arquivamento de novo não é para pequenos isso pequenos tem que se preocupar com o básico tem um backup para começar mas aí começamos a entrar no território de unicórnios o Uber Netflix iFood MercadoLivre e várias técnicas startups que geram toneladas de dados Digamos que é um iFood da vida não só vai ter informações básicas com cadastro de usuário e tabela de pedido simples mas vai ter dados como quem foi o motoqueiro que fez cada entrega que rotas usou que contatos foram realizados durante

o percurso o usuário abriu o chat o que que ele falou é uma granularidade volume muito maior de dados cada pequeno pedido já era megabytes de dados para depois terem usados para inteligência métricas de como melhorar a experiência e tudo mais empresas assim geram gigabytes de dados por dia o problema não é só o volume de dados mas a velocidade em que são gerados aqui é o território de dataware house data lakes e coisas assim em nenhuma dessas empresas vai ter um único servidor de banco de dados contudo sempre vai ter múltiplos bancos de dados

e certamente de vários tipos diferentes para cada caso de uso diferente simplificando bastante do lado do usuário que usa o app faz pedidos acompanha entrega e tudo mais cada um desses usuários vai gerar dezenas de requisições para os servidores de um iFood ou Uber da vida as pesquisas sendo feitas precisam ser rápidas estamos falando de centenas de milhares de usuários acessando a plataforma ao mesmo tempo por mais parrudo que seja um servidor nenhum aguentaria precisa distribuir essa carga em múltiplos servidores quando se instala múltiplos servidores de aplicação eles não podem todos acessar um único servidor

de banco de dados isso iria gerar uma fila enorme e muita espera muita latência entre requisições o problema de banco de dados relacionais com o posts ou se conserva é que foram feitos Originalmente para funcionar num único servidor parrudo a gente escalava o serviço melhorando o hardware da máquina colocando mais rã ou colocando uma CPU melhor eles não foram pensados para funcionar em múltiplos servidores hoje em dia Fazemos um meio do caminho o maior volume de operações costuma ser pesquisa como pesquisa de cardápio enquanto faz isso não tá gravando nada só pesquisando todos os serviços

de banco de dados SAS modernos conseguem criar servidores réplica cópia da original automaticamente assim o servidores de aplicação web consegue fazer a pesquisa em qualquer uma das réplicas evitando que se cria um gargalo só em um mais do que isso hoje em dia um servidor de aplicação vai primeiro fazer a pesquisa no servidor de Cash como um cash ou redisse se usar um aws temos Amazon elast Cash que é basicamente bem cash ou Hibisco no serviço a aplicação primeiro checa Você tem o cardápio do Restaurante no cash se não tiver aí pesquisa no banco de

dados grava do Cash e serve de volta para o usuário muito da carga de pesquisa cai em cima de alguma solução de Cash é impossível criar serviços grandes como um iFood ou Mercado Livre sem ter um volume grande de Cash temos dois problemas com isso O primeiro é que apesar de ser razoavelmente simples de criar servidores de réplica é difícil de ter múltiplos servidores que aguentem escritas operações como insert update ou de Elite acontece no único servidor principal todas as outras réplicas costumam ser o idioma somente de leitura existe um pequeno delay uma pequena latência

entre a escrita completar no servidor principal e as réplicas serem atualizadas mas isso costuma valer a pena todo e-commerce da vida tem essa arquitetura de servidor de banco de dados mestre principal prescritas várias réplicas somente de leitura e muito Cash aliado a uma estratégia de Jobs assíncronos como uma pasta da vida estratégias que eu já expliquei no episódio do ingresso.com do Twitch e do Twitter então depois revejam mas mesmo assim ainda tem casos especiais Digamos que temos um serviço de analíticos como o Google analíticos capturando cada visualização cada clique toda a operação que os usuários

estão fazendo em diversos apps em diversos sites para gerar monitoramento em tempo real relatórios periódicos com informações de cada usuário ou Imagine que fazemos o software que captura informações vindas de Apple watch ou Galaxy watch informações de batimentos cardíacos que cada usuário te manda uma vez a cada dois minutos é pois Samsung tem milhões de usuários conseguem imaginar esse volume de dados ou imagine uma corretora de criptomoedas como uma bainnense como milhares de transações acontecendo a cada minuto milhares de pessoas comprando e vendendo sem parar ou imagine um servidor de games como Collor Duty ou

fortnite onde se captura informações de cada ação de cada jogador cada movimento cada tiro cada pontuação jogadores do mundo inteiro estamos falando de gigabytes sendo gerados por minuto é muito dado e em cima desses dados queremos gerar compilados como o relatório da sua saúde na última hora ou nas últimas 24 horas ou do mês pra isso tem que ordenar agrupar processar e sumirizar gigabytes de dados recebidos por cada usuário muito pesado e não por acaso essa discussão começou a surgir no fim dos anos 2000 justamente quando redes sociais como Facebook Twitter estavam atingindo proporções que

nenhuma outra plataforma nunca tinha atingido até aquele ponto sem contar o advento de mobile e da popularização de games online nessas circunstâncias de fato o esquema de banco de dados relacionais atinge seus limites as pesquisas ficam lentas por volume absurdo de dados pior as escritas ficam absurdamente lentas em parte por causa das garantias que Estávamos acostumados a ter como durabilidade a ideia de que se mandarmos um servidor gravar uma linha e ele diz ok significa que aquela linha garantidamente está no disco nesse cenário de Big Data essa garantia se torna um problema quando falamos em

Big Data precisamos lidar com premissas diferentes num banco se assumir uma linha do seu extrato é um grande problema literalmente a conta não vai fechar vai faltar um depósito vai faltar um pagamento dinheiro vai sumir Pior se uma linha For duplicada mesma coisa não e-commerce mesma coisa num sistema como da Receita Federal todos precisam de garantias na consistência e integridade dos dados por isso existe e sempre vai existir um lugar para bancos de dados com características que ora com se conserva ou post eles oferecem hoje mas para certos tipos de dados como analíticos como dados

de batimentos cardíacos como dados de jogos online mesmo se você perder ou duplicar uma linha dessa Qual que é o impacto é baixo ou no caso geral nenhum Impacto estamos dentro de uma margem de erro no fim do dia você não tá interessado em cada clique individual no seu site estamos interessados na quantidade geral por dia por semana por mês não damos interessados no batimento exato de 5 minutos atrás mas sim na média por hora na média durante um exercício ou na média durante o sono e assim por diante é por isso que a partir

do começo dos anos 2010 começaram a surge bancos de dados não relacionais não bancos de dados criados para responder situações diferentes em particular de Big Data onde queremos lidar com séries de dados consolidados onde velocidade de escrita e baixa latência tem prioridade sobre consistência queremos poder escrever em múltiplos servidores ao mesmo tempo mesmo que durante algum período de tempos dados ficam ligeiramente inconsistentes o problema é como distribuir a carga tanto de processamento para pesquisa quanto para escrita e Como dividir os dados entre múltiplos servidores diferentes para permitir escalabilidade recapitulando bancos de dados relacionais funcionam muito

bem no único servidor oferecendo as garantias esse de diatonicidade consistência isolamento e durabilidade que todos nós gostamos tem opções para escalaria réplica somente de leitura e até certo ponto replicação bidirecional que é sempre complicado mas para situações de Big Data e volumes gigantes de escrita começa a se tornar uma tarefa complicada chata e com poucas opções não tem como no ciclo sem mencionar o famoso teorema Cap proposto por Eric bruel no ano 2000 foi um divisor de águas no estudo de sistemas distribuídos e provavelmente você vai aprender no curso de Ciências da Computação mas em

resumo ele propõe que bancos de dados verdadeiramente distribuídos Ou seja que rodam em múltiplos servidores ou múltiplos nós de um cluster no máximo satisfazem duas de três propriedades consistência a vela billette ou disponibilidade e partition ou tolerância à partição ou temos consistência e durabilidade mas o sistema não tolera partições ou seja alguns nós do Câncer podem ficar offline do nada e isso não é legal porque não é impossível um servidor dar problemas ou mesmo temos que tirar um deles do ar pra manutenção então queremos consistência e tolerância à partição mas aí temos baixa disponibilidade ou

vamos ter o ideal disponibilidade de tolerância à partição mas teremos baixa consistência ou que chamamos de consistência eventual onde um servidor ligeiro período de tempo pode não ter os mesmos dados que os outros servidores cap é um teorema e não uma teoria ou seja não é uma lei quando estudar vai encontrar que nem todo mundo concorda com todos os argumentos em particular porque os termos consistência disponibilidade de tolerância à partição podem ser facilmente mal interpretados não tem uma definição muito exata para cada coisa e todo mundo sabe o que acontece quando termos ficam abertos a

interpretação ninguém se entende E isso acontece com frequência Porque na minha cabeça eu quero falar de consistência Mas você tá entendendo como integridade e uma coisa diferente da outra daí tem o problema da natureza binária é um dos poucos lugares que de fato não podemos levar ao pé da letra que só podemos escolher duas propriedades de três no caso de termos disponibilidade de tolerância não significa que não vamos ter nenhuma consistência Depende se precisamos de consistência forte onde é obrigatório que todas as réplicas sempre tenham exatamente o mesmo dado correto podemos ter uma consistência fraca

eventual onde durante alguns segundos os dados diferem entre os servidores de novo num banco não podemos ter um saldo recarregar um navegador e aparecer outro saldo mas no exemplo dos batimentos cardíacos se faltar um batimento durante um minuto não vai ser um problema não quer dizer que você teve uma parada cardíaca do nada outra coisa é tolerância à partição de novo pense num data center onde um grande serviço pode ter um banco distribuído em múltiplos data center uma duas é de servidores em Nova York outra dúzia de servidores em Londres todos sincronizados mas aí temos

uma pane na internet entre eles um link submarino deu Pane caiu a fibra ótica É raro acontecer mas acontece e o sistema tem que saber o que fazer quando acontecer ou seja ser tolerante a essa partição da rede o problema é que isso realmente é muito raro de acontecer nossa infraestrutura dos anos 2020 é mil vezes melhor que nos anos 2000 hardware redes em geral é muito mais estável então nosso sistema não precisam ser tão agressivos na preparação para uma situação tão Rara Talvez seja melhor ser otimizado considerando o caso que não vai acontecer e

colocar a estratégia de degradação Graciosa caso aconteça como simplesmente uma página de aguarde alguns segundos mesmo se tiver pane na rede hoje em dia se recupere em poucos minutos antigamente poderia levar horas ou Dias Essas são algumas das considerações ao se discutir o teorema Cap na prática vamos lidar com alguma estratégia de charge e alguma estratégia de replicação de dados replicação é como acontece com o banco de dados relacional onde podemos adicionar nós na rede e eles vão receber uma cópia dos dados daí cada servidor vai ficar idêntico ao outro fornecendo redundância e possibilitando dividir

a carga dos usuários para mais servidores no caso de banco de dados relacional por causa da característica de consistência forte ficamos limitados Na quantidade de servidores que podemos ter para escrita num ciclo com consistência eventual qualquer todos nós pode ser usado para escrita mas vai levar um tempo para replicar os dados para os outros servidores a consistência vai existir Mas vai ser eventual ou seja eventualmente vai estar tudo consistente na real bancos de dados no ciclo como Cassandra ou Dynamo tem como configurar que nível de consistência queremos ter mais forte ou mais fraco podemos configurar

isso dependendo das necessidades uma coisa é um pequeno câncer de três servidores de caçando tudo no mesmo Data Center na mesma rede outra coisa são múltiplos Clans de dúzias de servidores em vários data centenas diferentes como é a operação do tamanho de uma Netflix bancos como Cassandra ou Dynamo foram feitos mais para situações onde precisamos funcionar em múltiplos datacentes dividido em regiões geográficas diferentes um no Japão outro na Europa outro na América e todos os servidores de todos os clusters sincronizando entre si não é uma situação que vamos encontrar todo dia para a maioria das

empresas médias de lidar com uma infraestrutura dessas do zero o mais prático seria usar um Dynamo DB da WS como tudo da WS eles gerenciam a maior parte dessa complexidade podemos só usar Claro que por causa disso o custo por transação é bem mais caro mas esse é o traidor precisa ser estudado ou vamos ter que investir em contratar pessoal especializado em infraestrutura para ficar 24 por 7 lidando com hardware Bear metal não data center ambos Cassandra e Diamond oferecem capacidades de particionamento e replicação mongo DB também tem isso mas ele chama de Charger e

reaplicar sets O que buscamos é a capacidade de conseguir particionar os dados em múltiplos servidores de forma balanceada e de ter replicação entre alguns desses servidores para ter redundância se um deles tiver uma Pane e cair tem outra cópia Idêntica para continuar servindo os mesmos dados é muito complexo para tentar detalhar em um vídeo mas eu queria que vocês pelo menos soubessem que isso existe para depois saber onde procurar para agora é interessante conhecer o último conceito aí diz voltando para o exemplo lá do começo a tabela de contatos feito em DF com the base

Lembra que eu falei que mesmo se eu fizer o índice de nome precisaria procurar pelo nome completo para achar hoje em dia em qualquer banco de dados todos oferecem alguma forma de pesquisar parcialmente ou palavras que somam parecido é um que um elástico search Soler ou se cursos de full text search de um post e outros bancos de dados oferecem é um índice diferente para esse tipo de pesquisa em particular eu expliquei isso no episódio do Twitter depois vejam antigamente nos anos 80 não tínhamos o poder de processamento para fazer coisas desse tipo em vez

de tentar lembrar se Brian Russell tem dois s ou dois l e muitos casos era mais fácil lembrar o código dele o ID por isso toda a tabela a gente se acostuma a colocar esse código assim como todo pedido de compra tem um código assim como todo o indivíduo nesse país é um CPF toda a linha numa tabela é um código numérico que usamos como uma chave primária ou no caso de bancos profissionais usamos para fazer uma linha em uma tabela referencial uma linha em outra tabela e chamamos esses I dias de Chaves estrangeiras porque

ela é estrangeira a tabela o jeito considerado errado hoje principalmente em códigos que Vamos divulgar para os usuários é fazer essa chave primária ser um número alto incremental ou seja começamos de um e incrementando próximo a linha sendo dois linha seguinte sendo três e assim por diante um erro de segurança que foi muito comum antigamente era ter uma aplicação web onde a URL mostra esse código por exemplo Digamos que tivesse mercadolivre.com/eusles/1 que é URL para página com os dados cadastrais de um usuário um sistema bem feito quando o usuário faz login eu guardo dele na

sessão quando ele navega para outras páginas privadas checamos com aid na sessão Antes de mostrar a informação se ele tentar acessar o URL que se der de outros usuário conseguimos invalidar o pedido e devolver um erro 403 não permitido esse seria o certo mas num sistema grande alguém pode deixar passar um bug e daí alguém de fora percebendo que estão usando aí diz alto incrementais e o dele aí de digamos mil óbvio que significa que tem usuários abaixo de 1000 e alguns acima e ele vai começar a tentar forçar e diz até alguma página abrir

na conta de outros usuário o certo não tem esse bug mas também não é legal oferecer informação de graça para estranhos com mais existência de outros usuários com AIDS fáceis de achar o ideal é usar um número aleatório gigante um campo de inteiro de 32 bits pode conter números de 0 até mais de 4 bilhões Mas se for inteiro de 64 bits estamos na ordem de 18 milhões de trilhões é muito número por isso não precisamos usar números sequenciais Auto incrementais os inúmeros aleatórios vai ser perto de impossível tentar adivinhar o agir de alguém para

isso usamos funções geradores de números como yu-wides nem precisamos usar o número inteiro que ele gera basta truncar e pegar um pedaço e as chances de colisão ou seja de escolher um número que já existe na sua tabela vai ser hiper baixo e como o certo é de Campos de chave primária com constrange de unicidade ele não vai deixar inserir um ID duplicado existem dezenas de estratégias para gerar números aleatórios para ir disso vale a pena parar para pesquisar e evitar números sequenciais chamamos isso de Chaves surregadas não é nenhuma lei Mas é uma boa

prática para tabelas internas cujas você nunca vai mostrar em público aí meio que tanto faz eu expliquei isso porque em Sistemas distribuídos temos o problema de balancear dados entre diferentes servidores quando replicamos dados estamos fazendo uma cópia dos dados de um servidor para outro para servir de redundância mas num sistema grande distribuído Queremos dividir o processamento e isso exige que algum servidores vão ter dados que outros servidores não vão ter deixa eu dar um exemplo besta Digamos que eu trabalho na Receita Federal fazer um único banco de dados com todos os impostos de renda de

todas as pessoas empresas num único banco de dados é bem pesado Ainda mais se tiver informação Histórica de todo mundo das últimas décadas um ingênuo de lidar com isso é manualmente dividir os dados por exemplo eu posso fazer um servidor com dados da região Sudeste outros servidor só para região sul outros só para região Nordeste assim por diante o problema que um servidor vai continuar tendo mais volume de dados que o outro não vai ser balanceado rapidamente da região Sudeste vai precisar dividir daí teremos que fazer um servidor só para São Paulo separado mas mesmo

assim o volume só de São Paulo sempre vai ser muito maior que tudo então vamos dividir pelo menos a cidade de São Paulo num único servidor sozinho tá vendo trampo ficar tentando dividir os dados assim manualmente vai ser horrível e pior ainda por software teremos que fazer algo como isso São Paulo procura no servidor x ou infeliz região Nordeste procura no servidor Y isso rapidamente fica caótico existe uma solução melhor antes vamos ver um outro jeito um gelo de balanceamento Alguém poderia pensar Hum E se não olharmos para os dados esquece de religião ou estado

vamos olhar só para os AIDS nesse caso Digamos que os que são médicos e sequenciais exatamente o que diz para não fazer daí temos três servidores como chamar de a b e c e 12 itens na tabela com aid de 1 a 12 para simplificar como que eu divido esses 12 itens entre os três servidores fácil que tal usarmos o módulo do id lembra a ideia de modo no caso faremos modo 3 modo é quando você pega o restante da divisão de um número por outro por exemplo um módulo de três seria um dois modos

de três seria dois três modos de Três É zero porque três dividido por 3 dá 1 E sobra zero interessante é acima disso quatro dividido por 3 é 1 e sobra um então o módulo é um cinco dividido por 3 é um E sobra dois então o modo é dois mas seis dividido por 3 é exato 2 e sobra zero o módulo é Zero qualquer número módulo três vai ser um número de 0 a 2 sempre vai rotacionando estabelecendo arbitrariamente o servidor Ah é zero B1 e c é 2 sabemos como dividir cada uma das

12 linhas em cada um dos três dores sacaram então o servidor a teremos os itens quais disso 147,10 no servidor B teremos os itens com dois 58 e 11 e no servidor C teremos os itens com AIDS 3 6 9 12 todos os múltiplos de três e toda vez que quisermos inserir uma nova linha Fazemos o módulo do id e vemos para qual servidor mandar isso garante que todos vão estar balanceados Ou seja todos vão ter exatamente o mesmo número de linhas Então tá resolvido mas é a receita federal eles crescem infinitamente muito em breve

só três servidores não vai dar conta precisamos adicionar um novo servidor agora fodeu a conta pasta de módulo 3 para módulo 4 ou seja precisamos rebalancear todos os dados em todos os servidores na nova configuração cada ID vai ficar num servidor diferente do que estava antes essa estratégia funciona para Balancear se nunca mexemos a quantidade de servidores mas não escala se precisamos adicionar novos porque precisa mover todos os dados de um lugar para rebalancear e por isso foi inventado algoritmo de consistência em computação distribuída é um esquema de organização de AIDS que permite adicionar ou

remover servidores sem precisar mover todos os dados de lugar toda vez ele consegue isso organizando todos os AIDS no anel um círculo de restos para entender restos Eu recomendo que assistam o primeiro episódio de criptografia em resumo bem resumido hashi é uma função que pega qualquer informação por exemplo um string e devolve um número de tamanho fixo Mas é uma função Não reversível Ou seja a partir do número não tem como encontrar esse trigo original porque diversas Strings podem chegar no mesmo número a função só garante que se você passar a mesma string vai chegar

no mesmo número dependendo da função ela devolve um número até um determinado tamanho por exemplo um chá 512 vai devolver um número de até 512 bits o número máximo de 512 bits é um absurdo maior que a quantidade de átomos do universo visível obviamente é exagerado demais para um campo de ID um Cassandra temos uma outra função de resto não criptográfico Ou seja que não deve ser usado para criptografia Mas é bom suficiente para ir disso o mar murtree que devolve restos de 64 bits onde o maior número é da ordem de milhões de trilhões

que ainda é um número gigante mas é mais gerenciado enfim o principal é que no sistema de consistente consideramos um anel que vai de zero até esse número máximo de 64 bits daí Fazemos o resto dos AIDS dos Servidores Digamos que temos quatro servidores ele se distribuem pelo anel o lance de uma função de herege é que ela tende a ter uma distribuição uniforme o oposto de sequencial podemos gerar o resto dos dados do registro qual a combinação de diversos dados como o endereço IP do usuário mais o horário ou qualquer coisa assim por exemplo

imagine um anel onde cada ponto desse anel começa em Zero no topo e tem todos os números até dois elevados a 64 no final do anel encostado no zero para dar uma volta entendeu todos os dias possíveis estão no anel daí aplicamos a função de resto com nomes o endereço de p de cada servidor E aí eles caem arbitrariamente pelo anel só para o exemplo o servidor a lá em cima depois o b mais para direita lá embaixo e o c mais pra esquerda em baixo vamos inserir alguns dados Digamos que é o resto do

nome do registro O Primeiro Registro tem o nome de John e digamos que o hashi gerado caia entre o Noah e o NOB a regra é para ele escolher o servidor com o Ash maior ou igual ao do id olhando na direção de relógio da esquerda para direita nesse caso vai ser o NOB o próximo Egito tem nome de Fred e o resto por acaso tem ponto aqui entre o b e o centro ele cai no nosso c e o último registro com o nome de Susan cara que entre o c e o a então

vai pro a sempre na direção de relógio beleza e Qual a vantagem disso Bom vamos voltar pro cenário onde queremos adicionar um novo servidor o node e o resto dele vai aqui entre o c e o a por acaso mas ele cai depois da Susan o que acontece é que todos os dados com AIDS depois do C que estavam caindo no nó a agora você movidos para o nó de é assim que ele rebalanceia mas prestem atenção no exemplo de usar a função simples de modo precisaria mover todos os dados de todos os servidores quase

aqui os dados dos Servidores b e c não precisam ser mexidos só os do a que precisam ser divididos e os registros com a de maior que d e menores que a continuam no ar Digamos que o servidor a tem uma pane qualquer ele precisa removido e agora todo o registro que antes caia no ar pela regra de olhar o próximo servidor em sentido de relógio do anel vai passar cair no B só isso e nenhum dado de nenhum outro servidor precisa ser mexido falando simplificadamente é assim que garantimos ter a menor quantidade possível de

dados sendo movidos quando a infraestrutura muda a ideia é mover a menor quantidade de dados quanto possível quando precisamos adicionar novos servidores tem várias nuances nessa estratégia Por exemplo quando da remoção de um nó pode acontecer de outro nó acabar acumulando dados demais para evitar isso cada Nó pode ter múltiplos restos repertórios que eu colocariam em múltiplas posições no anel daí os dados poderiam ser melhor rebalanceados se ficou interessado depois leia a documentação a respeito em sites como educação Sandra ou no paper do dinel da Amazon dizendo assim parece fácil mas em Dynamo DB por

exemplo você tem que entender o conceito de chave de partição e chave opcional de ordenamento dados com a mesma chave de partição cai na mesma partição obviamente o problema mas se quisermos fazer uma pesquisa que precisaria buscar dados em múltiplas partições para isso tem comandos como Scan Mas isso é uma operação bem mais custosa do que pesquisar dentro de uma mesma partição portanto a estratégia de partição precisa estar muito bem definida no começo você não vai ter obstáculos de não conseguir fazer pesquisas rápidas quando precisar as coisas não são automáticas trocamos conveniência por performance num

banco relacional onde normalmente fica tudo junto é só rodar um comando SQL e temos o que queremos rápido num sistema distribuídos as coisas estão distribuídas e precisamos levar isso em consideração no Dynamo DB que é oferecido como serviço da WS precisamos entender bem o comportamento da nossa aplicação não só para não dificultar operações depois mas porque a cobrança também não é simples não se paga por Gigabyte armazenado por exemplo precisa calcular a quantidade de escritas por segundo a quantidade de inscritos por segundo durante pico a duração de cada operação de leitura porcentagem de capacidade de

leitura que quer deixar reservado o nível de consistência das leituras quantas quer que sejam fortemente consistentes quantas fracamente consistente por exemplo na calculadora online deles o preço por Gigabyte na região e o sisti é de menos 25 centavos por mês sucesso então não com 10 inscritos não transacionais 100 inscritos por segundo em horário de pico 400 inscritos por segundo em horário de pico 72 horas operando em pico durante um mês com capacidade reservada de escrita para um humano pode tomar mais de 23 dólares por mês e 150 dólares que precisa a vista logo no começo

para reserva daí continuando com os valores padrão para leitura só para não entendiar mas três dólares por mês e mais 30 dólares up front a vista Então por mês nessa configuração vai pagar uns 26 dólares mais 180 dólares à vista na entrada e essa configuração é a mais basiquinha para um app minúsculo na categoria de bancos de dados no ciclo oferecidos como serviço Ou seja que não precisamos saber como configurar aí na manutenção da empresa estrutura tem diversas outras opções como mongo DB Atlas ou o Google Fire base é bem Popular para aplicações pequenas porque

até 1 GB de mensagem até 1 GB de armazenamento 5 GB de cloud Stories o custo é gratuito já é um morro do DB Atlas você paga até que barato a 10 centavos por milhão de operações de leituras ou recomendado 57 dólares por mês pra solução dedicada de 10 GB até quatro terabytes de armazenamento não é simples calcular o real valor que vai pagar em dezenas de parâmetros para considerar como quantidade de de funções e gigabytes por segundo ou minutos de cloud build ou gigabytes transferidos pela rede e mais o preço vai variar de acordo

com o sucesso ou fracasso da sua aplicação quanto mais barato ficar mais fracassado é seu app quanto mais sucesso fizer mais caro vai ser no começo parece uma grande vantagem mas Justo quando fizer sucesso e achar que vai ganhar bastante é também quando eles vão te cobrar mais caro Essa é a faca de dois gumes de serviços que você não gerencia uma hora conta chega e isso sem contar o custo do desenvolvimento e manutenção da sua aplicação quanto mais exótico for um banco de dados mais difícil vai ser encontrar profissionais qualificados ou treinar em casa

só porque um banco é exótico não significa que resolve todos os seus problemas em muitos casos alguém pode escolher o Google Fire base pelo Hype mas na realidade o desenvolvimento teria ficado mais barato se tivesse escolhido sei lá um longo dbas ambos Fire base e mongo DB tem a flexibilidade de lidar com documentos estilo Jason sem precisar entender a estrutura mais rígida de um esquema de banco de dados relacionados mas só dizer Jason não significa que são iguais mongo DB permite lidar com documentos mais complexos embeddedjas sub-documentos o modelo do fire base é bem mais

simples mas o Fire base tem atualizações em tempo real que é importante para quem desenvolve aplicações mobile mudanças no banco podemos ser empurradas como notificações direto para os usuários em tempo real mongo DB não tem isso nativo Dá para colocar mas dá mais trabalho portanto é mais custo de desenvolvimento por outro lado se quisermos fazer pesquisas mais complexas um longo DB tem uma linguagem de corres mais avançada incluindo coisas como joins e índices secundárias o Fire base tem capacidade mas mais limitadas da mesma forma transações todo mundo foge de bom relacionado mas todos adoram ter

transações e dados fortemente consistentes um longo DB tem mais suporta transações do que Fire base de novo se quiser algo semelhante a transações no Fire base o curso de desenvolvimento sobe e se transações é realmente importante Talvez um banco relacional como a wsrds tivesse sido melhor em primeiro lugar mas a vantagem de serem essa service quer dizer que tanto mongo DB Atlas quanto Fire Store do fire base tem escalabilidade e replicação automáticas em múltiplas regiões para alta disponibilidade ou seja se Frutti de operações e garantir que nunca fique fora do ar seja primordial ambos podem

ajudar com isso mas você vai pagar por isso e não vai ser barato como eu expliquei o modelo de precificação é complexo precisa necessariamente gastar tempo pesquisando e avaliando muito bem o que acontece não só agora que sua aplicação tá no começo mas aqui seis meses se fizer sucesso não tem como eu explicar todos os bancos oferecidos como serviços hoje a amazon É mais famosa todo mundo escolhe o aws RDS para soluções de mais rico ou post eles como serviço mas o Google também tem o clou de ciclo como concorrente vai depender de precificação e

funcional atividades que para vocês podem ser importantes além deles tem o Ager seco Database e eu acho que até a hora que oferece o banco de dados SQL deles como serviço para complicar a vida a própria Amazon oferece produto similares na mesma plataforma como a Apache Aurora que parece com RDS Aurora é um produto superior de banco de dados Maria DB post ele ficou surviver orako tem maior garantia de disponibilidade dobro da performance no mesmo perfil de hardware mais facilidade de escalabilidade opções de backup replicação porém obviamente custa mais caro ou seja tem SQL para

todas as necessidades e capacidades de pagamento Digamos que você é um apologista de novo ciclo não quer mesmo SQL daí tem um mongo dbas o Google Fire Store que eu já falei mas temos mais opções pro mundo enterprise a s ap oferece o HC que é o Hanna enterprise Cloud tem a sigla DB que oferece uma versão de Cassandra deles e tem um Astra add da data estética também é Cassandra como serviço isso sem contar o rerucu que oferece posto de vez como serviço redisco como serviço em termos de Cash Man capche redis aws tem

o elast Cash como eu falei tem serviço para todo mundo só consegui pagar mas para você que é iniciante em programação não se deixe enganar por Hype de novo a gente vem discutindo esse assunto desde pelo menos 2008 e eu posso te garantir algumas coisas não existe consenso pelo simples fato que cada banco de dados tem pontos fortes e pontos fracos cada um serve para situações diferentes para aplicações bem pequenas meio que tanto faz você vai escolher um banco relacional SQL como Maria DB oposto ou se vai direto para um Fire Store da vida você

tem poucos dados tem poucos problemas para lidar a primeira versão de qualquer coisa que fizer sempre vai ser isso versão 1.0 só quando tiver usuários de verdade dados de verdade receita faturamento de verdade só aí vai realmente entender o que precisa e se ficar limitada a usar ferramenta para tudo em breve vai ter tanto problema e vai ignorar que existem já soluções para cada problema que corre o risco de fracassar Por ignorância na dúvida a solução mais comum é a mesma a wsrds composto que usou Maria DB que é o que a grande maioria dos

frameworkswagen usam como Rubian rails de angular Abel Spring daí uma solução de Cash usando handie diz homem cache E para isso tem a WS elast Cash e finalmente Jobs a sincros seja com Kafka seja com a WS SQS e isso resolve 90% dos seus problemas Se precisar de alguma coisa de documentos em Jason um post já suporta isso nativamente que é só fazer um protótipo aí vai de Fiber base se por acaso tiver na Rara categoria de Big Data significa que você não é uma micro empresa ou um freelancer já é uma empresa média aí

é outra categoria já vai olhar pra Aurora deitar e soluções para deitar sais como a pasta Spark muita coisa customizada vai ter que ter profissionais experientes de infraestrutura de de essa categoria não é para amadores por isso se foi iniciante não se preocupe com isso tão cedo você não é nem nunca vai ser o Netflix no fim do dia entender bancos de dados sejam Racionais sejam no ciclo significa entender o problema que se quer resolver primeiro daí aplicar fundamentos de Ciências da Computação árvores estruturas de dados redes sistemas de arquivos sistemas operacionais fundamentos de criptografia

ficar acompanhando discussões inúteis em fio de Twitter na bolha Debby só vai te confundir nunca tem nada de útil e você vai ser mais um Maria vai com as outras se a tenha a pesquisar documentação oficial de cada coisa A grande maioria dos programadores iniciantes hoje tem o mesmo problema de ignorar fundamentos ignorar os problemas que se quer resolver e escolher baseado em likes influência nenhum sabe o seu cenário particular óbvio que vai dar ruim se ficar um com dúvidas mandem nos comentários abaixo de curtir o vídeo deixa um joinha assinem o canal e não

deixe de compartilhar o vídeo com seus amigos a gente se vê até mais e podemos usar é assim que podemos de telefone que é um pouco a bordas dos discos pariu esse é um trem diferente de uma árvore que pariu tô entendendo como fazer exige que você instale uma Ilhota cada entrega Que rota um servidor acontece quando temos quando Atlas quanto faz Fire Store Fire Store que você não é um microem não é uma micro empresa que pariu