Um pouco sobre a história dos bancos de dados – Parte III

 

Se não está na Internet, então não existe!

A nova era do NoSQL

O crescimento da Internet mudou tudo na informática. Aplicações relacionadas às redes sociais como Twitter e Facebook trouxeram novos desafios e o crescente uso de smartphones criou uma explosão de dados. Enquanto os bancos de dados relacionais estavam orgulhosos dos seus Datawarehouses, com seus relatórios complexos, OLAP, DataMining, VLDB, ETLs e por aí vai, surge a era do Big Data. Novos desafios numa escala sem precedentes surgem. Os bancos de dados relacionais nasceram com o conceito de ACID arraigado em suas premissas. Porém imagine que você administra o banco de dados de uma rede social como o Twitter. O que é mais importante para você, a disponibilidade  do serviço com bom desempenho ou a consistência dos dados? Neste cenário perder a informação de alguns tweets não é tão importante quanto manter o serviço no ar. Assim surge o teorema CAP, onde uma nova geração de bancos de dados abre mão da consistência de dados em nome da escalabilidade horizontal, um ponto fraco nos bancos de dados relacionais.Outro ponto interessante entre os bancos de dados NoSQL é a predominância esmagadora de soluções livres, enquanto entre os banco de dados relacionais, as versões proprietárias ainda dominam. Existem vários tipos de bancos de dados NoSQL (conhecidos como “No SQL” e depois como “Not Only SQL”): chave-valor, orientados a documentos, orientados a grafos, orientados a eventos, temporais, XML, etc. Comentarei aqui apenas os 3 mais utilizados atualmente.

Bancos de dados Chave-Valor

Foram criados dezenas de tipos de bancos de dados chave-valor, a maioria com persistência apenas em memória. Bancos de dados chave-valor tem um desempenho absurdo, pois não dependem da persistência em discos e nem controles de transações. Também podem se espalhar por dezenas de servidores de forma transparente. São muito eficientes para problemas de baixa complexidade. O Memcached, criado em 2003 foi o primeiro a se tornar popular e foi muito utilizado como cache de sites na internet. Atualmente o Redis é banco de dados do tipo chave-valor mais popular do mercado. Lançado em 2009, ele é também o 9º banco de dados mais popular no placar geral.

Bancos de dados orientados a documentos

Nos anos 2000, o XML ganha ampla aceitação no mercado e muitos bancos de dados implementam extensões para armazenar e manipular dados em XML. Em 2006 surge o uma especificação no padrão SQL:2006 para o armazenamento de XML. Novamente tivemos também bancos de dados especializados em manipular XML e até implementações do XQuery que se tornou uma recomendação do W3C em 2007.

Lançado em 2009, o MongoDB é o banco de dados orientado a documentos mais bem sucedido hoje. É o 5º mais popular entre todos os bancos de dados, logo depois do PostgreSQL.  Ele armazena dados no formato JSON, formato que ganhou o mercado nos anos 2010 na internet. Em 2016, o PostgreSQL lança a primeira implementação em bancos de dados relacionais eficiente para armazenar JSON. Outros bancos de dados também se tornaram capazes de armazenar dados no formato JSON, sendo lançado uma padronização no SQL:2016 onde o Oracle é o banco de dados mais aderente ao padrão ISO.

Bancos de dados orientados a grafos

Este tipo de banco de dados, resolve problemas que são particularmente chatos em bases relacionais: consultas hierárquicas. A estrutura de grafos permite modelar os dados em termos de relacionamentos mais naturais e flexíveis, resolvendo problemas complexos de forma muito mais simples em comparação com os bancos relacionais. Nesta categoria, o Neo4j é o mais popular, figurando na posição 21 no ranking geral.

A geração DevOps e a nuvem

A computação em nuvem ganhou o mundo e muitos bancos de dados que ficavam trancafiados nos CPDs passaram a flutuar por aí. Primeiro vieram as VMs, e por fim os serviços de provisionamento na nuvem com o PaaS, IaaS, SaaS, Pizza as a Service e por aí vai. Na nuvem, as coisas são voláteis. Uma das coisas mais complicadas para os bancos de dados tradicionais é garantir um bom desempenho em disco, o que é um problema complexo quando os discos são compartilhados na nuvem. Além disso, alguns bancos de dados tem uma relação muito íntima com o hardware. Na nuvem, este acoplamento entre hardware e software não faz muito sentido e você tem que trabalhar de outra forma para conseguir aproveitar as vantagens da nuvem sem drenar todo o seu orçamento.

Uma das soluções para utilizar melhor a nuvem é ter um provisionamento ágil, quebrar a sua aplicação enorme em vários pedaços menores, cada uma com seu próprio banco de dados. É o que se chama de microserviços. Gerenciar uma estrutura onde temos vários deploys acontecendo na produção diariamente, exige uma nova forma de trabalho, e é aí que surge a cultura DevOps, na qual a automação, a integração entre desenvolvimento, DBAs e sysadmins vira uma constante.

