{"id":1680,"date":"2016-12-06T10:00:40","date_gmt":"2016-12-06T12:00:40","guid":{"rendered":"https:\/\/blog.umbler.com\/?p=1680"},"modified":"2018-12-10T12:23:16","modified_gmt":"2018-12-10T14:23:16","slug":"3-como-aperfeicoar-a-velocidade-de-seu-site-banco-de-dados","status":"publish","type":"post","link":"https:\/\/blog.umbler.com\/br\/3-como-aperfeicoar-a-velocidade-de-seu-site-banco-de-dados\/","title":{"rendered":"#3 Como aperfei\u00e7oar a velocidade de seu site: banco de dados"},"content":{"rendered":"

Nos posts anteriores, falei sobre como melhorar a performance do seu site diminuindo a lat\u00eancia, otimizando o front-end<\/a> e \u201cesmerilhando\u201d o back-end<\/a>. Hoje, vamos falar de algo que muita gente usa, mas pouca gente entende de verdade: banco de dados<\/strong>.<\/p>\n

Tenho certeza que existem coisas b\u00e1sicas sobre performance de consultas no banco de dados que voc\u00ea aprendeu em algum lugar, geralmente em um curso, que deve usar extensivamente, acreditando que todos os seus problemas est\u00e3o resolvidos. Eu gostaria de estar errado, mas como professor de faculdade vejo uma situa\u00e7\u00e3o muito prec\u00e1ria quando o assunto \u00e9 a performance do banco de dados das aplica\u00e7\u00f5es de meus alunos.<\/p>\n

Vou tentar n\u00e3o \u201cchover no molhado\u201d aqui e n\u00e3o ficar falando para sempre fechar a conex\u00e3o depois de abrir. Vou tentar seguir pelo caminho contraintuitivo, que costuma gerar os melhores resultados. O fato \u00e9 que n\u00e3o existe uma \u201cbala de prata\u201d, uma solu\u00e7\u00e3o para todos os problemas do seu banco de dados. Dependendo do fabricante que voc\u00ea escolheu, do tipo de banco que optou e at\u00e9 mesmo do uso dos dados que sua aplica\u00e7\u00e3o faz, muitas outras dicas seriam ben\u00e9ficas.<\/p>\n

Como algu\u00e9m que j\u00e1 criou e gerenciou bancos de dados em sistemas usados por meio milh\u00e3o de usu\u00e1rios, tenho v\u00e1rias dicas para compartilhar, que, embora n\u00e3o cubram todos os casos, podem passar ideias bem interessantes.<\/p>\n

Dica 1: Escolha o banco certo<\/h2>\n

Como a ideia \u00e9 chacoalhar os seus neur\u00f4nios com dicas contraintuitivas, resolvi come\u00e7ar pela pior delas!<\/p>\n

Voc\u00ea conhece a hist\u00f3ria: Jo\u00e3ozinho faz curso de programa\u00e7\u00e3o e aprende o banco de dados X. Pro resto da vida Jo\u00e3ozinho cria seus projetos usando o banco de dados X. Mesmo quando tudo est\u00e1 dando errado, aponta a culpa para o banco.<\/p>\n

O mundo \u00e9 muito maior do que um fabricante de banco de dados ou mesmo do que os bancos relacionais que a imensa maioria est\u00e1 acostumado. O Jo\u00e3ozinho tem que abrir os olhos para o mercado, se quiser progredir como profissional!<\/p>\n

Ent\u00e3o, voc\u00ea precisa armazenar dados gigantes n\u00e3o relacionados ou que podem ser aninhados? Porque est\u00e1 usando SQL Server ao inv\u00e9s de MongoDB?
\nDados ef\u00eameros sendo criados e destru\u00eddos o tempo todo no seu MySQL, com performance sofr\u00edvel? Isso n\u00e3o deveria ser tarefa pro Redis?<\/p>\n

O seu site precisa guardar poucos dados e voc\u00ea criou um banco Oracle para isso, pois foi o que viu na faculdade? J\u00e1 ouviu falar em XML? Ah, n\u00e3o gosta de arquivos, mas e SQLite?<\/p>\n

Grafos e relacionamentos extremamente complicados em um PostgreSQL, quando temos o Neo4J especializado nisso? Ou ent\u00e3o s\u00e9ries de dados baseados em tempo, especialidade do InfluxDB, ou ent\u00e3o dados em tempo-real, coisa fac\u00edlima de fazer com RethinkDB, ou ent\u00e3o.. .acho que voc\u00ea entendeu o que eu quis dizer!
\nCada banco de dados existe por uma raz\u00e3o de existir, e eu mesmo n\u00e3o sou um especialista no assunto para ficar dizendo o que cada um deve usar. Cada sistema tem as suas caracter\u00edsticas e \u00e9 papel do analista ou arquiteto do sistema definir a op\u00e7\u00e3o ideal. Como a maioria dos projetos tem s\u00f3 programadores, \u00e9 voc\u00ea que est\u00e1 lendo esse post que vai ter de aprender a escolher o banco certo. Se ferrou! \ud83d\ude42<\/p>\n

O que quero colocar na sua cabe\u00e7a \u00e9 que voc\u00ea at\u00e9 pode tentar usar os bancos relacionais mais comuns como SQL Server e MySQL para todos os seus projetos. Mas que, dificilmente, eles ser\u00e3o as escolhas mais adequadas para todas as situa\u00e7\u00f5es que vemos na web de hoje e que os programadores teimam em tentar encaix\u00e1-los. \u00c9 uma dica um tanto radical? \u00c9. Mas, se nenhuma das demais dicas desse post ajudar, pode ser um \u00f3timo sinal de que voc\u00ea chegou no limite do modelo relacional para o seu problema e deveria procurar outras alternativas, geralmente no mundo NoSQL.<\/p>\n

Dica 2: Crie as tabelas do jeito certo<\/h2>\n

Esse problema \u00e9 t\u00e3o comum, mas t\u00e3o comum, que s\u00f3 n\u00e3o coloquei como primeira dica para causar mais impacto com a que deixei naquela posi\u00e7\u00e3o.<\/p>\n

Os bancos de dados modernos possuem dezenas de tipos de dados, v\u00e1rias constraints e v\u00e1rios \u00edndices. Mas, os programadores teimam em mudar seus h\u00e1bitos arcaicos e pregui\u00e7osos de colocar todo n\u00famero como integer, todo texto como varchar(max), uma chave prim\u00e1ria autoincremental e no m\u00e1ximo umas chaves estrangeiras para fazer os relacionamentos b\u00e1sicos.<\/p>\n

Isso funciona? Sim. Quando voc\u00ea est\u00e1 desenvolvendo. Ou quando seu sistema vai ser t\u00e3o pouco usado que n\u00e3o faz diferen\u00e7a alguma se usou um integer ou um smallint.<\/p>\n

Deixarei para falar de \u00edndices e relacionamentos mais pra frente, vou me focar nessa dica nos tipos de dados (colunas) do banco.<\/p>\n

Assim como mencionei no post anterior quando entrei na dica sobre tipos de vari\u00e1veis, os tipos das suas colunas impactam em a) no tamanho total do seu banco de dados e b) na velocidade das suas opera\u00e7\u00f5es de leitura e escrita. Vou falar melhor de cada um, calma!<\/p>\n

