No universo da engenharia de dados, escolher o banco de dados e a estrutura de armazenamento pode ser a diferença entre uma aplicação rápida e escalável e uma que trava constantemente. Com tantas opções - bancos relacionais, NoSQL, colunares, grafos - como saber qual usar em cada situação?
Neste artigo, vamos explorar os principais modelos de bancos de dados disponíveis, desde os tradicionais bancos relacionais até as modernas estruturas NoSQL, passando por soluções especializadas como Redis e Amazon S3. Tudo isso com base nos conceitos apresentados por Felipe Rodrigues (Bidu), Engenheiro de Software Sênior na Doist, em sua aula sobre Estrutura e Arquitetura de Dados na Tera.
Você vai descobrir como a forma como organizamos nossos dados impacta diretamente a performance e as possibilidades de uso da nossa aplicação - e por que isso é fundamental para construir sistemas eficientes e escaláveis.
Um banco de dados é um sistema organizado de armazenamento de informações que permite a coleta, o armazenamento, a recuperação e a manipulação de dados de maneira estruturada e eficiente.
Nos dias atuais, existem vários tipos de bancos de dados, incluindo relacionais, NoSQL, colunares e outros, cada um com suas próprias características e usos específicos. A escolha do tipo certo depende das necessidades da aplicação: volume de dados, tipo de consultas mais frequentes, necessidade de escalabilidade, e muito mais.
Mas antes de explorarmos os tipos específicos de bancos de dados, precisamos entender um conceito fundamental
Antes de falarmos sobre tecnologias específicas, é importante entender um princípio fundamental: a forma como organizamos nossos dados afeta diretamente a performance das nossas operações.
Imagine que a gente tem o conjunto de informações que normalmente se encontrava numa lista telefônica antiga: nome, sobrenome e telefone das pessoas. Nós temos diversas formas de guardar esse tipo de informação.
Para encontrar o telefone do "Seu João Soares", por exemplo, precisamos:
São três operações apenas para buscar um telefone!
Agora considere a estrutura que a gente costuma ver em listas telefônicas reais: todas as informações de uma pessoa ficam juntas, organizadas alfabeticamente por sobrenome.
Determinar o telefone do Seu João Soares gasta apenas um passo: você encontra "Soares" e todas as informações estão ali, juntas.
Note que o conjunto de dados é exatamente o mesmo, mas simplesmente mudando o jeito que escolhemos guardar essas informações, permitimos que a operação de busca fosse muito mais eficiente e prática.
Como numa lista telefônica impressa temos muito mais buscas por informação do que inserções ou remoções, faz sentido considerar estruturas de dados que facilitem a busca. Esse mesmo raciocínio se aplica aos bancos de dados.
A modelagem de dados em computação é dividida em dois grandes campos: bancos de dados relacionais (SQL), que armazenam informações em tabelas estruturadas com linhas e colunas, e bancos NoSQL, que utilizam estruturas alternativas como documentos, grafos e chave-valor.
Esses dois campos representam filosofias diferentes de armazenamento e acesso à informação, cada um com suas vantagens e casos de uso específicos.
No primeiro campo, temos os bancos de dados relacionais. Essa família de banco de dados é bastante antiga - o trabalho sobre ela começou há mais de 50 anos, baseado no modelo relacional de Edgar Codd em 1970. Até hoje, ela é bastante utilizada em muitas plataformas diferentes por muitas empresas.
Todas as estruturas relacionais aceitam acesso através de uma linguagem de programação conhecida como SQL (Structured Query Language), e a representação de dados é em linhas e colunas de uma tabela.
O universo dos bancos relacionais é bem rico e inclui nomes como:
Imagine uma estrutura completa de banco relacional: você teria vários blocos diferentes, cada um representando uma tabela composta por linhas e colunas, com cada coluna tendo seu título específico. Cada bloco representa uma tabela - como countries, users, etc - e cada linha dentro do bloco representa uma coluna daquela tabela, junto de seu tipo de dado - id como número inteiro, full_name como "varchar" (tipo normalmente usado para representar textos), etc.
Entre essas tabelas, existem linhas conectando umas às outras. Essas linhas são as relações que podemos traçar entre as diferentes entidades - por isso o nome "banco relacional".
Uma das principais vantagens dos bancos de dados relacionais é o conjunto de garantias de integridade que eles oferecem. Essas garantias protegem seus dados de inconsistências e erros comuns:
NOT NULL impedem que registros sejam criados sem informações essenciais. Por exemplo, você pode exigir que todo usuário tenha obrigatoriamente um email e um nome completo.Essas garantias tornam os bancos relacionais particularmente adequados para aplicações que exigem consistência rigorosa de dados, como sistemas financeiros, ERPs e aplicações transacionais críticas.
Em oposição às estruturas relacionais, existem as mais modernas estruturas conhecidas como NoSQL.
SQL é a linguagem que utilizamos para interagir com bancos relacionais. Chamamos coletivamente as tecnologias alternativas aos bancos relacionais de NoSQL.
"The name 'NoSQL' is unfortunate, since it doesn't actually refer to any particular technology—it was originally intended simply as a catchy Twitter hashtag for a meetup on open source, distributed, nonrelational databases in 2009"
— Martin Kleppmann em "Designing Data Intensive Applications"
O termo NoSQL (ou NOSQL) surgiu como uma ruptura ao modelo tradicional de bancos relacionais nas últimas duas décadas. Ele representa um conjunto de tecnologias que armazenam dados, mas fogem do paradigma relacional.
Portanto, o termo não significa uma tecnologia em especial, mas sim um coletivo de softwares diferentes, cada um implementando sua forma particular de armazenar dados.
Inicialmente, NoSQL era lido como "No" do inglês - "não" SQL, o oposto de SQL. Porém, conforme o tempo passou, NoSQL começou a ser mais frequentemente grafado como NOSQL e "NO" lido como "Not Only" - "não apenas".
Hoje, algumas tecnologias NOSQL possuem características similares aos bancos SQL, mas mantendo suas estruturas próprias que divergem mais ou menos dos bancos tradicionais. É praticamente impossível fazer qualquer afirmação genérica sobre elas além de "elas não são bancos relacionais clássicos".
O campo do NoSQL é bastante amplo e contém uma série de estruturas alternativas à estrutura relacional, como:
Nesse caso, temos estruturas muito especializadas para certos usos específicos em certas plataformas específicas.
Bancos colunares são bancos de dados que armazenam informações agrupadas por coluna, e não por linha. Enquanto bancos relacionais tradicionais gravam todos os dados de um registro juntos (linha a linha), bancos colunares gravam todas as informações de uma mesma coluna juntas, o que acelera enormemente operações analíticas como cálculo de médias, medianas e agregações em grandes volumes de dados.
Essa foi a primeira quebra com relação ao modelo relacional tradicional, e é especialmente útil para aplicações de data warehousing e business intelligence.
Bancos relacionais clássicos armazenam a informação internamente linha a linha. Esses detalhes internos raramente são importantes para desenvolvedores que utilizam esses bancos, porém nesse caso temos uma questão interessante.
No banco relacional comum, as informações são gravadas agrupadas em linhas. Ou seja, suponha que você guarde de um usuário o nome, a idade, o e-mail e uma série de outros campos relevantes. Todas as informações desse usuário serão gravadas em setores próximos, em uma única célula de memória no disco ou em células ligadas.
Armazenar linha a linha significa que todas as colunas de um registro são armazenadas juntas, e as do próximo registro podem não estar próximas na memória. Isso faz com que seja muito fácil fazer inserção de informações - você escreve todos os dados de uma vez no mesmo lugar.
Mas isso é um problema quando queremos calcular algo que cruza vários registros. Por exemplo, determinar qual a mediana da idade de todas as pessoas no nosso banco - precisamos acessar a coluna "idade" de milhares de registros que estão espalhados pela memória.
Nos bancos colunares, por outro lado, cada coluna dessas informações será gravada em células independentes. Uma forma alternativa de armazenar os dados é armazenar as informações de cada coluna juntas entre si. Isso garante que as informações da coluna estejam juntas, acelerando enormemente essas operações colunares.
Isso permite que a gente faça análises agregadas de dados - calcular médias, medianas e outras métricas estatísticas sobre todos os valores de uma coluna - de maneira muito mais rápida do que numa estrutura relacional comum.
Algumas plataformas que implementam banco colunar e são famosas:
Essas plataformas são muito boas quando estamos fazendo análise de dados em grandes volumes de informação. Elas são bastante performáticas e permitem que a gente faça consultas analíticas com mais velocidade do que no banco relacional tradicional.
O Amazon Redshift e o Google BigQuery são duas tecnologias queridas em aplicações de big data, e elas são soluções de data warehousing, conceito fundamental para análise de dados em larga escala.
Bancos de documentos são bancos de dados NoSQL que armazenam informações em formato de documentos (JSON, BSON ou XML) com estrutura flexível. Diferente dos bancos relacionais que exigem schemas rígidos, bancos de documentos permitem que cada registro tenha campos diferentes, facilitando a inserção rápida de dados e a adaptação a mudanças de estrutura sem necessidade de migrações complexas.
Dentro do universo de armazenamento de documentos, um dos mais famosos é o MongoDB, amplamente utilizado em aplicações web modernas e APIs.
Enquanto bancos colunares são uma ruptura no modo de armazenamento interno de dados, bancos orientados a documentos rompem com o quão estruturada a informação deve ser.
Tanto em bancos colunares quanto em relacionais, normalmente precisamos definir quais colunas queremos que uma tabela tenha. Os registros inseridos devem possuir, no máximo, os campos marcados. Embora alguns campos possam ser marcados como obrigatórios, não é possível inserir um registro que contém um campo novo sem realizar alguma operação que altere a estrutura da tabela em si.
No MongoDB e na estrutura de documentos como um todo, temos garantias um pouco menos rígidas com relação aos campos que vão estar presentes em cada documento (fazendo uma analogia com registros em bancos relacionais).
Bancos de Documentos quebram completamente com essa visão. Não é necessário definir uma estrutura inicial e tampouco mantê-la entre registros. Num documento, por exemplo, a gente pode ter alguns campos como primeiro nome, segundo nome, email, etc. Mas podemos, nesse mesmo repositório, inserir outro documento que não possui todas essas informações ou que possui campos a mais.
Uma forma interessante de pensar em bancos de documentos é compará-los com pastas de arquivo. Imagine que você tem uma pasta física com diversos documentos - alguns podem ser contratos completos com múltiplas páginas, outros podem ser notas fiscais simples, outros ainda podem ter anexos e informações extras.
Todos esses documentos estão na mesma pasta, mas não precisam ter o mesmo formato ou estrutura. Da mesma forma, em um banco de documentos como o MongoDB, você pode ter documentos com estruturas completamente diferentes coexistindo no mesmo repositório.
Para entender melhor como funciona um documento no MongoDB, veja este exemplo de um perfil de usuário armazenado em formato JSON:
{
"nome": "Bill",
"sobrenome": "Gates",
"endereço": {
"logradouro": "Rua das Acácias",
"número": 123,
"bairro": "Centro",
"cidade": "São Paulo"
},
"telefones": [
{
"tipo": "celular",
"número": "(11) 98765-4321"
},
{
"tipo": "trabalho",
"número": "(11) 3456-7890"
}
],
"empresa": "Microsoft",
"cargo": "Co-fundador"
}Note como esse documento possui estruturas aninhadas (como o endereço completo dentro do campo "endereço") e arrays (como a lista de telefones). Isso seria muito mais complexo de modelar em um banco relacional tradicional, que exigiria múltiplas tabelas relacionadas.
Outro usuário no mesmo banco poderia ter campos completamente diferentes, como "hobbies", "redes_sociais" ou "certificações", sem necessidade de alterar nenhuma estrutura pré-definida.
Nos bancos baseados em documentos, possuímos essas garantias um pouco menos rígidas de estrutura, que garantem que a inserção de dados será bastante rápida.
Porém, isso também pode causar problemas ou quedas de performance quando precisamos correlacionar informações contidas em diversos tipos de documentos diferentes - afinal, não há garantia de que todos os documentos terão os mesmos campos.
Bancos de grafos são bancos de dados NoSQL especializados em armazenar e consultar relacionamentos complexos entre dados. Utilizando a estrutura de grafos da ciência da computação, eles representam informações como nós (entidades) conectados por arestas (relacionamentos), sendo extremamente eficientes para queries que envolvem múltiplos níveis de conexões, como redes sociais, sistemas de recomendação e detecção de fraudes.
Um conceito bastante importante em ciência da computação é o conceito de grafo. Um grafo nada mais é do que uma rede de conexões - talvez você já tenha ouvido falar sobre como as pessoas no mundo estão separadas por "6 graus de separação". Esse é exatamente o resultado da teoria dos grafos.
Grafos são uma das estruturas mais queridas dentro da computação. Um grafo nada mais é do que uma rede. Em sua forma mais simples, eles possuem apenas nós e ligações entre eles.
Em situações mais elaboradas, podem possuir orientação - "é possível ir do ponto 6 ao ponto 4, mas não do ponto 4 ao ponto 6" - e também as ligações entre pontos podem possuir propriedades, como distância - "a distância do ponto 4 ao ponto 5 é 50".
Para entender melhor como funcionam os bancos de grafos, imagine uma rede social simples. Nela, temos nós heterogêneos - ou seja, nós de diferentes tipos que representam coisas diferentes:
As arestas (conexões) entre esses nós podem representar diferentes tipos de relacionamentos:
Com essa estrutura em grafo, queries complexas se tornam muito eficientes:
Essa capacidade de modelar e consultar nós heterogêneos com relacionamentos complexos é o que torna bancos de grafos tão poderosos para redes sociais, sistemas de recomendação e análise de conexões.
Grafos estão no centro de alguns problemas famosos:
O banco de dados Neo4j é um armazenamento NOSQL que utiliza grafos. Nele podemos lançar diversos pontos, suas relações e então calcular métricas que vêm da teoria de grafos. A modelagem é mais delicada, porém poderosa nas situações em que se encaixam.
Um banco em grafo é muito interessante quando precisamos computar relações complexas entre diversas entidades. Perguntas do tipo "qual é a distância entre dois nós?" são extremamente eficientes em bancos de grafos.
Toda vez que você, por exemplo, utiliza algum aplicativo de rotas no celular para calcular a menor distância entre dois pontos, o que está acontecendo por baixo dos panos é uma consulta em grafos.
Esse tipo de informação é bastante útil para:
Bancos chave-valor são bancos de dados NoSQL que armazenam dados como pares simples de chave e valor, similar a um dicionário. Cada chave única é associada a um valor (que pode ser um texto, número, objeto ou até um arquivo binário), permitindo buscas extremamente rápidas e escalabilidade horizontal, sendo ideais para cache, gerenciamento de sessões e configurações de aplicações.
Essas estruturas se comportam exatamente como um dicionário que usamos no dia a dia: uma chave utilizada para busca associada a um valor que é a informação que nos interessa.
Uma das principais plataformas que fazem armazenamento assim é o Amazon DynamoDB.
É um tipo de armazenamento totalmente gerenciado, o que significa que você não precisa instalar ou configurar servidores. Você contrata como serviço da Amazon e ele é bastante escalável e tem muita performance para fazer buscas por informação.
Uma coisa importante de notar em bancos de dados não relacionais é que existe uma correlação muito forte entre a estrutura e o servidor que implementa aquela estrutura.
O MongoDB, por exemplo, funciona como armazenamento de documentos. Ele não é o único servidor que armazena documentos, mas ele só armazena documentos. O BigQuery é característica do servidor armazenar informações em forma de colunas.
Nos bancos relacionais, por outro lado, temos uma série de tecnologias e servidores diferentes que todos utilizam o armazenamento relacional.
Redis é um banco de dados chave-valor em memória RAM, conhecido por sua performance extremamente rápida. Por armazenar todos os dados na memória ao invés de disco, o Redis é ordens de magnitude mais rápido que outros bancos, sendo ideal para cache de aplicações, filas de mensagens, sessões de usuário e rate limiting, apesar de seus dados serem efêmeros (desaparecem quando o servidor é desligado).
Redis merece destaque especial entre os bancos chave-valor. Ele se comporta como um dicionário: existe uma chave que identifica a informação e um valor associado àquela informação.
Exemplos: nome = bidu, banco_de_dados = redis, país = Brasil.
A característica do Redis é que ele funciona todo na memória RAM da máquina. Por funcionar na memória RAM, ele é bastante rápido - algumas ordens de magnitude mais rápido do que qualquer uma das outras plataformas que vimos até agora.
A grande desvantagem é que, para ele ser em memória RAM, toda informação que existe nele desaparece assim que o computador é desligado.
Isso faz com que o Redis pertença a uma categoria de armazenamento de dados conhecida como armazenamentos efêmeros. Eles não são duradouros em memória como um banco de dados normal, que você pode desligar o computador, fazer atualizações e eles continuarão armazenados.
Você pode estar pensando: "Mas para que serve um banco de dados que some quando o computador desliga?"
A questão é que, como ele é bastante rápido, é muito utilizado para fazer armazenamento temporário de informações que precisam de acesso extremamente rápido.
Por exemplo, suponha que você faça login num sistema. O sistema pode guardar num Redis a informação de que seu usuário fez login de tal endereço em tal lugar e usar essa informação para agilizar outras partes do processamento.
Casos de uso comuns do Redis:
Object Storage (armazenamento de objetos) é uma arquitetura de armazenamento completamente não estruturado que permite guardar qualquer tipo de arquivo binário. Ao invés de bancos de dados tradicionais, sistemas como Amazon S3, Google Cloud Storage e Azure Blob Storage armazenam arquivos completos (imagens, vídeos, documentos, backups) de forma escalável e durável, sendo a solução ideal para mídia de usuários e dados não estruturados.
Essa classe de armazenamento é bastante usada em aplicações modernas e representa uma categoria à parte dos bancos de dados tradicionais.
O exemplo mais famoso é o Amazon S3 e o Google Cloud Storage também é bastante utilizado atualmente.
O armazenamento de objeto é completamente não estruturado. Você pode literalmente colocar qualquer coisa que quiser lá dentro: desde um arquivo de texto até uma foto, um vídeo ou qualquer tipo de arquivo binário.
Suponha, por exemplo, que você está fazendo um sistema de cadastro de usuário em que aceita uma foto do usuário e um vídeo de apresentação.
Normalmente é uma má ideia guardar essas informações dentro do banco de dados, seja ele relacional ou não, porque essas informações binárias são bastante pesadas e não são exatamente buscáveis para um banco comum.
A técnica comum é:
Dessa forma, seu banco de dados fica leve e otimizado para buscas, enquanto os arquivos pesados ficam em um sistema especializado para isso.
Redis e S3 são duas tecnologias mais utilizadas pelos times de desenvolvimento do que pelos times de análise em si.
O Redis, por sua velocidade extrema, é perfeito para armazenar informações temporárias que precisam de acesso rapidíssimo durante a execução da aplicação. O S3, por outro lado, é o destino ideal para todo tipo de arquivo que a aplicação precisa armazenar de forma durável e barata.
Enquanto bancos relacionais e NoSQL são frequentemente usados diretamente por analistas de dados e cientistas de dados, Redis e S3 são mais comuns na infraestrutura das aplicações, trabalhando nos bastidores para garantir performance e confiabilidade.
Para facilitar o entendimento das principais diferenças entre esses tipos de bancos de dados, confira a tabela comparativa abaixo:
| Tipo | Tecnologias | Melhor Para | Performance | Estrutura |
|---|---|---|---|---|
| Relacional (SQL) | PostgreSQL, MySQL, SQL Server | Transações, dados estruturados, integridade referencial | Leitura/Escrita balanceada | Linhas e colunas Schemas rígidos |
| Colunar | BigQuery, Redshift, Snowflake | Analytics, agregações, data warehousing | Leitura muito rápida Escrita lenta | Dados por coluna Compressão eficiente |
| Documentos | MongoDB, CouchDB, Firestore | Dados semi-estruturados, schema flexível, APIs | Escrita rápida Leitura rápida | JSON/BSON Schema flexível |
| Grafos | Neo4j, Amazon Neptune, ArangoDB | Redes sociais, recomendações, detecção de fraudes | Queries de relacionamento | Nós e arestasRelações complexas |
| Chave-Valor | DynamoDB, Cassandra, Riak | Cache, sessões, configurações | Leitura muito rápida Escrita muito rápida | Pares chave-valorSimples |
| Em Memória | Redis, Memcached | Cache, sessões, filas, rate limiting | Extremamente rápido | Efêmero RAM only |
| Object Storage | Amazon S3, Google Cloud Storage, Azure Blob | Arquivos, imagens, vídeos, backups | EscalávelDurável | Não estruturado Qualquer formato |
Tabela comparativa dos principais tipos de bancos de dados e suas características
Neste post listamos 9 tipos de banco de dados.
Neste artigo, vimos diversas formas de estruturar e guardar nossos dados, assim como as vantagens e desvantagens que cada uma delas possui.
Compreender esses diferentes modelos é fundamental para tomar decisões arquiteturais corretas em seus projetos. Cada tipo de banco de dados foi otimizado para casos de uso específicos, e escolher a ferramenta certa pode fazer toda a diferença na performance e escalabilidade da sua aplicação.
Lembre-se: não existe um banco de dados "melhor" em absoluto. Existe o banco de dados mais adequado para cada problema. Muitas vezes, a melhor solução é combinar diferentes tipos de bancos em uma mesma aplicação, aproveitando os pontos fortes de cada um.
No próximo artigo da série, vamos explorar conceitos fundamentais de arquitetura de dados: Data Lake, Data Warehouse e Data Mart. Essas são estruturas essenciais para organizar grandes volumes de dados em aplicações modernas.
Se você quer se aprofundar nesse universo, conheça mais sobre engenharia de dados e estruturas de dados.