Outra característica comum nos dias de hoje é a presença de bancos de dados de vários tipos ao lado do tradicional banco de dados relacional. O banco de dados central e monolítico perdeu espaço para opções mais simples e especializadas para cada situação.

Conclusões

O trabalho de pesquisar sobre a história dos bancos de dados nos traz algumas informações interessantes:

  • Ser melhor não significa ser maior. Algumas vezes tecnologias melhores fazem menos sucesso pelas condições em que são lançadas. O QUEL poderia ser melhor que o SQL, mas o poder da IBM em criar um padrão se mostrou forte, assim como o lançamento do IBM-PC no começo da década de 80 que criou o padrão dos microcomputadores para o mercado;
  • Seguir um padrão realmente importa. O padrão SQL teve um peso muito importante no mercado de bancos de dados. Mesmo numa era NoSQL, o padrão SQL continua sendo muito relevante, mesmo depois de quase 50 anos de existência. Os bancos de dados orientados a objetos não tinham um padrão e uma teoria bem definida. Havia um frisson no seu lançamento de que os bancos de dados relacionais iriam desaparecer com o sucesso dos bancos de dados orientados à objeto;
  • Novas demandas requerem novas soluções. O MySQL foi o banco de dados que surfou nesta onda e se espalhou por toda a internet, mesmo sendo muito inferior a maioria dos concorrentes. Mas era simples, barato e leve. O NoSQL atende demandas específicas onde os bancos de dados relacionais não são tão eficientes e garantiram seu espaço no mercado;
  • Grandes empresas podem cair sim. A IBM tem mais de um século, criou um número enorme de novas tecnologias e foi uma das maiores empresas do planeta. Seus funcionários ganharam 5 prêmios Nobel. Foi a maior detentora de patentes do planeta e hoje não é mais tão grande assim. Grandes empresas tem grande capacidade de investimento em pesquisa, mas são péssimas em se adaptar às novas tendências.

Sobre o futuro…

Brincar de futurologia é sempre um perigo. Dizem que se a frase “quem não conhece a história está condenado a repeti-la” fosse verdade, ninguém casaria duas vezes! Outro ponto que devemos observar é que o mercado de banco de dados se move lentamente. DBAs são pessoas conservadoras e resistentes à mudanças. Mas me arrisco a alguns palpites aqui, que acho bastante válidos:

  • A nuvem não vai dominar o mundo, mas vai continuar crescendo e provavelmente vai engolir mais da metade do mercado. Existem muitas aplicações de grande porte que não vão se adaptar bem à nuvem, por questões de desempenho, por questões legais, segurança, custo, etc. Mas aos poucos, a maior parte das novas aplicações nascerão na nuvem. Quem não se adaptar vai dançar;
  • A maioria dos bancos de dados rodarão em Linux. O lançamento do SQL Server para Linux não foi um mero acidente, é uma tendência de mercado clara. Além disso, parece que nos últimos testes o SQL Server já roda mais rápido em Linux do que em Windows.
  • Assim como o Linux dominou o mercado de sistemas operacionais, particularmente na nuvem, os bancos de dados livres dominarão o mercado, pelo menos nas aplicações mais comuns. Os bancos de dados livres já tem a características suficientemente boas para lidar com a maior parte dos problemas comuns. Os bancos de dados proprietários  se tornarão soluções de nicho, como são hoje os supercomputadores e sistemas operacionais mais exóticos. Em quase 5 anos, os bancos de dados livres pularam de 35,5% para 46,2% do ranking do DB Engines;
  • Cada vez mais a flexibilidade vai se tornar um fator decisivo ao escolher um banco de dados. A capacidade de estender as capacidades e de conversar nativamente com outros bancos de dados e serviços é fundamental para o sucesso e evolução dos projetos que começam hoje;
  • Os bancos de dados relacionais continuarão dominando o mercado e incorporando algumas características de outros bancos de dados NoSQL. Outras soluções não relacionais continuarão surgindo, mas entre as centenas de soluções que surgiram recentemente deverão sumir em favor de algumas poucas opções mais populares. Apesar do rápido crescimento dos bancos de dados NoSQL, os bancos de dados relacionais ainda respondem por quase 80% do ranking do DB Engines.

Compartilhe

Você pode gostar

pg_hba.conf

Introdução O arquivo pg_hba.conf (PostgreSQL Host-Based Authentication) é uma peça fundamental na configuração de segurança de qualquer instância PostgreSQL. Ele define as regras de autenticação

Tuning de SO (no Linux)

Introdução Tuning refere-se ao processo de ajustar e otimizar o desempenho de um sistema, software ou aplicação. A otimização do sistema operacional é uma etapa

Tipos de cargas dos bancos de dados

Introdução Cargas de dados referem-se aos diferentes tipos de operações e transações que um banco de dados deve processar. Essas cargas variam conforme o tipo

plugins premium WordPress