Cada tipo de dado ocupa uma quantidade de bytes no(s) arquivo(s) do banco, e quanto menor o tamanho do banco, melhor por diversas raz\u00f5es, mas a mais \u00f3bvia \u00e9 custo de disco, embora n\u00e3o seja o maior problema atualmente. Usando um integer em uma coluna, cada registro da tabela em quest\u00e3o consumir\u00e1 4 bytes e permitir\u00e1 n\u00fameros entre -2.5B e +2.5B, aproximadamente. Agora, se voc\u00ea optar por um smallint essa mesma coluna vai permitir n\u00fameros entre -32k e +32k, ocupando apenas 2 bytes e geralmente oferecendo n\u00fameros suficientes. Tinyint vai mais longe ainda, consumindo apenas 1 byte e dando 256 n\u00fameros poss\u00edveis. E para chutar o balde, alguns bancos ainda tem o bit (ou boolean) que fornece apenas dois n\u00fameros\/op\u00e7\u00f5es e consome apenas 1 bit de espa\u00e7o em disco por registro!<\/p>\n

O mesmo vale para as colunas com ponto flutuante, que variam de banco para banco, mas que, geralmente, quanto maior a precis\u00e3o (n\u00famero de casas depois da v\u00edrgula), mais espa\u00e7o ocupam no banco.<\/p>\n

