Arquivo da tag: Banco de Dados

A nova geração de bancos de dados

Martelo. É a primeira ferramenta que vem a cabeça quando é necessário pregar alguma coisa. E se ao invés de um prego, você precisar prender uma estaca (sempre útil quando você tem um elefante de estimação), existem martelos ou marretas de diversos tamanhos, mas o mecanismo, a forma básica da ferramenta é a mesma. São todos martelos.

Para quem nunca viu, isto é um martelo

Para quem nunca viu, isto é um martelo

Depois que você resolve muitos problemas com seu martelo, começa a achar que todos os seus problemas podem ser resolvidas a base do martelo. Por exemplo, você pode usar o martelo para enfiar um parafuso em um buraco (não façam isso em casa, crianças). Pode fazer um strike no boliche usando o martelo. Precisa desligar a TV? Martelo.

O banco de dados relacional é o martelo, das últimas décadas, quando se fala em armazenamento de dados. Chegamos em um ponto em que nem se questionava mais essa escolha. Precisamos armazenar um monte de dados e depois consultá-los? Banco de dados. Depois disso era questão de escolher entre Microsoft, Oracle ou opções open source. Se o problema não fosse um prego, bastava dar um jeitinho que ele se tornava um prego. E muitos problemas realmente são pregos.

“E quais problemas não são pregos?”, você me pergunta segurando seu martelo. Eis os principais:

Escalabilidade

Mas hoje vivemos em mundo em que a internet já não é mais novidade. O que significa que aplicações muitas vezes precisam suportar acessos de um número imenso de usuários. O que significa que é necessário armazenar montanhas de dados que crescem em um ritmo muito grande e depois consultar esses mesmos dados sem perder muito tempo. Pense em sistemas como Facebook, ou Amazon, ou LinkedIn, e imagine o sistema virando uma carroça porque o banco de dados se tornou o gargalo. É MUITO dinheiro indo pelo ralo.

Para esses casos, se seu banco de dados velho de guerra não está dando conta de jeito nenhum, você precisa de alguma solução que seja um pouco mais distribuída, para a carga de escritas e leituras de dados ficar distribuída. Você precisa de políticas de lock que sejam mais baratas para sua aplicação, porque cada milissegundo perdido em um sistema desse porte pode se transformar em muitos segundos (ou muitos time-outs).

Para esses casos você pode dar uma olhada em alguns dos bancos de dados de documentos (document databases) e hashmaps distribuídos, como CouchDB, MongoDB, Tokyo Cabinet e Project Voldemort. Também existem os serviços do Google e da Amazon que inspiraram muitos desses projetos, o BigTable e o SimpleDB respectivamente. E se seu maior problema é processar muitos dados, talvez você queira conhecer o HBase, que é um subprojeto do Hadoop, a implementação open source do algoritmo Map-Reduce do Google (também conhecido como a forma mais popular hoje de se dividir um trabalho grande e resolver em paralelo como muitas coisas pequenas). O CouchDB também está implementando um Map-Reduce diretamente em seu banco de dados.

Flexibilidade

Às vezes a estrutura de seus dados não é fixa. Imagine por exemplo que você precise guardar questionarios e suas respostas, e toda hora alguém inventa umas perguntas novas para o seu questionário. Isso é motivo de mau humor para o DBA que toda hora vai criar uma coluna no banco de dados e alterar suas consultas para incluir os novos campos. Esse DBA vai riscar o seu carro. Se quiser se prevenir, você pode dar uma olhada em um dos bancos de dados de documentos de que já falei, como o CouchDB ou o MongoDB, que armazenam os dados como uma entidade que eles chamam de documentos (nada mais que uma coleção de campos e respectivos valores) sem uma estrutura fixa. Na verdade você pode armazenar em uma mesma tabela coisas completamente diferentes, como estatísticas da Fórmula 1 e resumos da novela das 8 (o que não seria muito útil).

Outro caso de uso seria construir um sistema como o Salesforce, que permite que os clientes customizem os dados, adicionando campos que julguem ser úteis para seu negócio. A empresa que vende carros vai querer campos para indicar quais são os opcionais do veículo que estão vendendo. Já o usuário que vende aquelas garrafadas que curam várias doenças, vai querer marcar quais são os males que seu produto vai sanar.

