Eu me lembro quando eu estava começando a estudar sobre a área de dados e lia sobre os bancos de dados chamados NoSQL. A história por trás da criação desses bancos era sempre muito parecida; os bancos de dados tradicionais não estavam atendendo as necessidades das empresas, então foi criada uma nova arquitetura de banco de dados que conseguisse suprir a necessidade. Isso ocorreu principalmente pelo crescente volume de dados e pela necessidade de respostas cada vez mais rápidas nas empresas, fazendo com que os bancos de dados tradicionais não fossem mais capazes de atender as demandas com eficiência. No cenário atual, é muito importante que os arquitetos e engenheiros de dados possuam uma boa noção sobre as características dos bancos de dados para saber quais as melhores opções para serem utilizadas em cada componente da arquitetura.

Começando pelos bancos de dados tradicionais, estes surgiram por uma necessidade de organizar os dados, armazenando-os de forma segura ao mesmo tempo que fornece meios simples para acesso aos dados armazenados. Os bancos de dados seguem um padrão chamado ACID onde implementam funcionalidades para garantir as quatro características que formam a sigla: Atomicidade, Consistência, Isolamento e Durabilidade. Além disso, estes bancos de dados adotaram uma linguagem padronizada para a consulta dos dados, o SQL. Os bancos de dados transacionais mais populares são o Postgres e o MySQL para projetos menores (ambos open source) e o Oracle e SQL Server para projetos maiores (ambos proprietários).

Talvez o banco de dados NoSQL mais conhecido seja o MongoDB. Este é um banco de dados open source que utiliza estruturas chamadas de documentos (muito semelhantes ao JSON) para armazenar os dados. Assim, o MongoDB foge do padrão tradicional de tabelas para um padrão de dados com um schema flexível, isto é, dados semi-estruturados. Além disso, ele também quebra o padrão ACID, assumindo que inconsistências eventuais podem ocorrer (as versões mais atuais do MongoDB aceitam transações ACID). Isso tudo trouxe ao MongoDB uma maior velocidade e versatilidade, principalmente no processo de escrita dos dados.

Voltando a pensar nos bancos de dados tradicionais nos por um instante. Em seu processo de armazenamento e recuperação dos dados eles mantém todos os dados armazenados no disco rígido e quando é solicitada a leitura de um grupo de dados selecionados, estes são levados para a memória RAM para poderem ser acessados e mantidos lá por um curto período de tempo enquanto houver instruções para que estes sejam acessados. Mas e se nós quiséssemos que todos os dados de um bando de dados ficassem disponíveis diretamente na memória RAM o tempo todo? Para isso foi criado o Redis, um banco de dados que segue a estrutura chave-valor e possui uma velocidade impressionante de acesso aos dados (e um custo igualmente impressionante). Este banco de dados é muito utilizado para fazer cache de dados.

O HBase é um banco de dados colunar que foi desenvolvido pela Google e se tornou um banco de dados open source, sendo agora mantido pela Apache Foundation. Comparado com os bancos de dados tradicionais, o HBase possui uma performance ruim ao lidar com pequenas quantidades de dados, porém sua performance ao lidar com grandes massas de dados é muito superior à dos bancos de dados tradicionais. Este tradeoff permite que este banco de dados seja uma boa opção para processos analíticos que utilizam grandes massas de dados. Esta arquitetura deu origem à diversos bancos de dados fornecidos pelos provedores de serviços na nuvem, como o BigQuery e o Redshift.

Podemos classificar estes bancos de dados em quatro categorias: Relacionais, Orientados à Documento, Chave-Valor e Colunares. Há ainda uma quinta categoria que não abordamos aqui, os bancos de dados de Grafos. Porém, não vamos explorar esse tipo de banco de dados neste artigo, assim como não exploramos a imensa maioria dos bancos de dados. Antes de finalizar este artigo é importante comentar que é muito comum ver projetos utilizando bancos de dados totalmente equivocados em seus processos. Eu já vi (em mais de uma ocasião) empresas utilizando bancos de dados colunares em processos transacionais e depois reclamando que o processo está demorando muito para retornar os dados. Também já vi projetos querendo realizar processos analíticos com um banco de dados MongoDB e reclamando que o schema quebra constantemente os processos. Como vimos no artigo Organização dos Dados Analíticos, dados transacionais (OLTP) e dados analíticos (OLAP) possuem características diferentes e por isso, muitas vezes, precisam de bancos de dados que atendam suas especificidades.