Com colunas textuais acontece o mesmo, existem diferentes tipos de dados, sendo que os mais comuns s\u00e3o char e varchar e, em ambos, devemos especificar o limite de caracteres permitidos, consumindo em torno de 2 bytes por caractere, dependendo do collation\/idioma do seu banco (mais um \u201coverhead-zinho\u201d de 1 bytes para cada 255 caracteres). Qual a diferen\u00e7a ent\u00e3o?<\/p>\n

Um char(11) sempre ocupar\u00e1 11 \u2018espa\u00e7os\u2019 em cada registro da tabela, independente se voc\u00ea enviou uma palavra com menos caracteres. J\u00e1 um varchar(11) ocupa sempre o necess\u00e1rio para a palavra que for inserida, at\u00e9 o limite de 11 caracteres. Varchar \u00e9 sempre melhor, ent\u00e3o? Definitivamente n\u00e3o. Este tamanho \u2018vari\u00e1vel\u2019 (que \u00e9 o \u2018var\u2019 no nome) cobra seu pre\u00e7o nas opera\u00e7\u00f5es realizadas no banco, uma vez que o tamanho fixo do char permite c\u00e1lculos mais r\u00e1pidos para alocar espa\u00e7o em disco e retornar dados. Ou seja, se a sua coluna precisa de tamanho vari\u00e1vel, use varchar, mas se a string que voc\u00ea vai salvar sempre possui o mesmo tamanho, use char.<\/p>\n

Varchar(max), quando dispon\u00edvel, \u00e9 mais nocivo ainda, pois gera overflows de dados, mais trabalho pro banco e n\u00e3o permite que o campo seja index\u00e1vel, sempre gerando scans no banco de dados quando a dita coluna \u00e9 inclu\u00edda em um select. Se n\u00e3o entendeu tudo o que eu disse, apenas n\u00e3o use. \ud83d\ude42<\/p>\n

Tamb\u00e9m temos os tipos de datas que v\u00e3o de date, para time, para datetime e outras varia\u00e7\u00f5es, dependendo do banco. E temos tipos de dados geom\u00e9tricos, tipos de dados para geolocaliza\u00e7\u00e3o, para guardar arrays de bytes (BLOBs, arghhhh) e muitos outros que voc\u00ea deveria dar uma estudada a fundo focado na tecnologia<\/a> de banco que ir\u00e1 utilizar. \u00c9 \u00f3bvio que ningu\u00e9m acerta na modelagem do banco logo de cara, mas planejar um pouco mais antes de sair criando tabelas pode ser a chave para ter menos dor de cabe\u00e7a no futuro, quando tudo estiver em produ\u00e7\u00e3o e downtimes tiverem de ser evitados ao m\u00e1ximo.<\/p>\n

Dica 3: Mantenha seus amigos por perto, e seu banco de dados mais perto ainda!<\/h2>\n

