Bancos de dados

Em sistemas do mundo real, as aplicações geram e dependem constantemente de dados como contas de usuário, transações, mensagens e logs. Armazenar esses dados diretamente na memória da aplicação não é suficiente, porque a memória é temporária e desaparece quando o programa para ou trava.

Os bancos de dados resolvem isso fornecendo armazenamento durável. Os dados são gravados em disco de uma forma que sobrevive a reinicializações e falhas do sistema. É isso que permite que sistemas como plataformas bancárias, redes sociais e sites de e-commerce mantenham estado de longo prazo.

Além do armazenamento, os bancos de dados fornecem formas estruturadas de acessar os dados. Em vez de percorrer arquivos manualmente, os desenvolvedores podem usar consultas para recuperar exatamente o que precisam. Por exemplo, buscar um usuário por e-mail ou recuperar todos os pedidos da última semana.

Os bancos de dados também impõem regras de consistência, garantindo que os dados permaneçam válidos mesmo quando várias operações ocorrem ao mesmo tempo. Sem isso, os sistemas corromperiam os dados facilmente sob acesso concorrente.

Em alto nível, o banco de dados atua como a fonte de verdade do sistema. A aplicação processa as requisições, mas o banco de dados é responsável por armazenar e gerenciar os dados dos quais essas requisições dependem.

Bancos de dados SQL seguem o modelo relacional, no qual os dados são organizados em tabelas. Cada tabela representa uma entidade (como usuários ou pedidos), e cada linha representa um registro dentro dessa entidade.

Um recurso importante é o schema. Antes de armazenar os dados, você define a estrutura, incluindo os tipos de coluna e as restrições. Isso garante que todos os dados sigam um formato consistente, o que reduz erros e mantém a integridade.

Os relacionamentos entre tabelas são centrais nos sistemas SQL. Por exemplo, uma tabela de usuários pode ser vinculada a uma tabela de pedidos por meio de um user_id, permitindo que o sistema conecte dados relacionados de forma eficiente.

Bancos de dados SQL também oferecem recursos poderosos de consulta. Usando joins, filtros e agregações, os desenvolvedores podem recuperar conjuntos de dados complexos de várias tabelas em uma única consulta.

Essa abordagem estruturada oferece forte consistência e confiabilidade, razão pela qual bancos de dados SQL como PostgreSQL e MySQL são amplamente usados em sistemas nos quais a correção e a integridade dos dados são críticas.

Ao contrário dos bancos de dados SQL, os sistemas NoSQL não exigem um esquema predefinido. Isso significa que cada registro pode ter uma estrutura diferente, tornando-os úteis quando os dados são não estruturados ou mudam com frequência.

Diferentes bancos de dados NoSQL são otimizados para diferentes casos de uso. Bancos de dados de documentos, como o MongoDB, armazenam objetos semelhantes a JSON; armazenamentos chave-valor, como o Redis, oferecem consultas extremamente rápidas; bancos de dados wide-column, como o Cassandra, lidam com enormes conjuntos de dados distribuídos; e bancos de dados de grafo modelam relacionamentos diretamente.

Essa flexibilidade torna os sistemas NoSQL mais fáceis de escalar horizontalmente em vários servidores, o que é crítico para aplicações em grande escala que lidam com alto tráfego.

A desvantagem é que muitos sistemas NoSQL sacrificam consistência estrita ou consultas relacionais complexas em favor de desempenho e escalabilidade. A escolha entre SQL e NoSQL depende da estrutura dos dados e dos requisitos do sistema.

Quando uma consulta é executada sem um índice, o banco de dados precisa verificar cada linha, uma por uma, para encontrar os resultados correspondentes. Isso é chamado de varredura completa da tabela, e fica extremamente lento à medida que o conjunto de dados cresce.

Um índice funciona como uma estrutura de consulta rápida (semelhante ao índice de um livro). Em vez de varrer tudo, o banco de dados pode ir diretamente até a localização dos dados. Isso reduz significativamente o tempo da consulta, especialmente em tabelas grandes.

Por exemplo:

CREATE INDEX idx_users_email
ON users(email);

Isso cria um índice na coluna email, permitindo que consultas como "encontrar usuário por email" sejam executadas muito mais rápido.

No entanto, índices não são gratuitos. Toda vez que dados são inseridos, atualizados ou excluídos, o índice também precisa ser atualizado. Isso torna as gravações um pouco mais lentas e aumenta o uso de armazenamento.