Graças ao meu sistema de CRM, meu market share dobrou no Q3

Graças ao meu sistema de CRM, meu market share dobrou no Q3

Estrutura

Dependendo do domínio de sua aplicação, seus dados podem não ter muita cara de tabelas e registros. Não que seja impossível utilizar tabelas e registros para modelar quase tudo, mas pode ser que a natureza desses dados torne um pesadelo tentar modelar as entidades em tabelas. E pior ainda, seu programa levar tanto tempo para te trazer os dados da forma que você precisa que simplesmente inviabilize o projeto.

Imagine que você esteja construindo sua própria rede social, seu Orkut ou algo do tipo. Você acordou com uma vontade muito forte de fazer uma aplicação que descobre quantas pessoas que são amigos de seus amigos, ou amigos de seus amigos de seus amigos e assim por diante, que são fãs do blog TI Simples. Se você é um ninja de SQL já sabe que fazer isso de um golpe só não é viável (a não ser que seu banco de dados tenha alguma extensão ninja de SQL). O problema dessa aplicação é que os relacionamentos entre os dados são a parte mais importante. O que você precisa neste caso é de um banco de dados de grafos (ou banco de dados de redes), como o Neo4j por exemplo.

Precisa construir um datawarehouse para seu sistema de BI? Consultar o banco de dados para retirar informações úteis e que vão ajudar na estratégia da empresa não é algo muito suave de se fazer no mesmo banco de dados que seus sistemas de produção alimentam (por experiência própria, já fui ao cinema enquanto uma consulta rodava, voltei e ainda não havia acabado). A estrutura boa para os dados dos sistemas de entrada de dados em geral não é muito boa para uma consulta mais profunda a esses mesmos dados. No final, você precisa usar produtos de datawarehousing para deixar seus dados no jeito. Ou pode apelar para soluções inovadoras, em que a estrutura física dos dados é otimizada para permitir consultas mais elaboradas, como o Vertica que armazena os dados agrupando-os por coluna (ou seja, os valores para o mesmo campo logicamente próximos, ao contrário de colocar os valores dos campos de cada registro logicamente próximos, como os bancos comuns fazem). Ou armazenamento baseado em valor, fornecido pelo iLuminate, que armazena todos os valores de um mesmo tipo em um mesmo pool evitando valores repetidos (esta abordagem é tão diferente que vale até uma visita ao site do fabricante).

Eu realmente preciso desse trem?

Esses novos bancos de dados surgiram por conta de necessidades que foram aparecendo e que não eram bem respondidas com os produtos existentes. Por serem coisas novas (e legais) começaram a virar moda entre os desenvolvedores, mesmo que muitas dessas bases de dados ainda não estejam em uma fase muito estável. Muito provavelmente, para a maioria dos casos, você pode resolver seus problemas usando o seu banco de dados comum. Pode resolver a escalabilidade utilizando caches de dados, fazendo replicação master-slave ou sharding de seus dados (um servidor com dados de São Paulo e outro com os outros estados por exemplo). Se você precisa de muita flexibilidade nos dados mas não necessariamente precisa realizar consultas usando esses campos, pode por exemplo colocar os dados no banco como XML ou gravá-los em arquivos. Nenhum dos problemas listados acima é novo e dependendo do tamanho do problema e da sua paciência é possível dar um jeito que atenda a sua necessidade.

Mas eu recomendo que comece a dar uma olhada em alguns desses projetos, a maioria deles gratuitos e open source. Verifique se existe uma comunidade ativa de desenvolvedores ao redor do projeto. Faça pequenos testes. A maioria desses projetos abre mão de muitas funcionalidades que existem nos BDs comuns, em troca de alguma vantagem como performance, mas muitos deles estão caminhando para se tornar produtos bastante completos que poderão ser utilizados tranquilamente como seus ancestrais. Com certeza eles não vão acabar com os bancos de dados relacionais (como algumas pessoas estão pensando), mas são ótimas adições à sua caixa de ferramentas. Assim como o martelo.

Se quiser se aprofundar um pouco mais, recomendo este link e mais este, todos em inglês. E visitar os sites dos projetos.