Acredito que deva ser um tanto \u00f3bvio falar que o banco de dados deve estar o mais perto poss\u00edvel da sua aplica\u00e7\u00e3o, mas n\u00e3o custa repetir. O que geralmente n\u00e3o \u00e9 t\u00e3o \u00f3bvio \u00e9 o estrago que um banco de dados distante pode causar na performance e que n\u00e3o importa que tudo mais esteja otimizado, a lat\u00eancia das conex\u00f5es com o banco ser\u00e3o o gargalo da sua aplica\u00e7\u00e3o.<\/p>\n

Lat\u00eancia? Onde ouvi falar dela antes? Ah sim, no primeiro post dessa s\u00e9rie. Corre l\u00e1 se ainda n\u00e3o leu!<\/a> \ud83d\ude00
\nSe o mundo fosse um lugar perfeito, o banco de dados ficaria no mesmo servidor da aplica\u00e7\u00e3o, para ter lat\u00eancia pr\u00f3xima de zero. Como isso, na maioria das vezes, n\u00e3o \u00e9 poss\u00edvel ou n\u00e3o \u00e9 recomend\u00e1vel, por quest\u00f5es de seguran\u00e7a<\/a>\/escala\/produtividade\/coloque-seu-motivo-aqui, temos de manter o banco na mesma LAN, ele tem de ser acess\u00edvel pela rede local, jamais pela Internet.<\/p>\n

Independente das suas preocupa\u00e7\u00f5es com seguran\u00e7a, que fugiriam do escopo desse post, a maioria das bibliotecas de conex\u00e3o com bancos de dados, especialmente os relacionais, n\u00e3o foram projetadas para uso atrav\u00e9s da Internet, sendo um dos principais motivos pelos quais plataformas m\u00f3veis n\u00e3o se conectam diretamente a SGBDs.<\/p>\n

Resumindo, n\u00e3o basta ter toda a sua infraestrutura no mesmo continente ou pa\u00eds, como algumas empresas vendem por a\u00ed, o seu banco de dados PRECISA estar na mesma rede (qui\u00e7\u00e1 mesmo servidor) que a sua aplica\u00e7\u00e3o. Ponto.<\/p>\n

Dica 4: S\u00f3 pegue o que vai consumir<\/h2>\n

Lembra quando voc\u00ea era crian\u00e7a (supondo que nenhum menino prod\u00edgio esteja lendo esse post) e sua m\u00e3e dizia: \u201cS\u00f3 p\u00f5e no prato o que vai comer!\u201d, o que nas entrelinhas queria dizer \u201cseu couro vai ficar ardendo se deixar comida no prato\u201d? Pois \u00e9, em banco de dados vale a mesma dica: s\u00f3 pegue o que vai consumir.
\nComo assim? Calma, eu explico!<\/p>\n

Toda vez que voc\u00ea for no banco de dados para fazer uma consulta, pegue apenas os dados que v\u00e1 consumir. Cada consulta que voc\u00ea faz no banco de dados gera um \u2018download\u2019, caso ainda n\u00e3o tenha parado para refletir. Quanto mais dados voc\u00ea trouxer, maior ser\u00e1 esse \u2018download\u2019 e se voc\u00ea n\u00e3o for usar esses dados na aplica\u00e7\u00e3o, voc\u00ea apenas consumiu mais tr\u00e1fego e principalmente, mais tempo do usu\u00e1rio que est\u00e1 no seu sistema\/site!<\/p>\n

Geralmente as pessoas simplificam essa dica dizendo para jamais usar \u201cSELECT * \u201d nas suas consultas, mas vai al\u00e9m disso. A ideia \u00e9 jamais pegar mais dados do que realmente necessita.<\/p>\n

Dica 5: S\u00f3 observe<\/h2>\n

Depois que voc\u00ea colocou as quatro dicas anteriores em pr\u00e1tica, \u00e9 hora de parar um pouco de otimizar e observar.<\/p>\n

