Bancos De Dados Nao Relacionais

O que você realmente precisa saber antes de escolher um banco não relacional

A maioria dos desenvolvedores chega nos bancos de dados nao relacionais porque o banco relacional não estava aguentando a carga. Essa é a realidade. Você começa com PostgreSQL, tudo funciona bem, e de repente as consultas com joins começam a levar segundos onde levavam milissegundos. A primeira reação é otimizar índices, refatorar queries, tentar fazer o SQL funcionar. Às vezes funciona. Na prática, geralmente não funciona de forma sustentável. Existem quatro categorias principais que você precisa entender antes de tomar qualquer decisão. Document store, como MongoDB e Couchbase, onde cada documento é uma estrutura JSON autossuficiente. Key-value store, como Redis e DynamoDB, que são essencialmente hash maps gigantes distribuídos. Column-family store, como Cassandra e ScyllaDB, organizados por colunas em vez de linhas. E graph database, como Neo4j e ArangoDB, projetados para relações complexas entre entidades.

Por que bancos de dados nao relacionais se tornaram padrão em muitos projetos

O argumento mais comum é escalabilidade horizontal. Bancos relacionais tradicionais escalam verticalmente, ou seja, você compra hardware maior. Isso tem um limite físico e financeiro. Bancos não relacionais foram construídos desde o início pensando em distribuição, com sharding automático e replicação assíncrona. Isso significa que adicionar nós ao cluster é uma operação de infraestrutura, não de redesign de schema. Na prática, eu vi um sistema de e-commerce que processava cerca de 800 requisições por segundo nas horas de pico usando MySQL. Quando migraram para MongoDB com sharding em três réplicas, o throughput subiu para aproximadamente 4.500 requisições por segundo com latência média de 12ms. A migração levou onze dias. O problema foi que a equipe precisou reescrever completamente a camada de acesso a dados. Queries que usavam five tables join agora precisavam de embedded documents ou múltiplas queries sequenciais. O lado que ninguém menciona é que query flexibility tem um custo. Quando você não tem schema fixo, campos podem aparecer e desaparecer entre atualizações. Document store permite isso, o que é conveniente durante o desenvolvimento mas gera inconsistências silenciosas em produção. Um campo que era string virou number em uma atualização que ninguém documentou, e a query que assumia string retornava resultados errados sem nenhum erro explícito.

Um problema real que aconteceu comigo

Eu trabalhei num projeto onde precisávamos armazenar eventos de streaming com bilhões de registros por mês. A solução parecia óbvia: Cassandra. Escrita rápida, distribuição nativa, tolerância a falhas por design. O problema surgiu quando precisamos fazer queries de agregação por intervalo de tempo com grouping por usuário. Cassandra não suporta GROUP BY da forma como você está acostumado no SQL. Cada agregação precisava ser calculada application-side ou através de tabelas materializadas adicionais. A workaround que funcionou foi criar uma tabela secundária com partition key por data-hour e clustering key por user_id, mantendo os dados duplicados. Isso dobrou o tamanho do dataset mas tornou as queries de agregação em cerca de 3ms em vez de precisar de um job batch noturno de 40 minutos. O trade-off foi aceitar consistência eventual entre as tabelas e monitorar de perto a latência de escrita, que subiu cerca de 15% por causa do write path duplo. Outro problema que encontrei recentemente envolveu Redis como cache para uma API que servia dados de perfis de usuário. Implementamos TTL de 5 minutos e invalidação por chave. Funcionou perfeitamente por três semanas. Depois, começamos a ver hits de cache com dados desatualizados de 12 a 18 minutos. Descobrimos que o Redis evicting policy estaba configurada como allkeys-lru, e com o crescimento do dataset acima de 8GB, keys válidas estavam sendo substituídas antes do TTL expirar. A correção foi aumentar o maxmemory para 16GB e mudar para volatile-lru, mantendo apenas chaves com TTL sob pressão de memória.

O que iniciantes sempre erram

A tentação mais comum é tratar um banco não relacional como se fosse um banco relacional disfarçado. Criar colunas que poderiam ser foreign keys, fazer queries com filtros que exigem full table scan, ou tentar replicar transações ACID em sistemas que não oferecem isso. MongoDB tem transações multi-documento desde a versão 4.0, mas elas têm overhead significativo e não são gratuitas. Usar transações no MongoDB para cada operação de escrita é como colocar um motor de F1 num carro de cidade: funciona, mas o consumo de recursos é desproporcional. DynamoDB é outro caso onde o modelo de pensamento precisa ser diferente. A limitação mais crítica é o item de 400KB. Se você modelar entidades que crescem semanticamente, como um feed de atividades ou logs de sessão, vai bater nesse limite sem perceber. A solução é partilhar dados em múltiplos itens com key design adequado, usando atributos como date e activity_type como parte da primary key. A outra armadilha é subestimar a importância do access pattern antes de definir o schema. Em bancos relacionais, você define o schema primeiro e depois escreve as queries. Em bancos não relacionais, o access pattern define o schema. Se você não sabe como os dados vão ser lidos antes de modelar, vai passar semanas refatorando a estrutura depois. Anote todos os read paths do sistema antes de criar a primeira coleção ou tabela.

Quando NÃO usar bancos não relacionais

Se o seu sistema depende pesadamente de transações complexas com rollback condition, integridade referencial estrita, ou relatórios analíticos com joins dinâmicos, um banco relacional ainda é a escolha correta. MongoDB e Cassandra oferecem melhorias em consistência e join support ao longo dos anos, mas nenhuma delas alcança o nível de garantir ACID completo com performance comparable em todos os cenários. Para sistemas com leitura predominantemente analítica e dados estruturados que raramente mudam de schema, um data warehouse como BigQuery ou Snowflake resolve melhor do que qualquer solução NoSQL. E para cache puramente estratégico, Memcached às vezes é mais simples e eficiente do que Redis, especialmente se você não precisa de estruturas de dados avançadas como sorted sets ou streams. O mercado também tem soluções híbridas que valem consideration. PostgreSQL com extensões como Citus oferece sharding automático mantendo SQL compatível. MongoDB Atlas e Cosmos DB abstraem a complexidade operacional mas introduzem lock-in de provedor. A escolha certa depende do trade-off entre controle operacional, flexibilidade de query e custo de infraestrutura que você está disposto a assumir.