Um bom design de banco de dados envolve escolher as colunas certas para indexar — normalmente aquelas usadas com frequência em condições de busca, filtros ou joins.

Em muitos sistemas, as operações não são isoladas. Por exemplo, transferir dinheiro entre duas contas exige atualizar ambos os saldos. Se uma atualização for bem-sucedida e a outra falhar, o sistema fica inconsistente.

As transações resolvem isso agrupando as operações:

BEGIN
UPDATE account A
UPDATE account B
COMMIT

Se alguma etapa falhar durante a execução, o banco de dados realiza um rollback, desfazendo todas as alterações anteriores na transação.

Isso garante que atualizações parciais nunca ocorram. Ou toda a operação é concluída com sucesso, ou o sistema retorna ao seu estado anterior.

As transações são essenciais em sistemas onde a correção é importante, como sistemas financeiros, controle de estoque e sistemas de reservas. Sem elas, falhas ou problemas de concorrência corromperiam os dados com facilidade.

ACID é um conjunto de quatro propriedades que bancos de dados relacionais लागूam para garantir a correção durante as transações.

Atomicidade significa que uma transação é indivisível. Se qualquer etapa falhar, toda a transação é revertida, evitando atualizações parciais.

Consistência garante que, após a conclusão de uma transação, o banco de dados siga todas as regras, como restrições, relacionamentos e validade dos dados. Estados inválidos nunca são permitidos.

Isolamento garante que várias transações executadas ao mesmo tempo não interfiram umas com as outras. Cada transação se comporta como se estivesse sendo executada sozinha, mesmo em um sistema concorrente.

Durabilidade garante que, uma vez que uma transação seja confirmada, os dados sejam armazenados permanentemente, mesmo que o sistema falhe imediatamente depois.

Juntas, essas propriedades permitem que os bancos de dados lidem com falhas, concorrência e operações complexas sem corromper os dados. Elas são fundamentais para construir sistemas confiáveis em que a correção importa.

Quando você envia uma consulta para um banco de dados, ele não a executa cegamente passo a passo. Em vez disso, o banco primeiro analisa a consulta usando um componente chamado planejador de consultas.

O planejador avalia várias maneiras possíveis de executar a consulta e seleciona a mais eficiente. Isso inclui decisões como usar ou não um índice, como fazer o join entre tabelas e a ordem das operações.

Por exemplo, se uma consulta busca um usuário por e-mail e existe um índice nessa coluna, o banco de dados usará o índice em vez de percorrer cada linha. Isso pode reduzir o tempo de execução de segundos para milissegundos em grandes conjuntos de dados.

O resultado desse processo é um plano de execução, que define exatamente como a consulta será executada internamente.

A otimização de consultas se torna crítica à medida que os dados crescem. Consultas mal otimizadas podem causar respostas lentas, alto uso de CPU e gargalos no sistema, enquanto consultas bem otimizadas mantêm os sistemas rápidos e escaláveis.

A replicação é usada para manter várias cópias dos mesmos dados em diferentes servidores de banco de dados. A configuração mais comum é o modelo primário-réplica.

Nesse modelo, o banco de dados primário lida com todas as operações de gravação. Quaisquer alterações feitas são então propagadas para os bancos de dados réplica. Essas réplicas mantêm cópias dos dados e podem atender solicitações de leitura.

Essa configuração oferece vários benefícios. Se o banco de dados primário falhar, uma réplica pode assumir, melhorando a disponibilidade do sistema. Ela também permite que os sistemas escalem o tráfego de leitura distribuindo as consultas entre várias réplicas, em vez de sobrecarregar um único banco de dados.

No entanto, a replicação introduz complexidade. Pode haver pequenos atrasos entre o momento em que os dados são gravados no primário e quando eles aparecem nas réplicas (replication lag). Isso significa que as réplicas nem sempre terão os dados mais atualizados.

Apesar dessa desvantagem, a replicação é uma técnica essencial para construir sistemas backend escaláveis e tolerantes a falhas.

À medida que os dados crescem, um único servidor de banco de dados eventualmente se torna um gargalo. A fragmentação resolve isso dividindo os dados em partes menores, com cada shard armazenado em um servidor diferente.

Por exemplo:

Shard 1 → users 1–1M
Shard 2 → users 1M–2M
Shard 3 → users 2M–3M

As requisições são roteadas para o shard correto com base nos dados acessados. Isso permite que os sistemas escalem horizontalmente e lidem com cargas de trabalho muito maiores.

A desvantagem é o aumento da complexidade, especialmente quando as consultas precisam de dados de vários shards.