\u00c9 muito comum acontecer excesso de engenharia (over-engineering) ou otimiza\u00e7\u00f5es prematuras quando o assunto \u00e9 banco de dados. Ent\u00e3o pare de mexer no seu banco por um momento e passe a analisar seu comportamento em produ\u00e7\u00e3o.<\/p>\n

Periodicamente use os relat\u00f3rios fornecidos pelo pr\u00f3prio banco de dados para saber quais tabelas est\u00e3o sendo mais acessadas, quais consultas est\u00e3o sendo mais utilizadas e quais est\u00e3o lentas, qual tabela est\u00e1 crescendo mais r\u00e1pido que as demais, etc. Com essas informa\u00e7\u00f5es voc\u00ea poder\u00e1 tra\u00e7ar um plano de a\u00e7\u00e3o do que deve ser otimizado de facto.<\/p>\n

Outra dica nesta linha de \u2018just watch\u2019 \u00e9, uma vez identificadas as consultas que mais s\u00e3o utilizados\/mais consomem o banco, analisar os execution plans delas, o que pode ser feito geralmente atrav\u00e9s de ferramentas visuais de gerenciamento do banco de dados, como o SQL Server Management Studio. No execution plan voc\u00ea conseguir\u00e1 ver qual parte da consulta \u00e9 o gargalo, qual parte pode ser otimizada com um \u00edndice e por a\u00ed vai.<\/p>\n

S\u00f3 depois que observar o seu banco \u201cem a\u00e7\u00e3o\u201d por um tempo \u00e9 que voc\u00ea deve partir para as pr\u00f3ximas dicas.<\/p>\n

Dica 6: Tenha recursos suficientes<\/h2>\n

Uma vez que tenha observado o seu banco de dados funcionando por algum tempo, especialmente nos hor\u00e1rios de pico, voc\u00ea conseguir\u00e1 saber se voc\u00ea possui recursos suficientes. Eu sei, essa n\u00e3o \u00e9 a \u201cf\u00f3rmula m\u00e1gica\u201d para a escala do banco de dados que voc\u00ea esperava, mas sinto informar que, se essa f\u00f3rmula existe, eu nunca encontrei.<\/p>\n

Voc\u00ea precisa basicamente verificar quatro recursos b\u00e1sicos: CPU, mem\u00f3ria RAM, espa\u00e7o em disco e IO de disco. Geralmente o gargalo dos BDs s\u00e3o mem\u00f3ria RAM e IO de disco, ent\u00e3o fique atento a eles, e atente \u00e0s limita\u00e7\u00f5es da vers\u00e3o de banco que estiver usando (m\u00e1ximo 1GB RAM para SQL Express, por exemplo), restri\u00e7\u00f5es do seu provedor de hospedagem (se for o caso) e por a\u00ed vai.<\/p>\n

Garanta que, no m\u00ednimo, seu banco de dados tenha uma \u201cfolga\u201d de 20% de teto de uso dos recursos de hardware e aumente essa folga em eventos sazonais que afetem seu neg\u00f3cio, como o Natal para donos de ecommerce, por exemplo.<\/p>\n

Dica 7: Desnormalize suas tabelas (!!!)<\/h2>\n

Calma, n\u00e3o atire suas pedras em mim antes de ler esta dica por completo! Eu sei, todos aprendemos na faculdade que devemos manter nossos bancos sob as Formas Normais, 100% normalizado, bonitinho, como manda o figurino.<\/p>\n

Mas\u2026<\/p>\n

Assim como tudo na vida, existem exce\u00e7\u00f5es. Observando o seu banco em produ\u00e7\u00e3o durante algum tempo (dica 5) e garantindo que h\u00e1 recursos suficientes para ele operar com m\u00e1xima efici\u00eancia (dica 6) voc\u00ea saber\u00e1 se o modelo ER que construiu foi o correto e, dependendo do seu neg\u00f3cio, uma \u201cdesnormaliza\u00e7\u00e3o\u201d de algumas tabelas pode vir a calhar.<\/p>\n

Como assim?<\/p>\n