Evolução do backup de banco de dados

A principal razão para quedas de cabelos e noites mal dormidas de DBAs e System Engineers, quando o assunto é banco de dados, é com certeza o backup. Dependendo de como é feito, o backup pode gerar muita dor de cabeça mesmo quando está funcionando bem. E custar alguns empregos se não funcionar (e claro que as pessoas só descobrem isto quando precisam restaurar alguma coisa).

Reação de DBA quando perguntada sobre o backup

Reação de DBA quando perguntada sobre o backup

Os principais problemas (e RISCOS) relacionados aos métodos de backup de bancos de dados atualmente são:

  • Janela de backup: a execução de backup precisa começar e terminar dentro de um certo período de tempo. Porém, dependendo da carga no banco de dados, velocidade do storage, rede, da forma como os dados são jogados para fita ou área de armazenamento de backup, etc., um job de backup pode acabar levando tanto tempo que acaba sendo executado em horários em que o sistema está em produção, ou seja, acaba afetando a performance dos servidores e sistemas que utilizam o banco. Nos piores casos pode até chegar a mais de 24 horas, inviabilizando a execução de backups diários e tornando o risco de perder dados críticos seu companheiro de trabalho permanente.
  • Tempo para recuperação: Shit happens, e quando o pior acontece você precisa rezar para aquela fita com o último backup full esteja funcionando direitinho. Só que em alguns casos, cada minuto em que o sistema fica fora do ar, é dinheiro que está escoando pelo ralo, são clientes perdidos, é credibilidade descarga abaixo. E restaurar backups de fita sempre vão levar muitos minutos, às vezes horas. Mesmo que o cliente possa fazer restaurações demoradas sem perder dinheiro, esse é o tipo de tarefa capaz de gerar úlceras de preocupação nos donos dos dados e no pobre do operador de backup (que usa o tempo de restore para enviar currículos caso a tarefa não seja bem sucedida).
  • Confiabilidade: Mesmo que tenham melhorado muito, backups em fita, que ainda são a principal forma de armazenar backups, não são confiáveis o suficiente. Pelo menos não o suficiente para que um DBA não se apavore caso precise da fita. E como um restore normalmente leva muito tempo e pode precisar de várias fitas, você pode demorar muito tempo para descobrir que está ferrado.
  • Ponto de recuperação: O quanto de seus dados você pode perder? Óbvio que a maioria das pessoas vai responder que não pode perder nada, mas isso não é uma expectativa realista. Em caso de um problema com seu banco de dados (como um ataque de rinocerontes em seu data center), alguns dados, os dados mais recentes, você vai perder. Ou eles acabam não indo para o backup por serem extremamente recentes, ou não houve tempo para replicá-los no banco de dados espelho. A frequência de seus backups e a forma como você planeja seu DR (disaster recovery) podem definir o quanto você vai perder. O problema é que normalmente é simplesmente inviável aumentar a frequência dessas operações.

Isso ainda é verdade tanto para bancos de dados mais “maduros”, como o Oracle, quanto para bancos que estão amadurecendo, como o SQL Server da Microsoft. Isso sem falar em MySQL, Sybase, DB2, PostgreSQL e outros mais obscuros. Realizar backups com todos estes problemas já é prática a tanto tempo, que a maioria das pessoas nem cogita outras possibilidades. É a operação padrão, ao projetar um sistema com um banco de dados, a equipe de TI automaticamente se prepara para montar todo esse esquema.

Mas graças a Santo Isidoro, hoje existem maneiras muito melhores para acabar com esses problemas, para transformar o backup em uma brisa ao invés de um inferno. O grande problema é que estas formas mais evoluídas  não são muito conhecidas, mesmo por DBAs e administradores de storage. Mas para entender porque isso representa uma grande evolução na forma de se fazer backup, precisamos fazer uma rápida revisão sobre os métodos ultrapassados.

  • Pré-história: A forma mais primordial consistia em desligar o banco de dados, realizar o backup e depois colocar o banco no ar novamente. Porém muitos sistemas não podem ser simplesmente desligados todo dia por várias horas (pelo menos é o que os pacientes de hospitais informatizados preferem acreditar). Outra forma é um dump lógico dos dados, extrair os dados do banco para um arquivo que pode ser importado caso fosse necessário restaurar os dados. Isto gera dados com um tamanho que pode ser bem maior que o banco de dados original, problemas de formatos na recuperação e impacto de performance. Ainda são formas utilizadas para bancos menores e menos importantes.