\u00c0s vezes, um ER 100% normalizado n\u00e3o \u00e9 perform\u00e1tico. Na verdade, na maioria das vezes ele n\u00e3o \u00e9. As Formas Normais que aprendemos na faculdade, n\u00e3o s\u00e3o voltadas para performance, s\u00e3o voltadas para garantir partes do acr\u00f4nimo ACID: atomicidade, consist\u00eancia, integridade e durabilidade. Isso n\u00e3o \u00e9 necessariamente ruim, apenas que pode n\u00e3o ser o que voc\u00ea deseja em alguns casos.<\/p>\n

Algumas vezes, uma chave natural \u00e9 melhor que constraints. Algumas vezes, repetir alguns dados pequenos e simples, mas que s\u00e3o muito requisitados, \u00e9 melhor do que criar relacionamentos com chaves estrangeiras que te levar\u00e3o a fazer JOINs toda hora (na verdade essa dica poderia se chamar \u201cn\u00e3o use JOINs demais\u201d). Algumas vezes, usar o bom senso \u00e9 muito melhor do que usar os livros did\u00e1ticos. Pense nisso.<\/p>\n

Desnormalizando algumas tabelas muito requisitadas geralmente reduzem a complexidade de queries que temos de executar o tempo todo, e queries menos complexas geralmente nos levam a execution plans melhores. \u00d3bvio que voc\u00ea ter\u00e1 de pesar os pr\u00f3s e contras, mas esse \u00e9 o seu trabalho, n\u00e3o \u00e9 mesmo? Se modelar bancos de dados eficientes e eficazes fosse uma ci\u00eancia exata, n\u00e3o precisar\u00edamos de pessoas trabalhando nestas posi\u00e7\u00f5es e voc\u00ea n\u00e3o estaria lendo esse artigo, n\u00e3o \u00e9 mesmo?<\/p>\n

Dica 8: Crie \u00edndices para as consultas mais comuns<\/h2>\n

Novamente, observando o seu banco de dados em funcionamento e, principalmente, as consultas mais comuns, \u00e9 f\u00e1cil notar onde deveriam existir \u00edndices. Um par\u00eanteses: note que n\u00e3o \u00e9 a primeira vez que cito \u2018observar seu banco de dados\u2019 nas \u00faltimas dicas. Voc\u00ea deve fazer isso constantemente se quiser manter seu banco performando bem.<\/p>\n

\u00c9 impressionante como muitos, mas muitos sistemas, n\u00e3o possuem \u00edndice algum. Em alguns SGBDs como o SQL Server, um \u00edndice clusterizado \u00e9 automaticamente criado quando voc\u00ea define a chave prim\u00e1ria de sua tabela, mas isso \u00e9 uma exce\u00e7\u00e3o. N\u00e3o \u00e9 incomum ver bancos sofrendo para fazer consultas b\u00e1sicas pois quem modelou o banco n\u00e3o conhecia como criar \u00edndices ou se esqueceu. Isso inclusive em sistemas comerciais famosos que n\u00e3o vou mencionar aqui.
\nOs mais incautos podem pensar: \u201cse \u00edndice \u00e9 algo bom, vou criar em todas colunas!\u201d. Tudo na vida tem seu pre\u00e7o, e \u00edndices n\u00e3o s\u00e3o exce\u00e7\u00e3o. A cada \u00edndice criado, voc\u00ea aumenta o espa\u00e7o em disco alocado para o seu banco de dados e uma vez que um \u00edndice \u00e9 uma constraint (restri\u00e7\u00e3o), ele ser\u00e1 verificado em diferentes situa\u00e7\u00f5es de escrita, o que pode causar redu\u00e7\u00e3o da performance nessas situa\u00e7\u00f5es.<\/p>\n

Algumas dicas gerais (n\u00e3o gosto muito de dar dicas gerais, mas vamos l\u00e1\u2026) incluem:<\/p>\n