Métodos antigos de backup de BDs

Métodos antigos de backup de BDs

  • Atual mas ultrapassado: Hoje existe uma proliferação de softwares para backup, com integração com storage e dispositivos de fita, com automatização do processo de backup, possibilidade de realizar backups incrementais para diminuir as janelas de backup, luzinhas piscando para todos os lados, etc.. Os grandes problemas são os custos dessas soluções, a fauna bastante diversificada de software que precisa ser instalada nos clientes para integrar tudo, necessidade de técnicos que praticamente tem PhD em backup, além de não resolver muito bem as 4 grandes questões já citadas: janela de backup, tempo para recuperação, confiabilidade e ponto de recuperação. Obviamente muito melhor que os métodos pré-históricos, mas ainda geradores de dor de cabeça.
Métodos atualmente mais usados

Métodos atualmente mais usados

O futuro!

Como o backup deveria ser

Como o backup deveria ser

Hoje, com a ajuda de hardware altamente integrado com software, é possível realizar backups de bancos de dados e superar os 4 cavaleiros do apocalipse do backup (também conhecidos como os 4 problemas anteriormente citados). Vou falar mais especificamente do storage da NetApp, mas existem alternativas. Como não conheço bem as alternativas, não posso me pronunciar sobre a qualidade dessas soluções.

Storage NetApp família FAS3100

Storage NetApp família FAS3100

Basicamente a solução de seus piores pesadelos envolve armazenar seu banco de dados em uma dessas máquinas. Além delas terem uma performance muito boa para bancos de dados ( e estou tomando o Oracle como referência), elas já vêm de fábrica com alguns truques muito espertos para facilitar o backup (aliás, não só de bancos de dados). Não vou entrar em detalhes de quais são os grandes truques para que isto funcione desta forma (talvez em posts futuros), mas já aviso aos que não conhecem NetApp tudo o que eu disser vai parecer um exagero, o tipo de mentira que o pessoal de marketing gosta de contar, mas asseguro que é tudo de verdade e que muitos clientes (incluindo a própria Oracle) utilizam este tipo de solução.  Ok, vamos aos fatos que vão te fazer parar de sofrer com a menção da palavra “backup”.

  • Janela de backup: Imagine conseguir realizar backups full de seu banco de dados em menos de 2 minutos, mesmo que ele tenha TeraBytes de dados. Imagine realizar diversos backups full ao longo do dia. E imagine que isso não envolve copias brutas de todos os dados e tenha um impacto imperceptível no banco de dados e no storage. Tudo isso é real e possível! As palavras chaves para este truque são NetApp e Snapshot!
  • Tempo para recuperação: Da mesma forma que o backup é feito em um piscar de olhos, a recuperação também é muito rápida. Você nunca mais vai precisar passar a noite inteira rezando um terço do lado de seu servidor pedindo para que a recuperação de seu banco de dados corrompido funcione. A recuperação é tão rápida que você só tem tempo para uma “Ave Maria”.
  • Confiabilidade: O storage possui diversos mecanismos de hardware e software para garantir a integridade dos dados: RAID-DP, checagem e realocação de bad blocks, memória NVRAM com bateria, Snapshots, cluster ativo-ativo, replicação para outro storage. Além disso, quando se fala em Oracle, o NetApp é o storage mais barato que implementa o Oracle HARD.
  • Ponto de recuperação: Como os backups podem ser realizados com maior frequência, a probabilidade de perder dados em caso de algum problema no banco é bastante diminuída.
  • Hoje o NetApp possui softwares para integração com Microsoft SQL Server e Oracle (sem falar em Exchange, SAP e VMware). Mesmo assim, não é coisa do outro mundo integrá-lo com um MySQL ou outro banco por exemplo. Para ver o SnapManager para Oracle em funcionamento, assista o seguinte vídeo feito pelo Neto da NetApp.