Quando não usar SQL

Quando se pensa em criar uma nova aplicação, uma das partes mais importantes é a camada de persistência da aplicação. E em 99% dos casos, a escolha óbvia é um banco de dados relacional.

Por que usar um banco de dados SQL?

Atomicidade, consistência, isolamento e durabilidade

Para iniciar nossa explicação a princípio do ACID, definiremos aqui alguns termos para minimizar algumas confusões futuras:

1. Banco: Imagine um banco qualquer, onde guardamos nosso dinheiro.
2. Transferência: Operação bancária onde a pessoa A envia dinheiro à pessoa B.
3. Banco de dados: O banco de dados utilizado nos sistemas deste banco.
4. Transação: Um conjunto de uma ou mais operações que compõem uma única tarefa ou unidade lógica de trabalho a ser executada no banco de dados.

Pense em um banco, sempre que você faz uma transferência, é necessário ter certeza que o dinheiro foi subtraído da conta A e somado na conta B. A atomicidade em um banco de dados SQL é o princípio que essa transação será concluída por completo ou não será realizada.

Agora, neste mesmo banco, imagine que ao realizar uma transferência uma das contas fica negativa (considerando que o banco não permita contas negativadas), a consistência é o princípio que não deixará que isso ocorra ao falhar a transação quando uma dessas restrições é quebrada.

Além disso, o princípio do isolamento garante que transações concorrentes não interfiram umas nas outras. Isso assegura que, mesmo quando múltiplas transações ocorrem simultaneamente, o resultado final seja equivalente a se elas tivessem sido executadas sequencialmente. Ainda no exemplo do banco, caso duas transferências ocorram "ao mesmo tempo", para assegurar a integridade das informações, uma transação só poderá ocorrer após o término da outra.

E por último, mas não menos importante, após a confirmação de uma transação, é necessário que seus efeitos permanentes sejam mantidos, mesmo em caso de falhas de sistema ou queda de energia. E para isso, o princípio da durabilidade nos trás essa garantia.

Eu não sei vocês, mas eu certamente não deixaria meu dinheiro em um banco que não tivesse um banco de dados que me assegurasse esses princípios!

Estrutura, maturidade e relevância

O SQL se tornou um padrão em 1986 e desde então recebeu inúmeras atualizações, fazendo com que o mesmo nunca perca sua relevância ao longo dos anos.

A linguagem SQL é poderosa e flexível podendo se adaptar a diversos cenários desde os mais simples aos mais complexos onde o domínio dos dados é conhecido. (E até mesmo nem tão conhecido assim, afinal, em 2023 o tipo JSON foi formalmente adotado nos padrões da linguagem)

A maturidade do SQL, combinada com sua estrutura tabular intuitiva e ampla adoção como padrão no ensino de gerenciamento de dados, em universidades e cursos, mantém sua relevância no mercado. Esta popularidade resulta em uma vasta disponibilidade de recursos educacionais, desde conceitos básicos até tópicos avançados, facilitando o aprendizado e o aprofundamento no SQL através de diversos canais.

o NoSQL

Agora que entendemos alguns dos principais motivos do porquê alguém usaria do SQL, o que acontece em casos onde você não precisa de ACID? Seria isso o suficiente para não usar SQL? Vamos aqui discutir alguns principais casos onde o NoSQL pode ser interessante a você ou sua empresa/projeto!

Grande volume e dados não estruturados ou semi-estruturados

NoSQL é ideal para armazenar e gerenciar grandes volumes de dados não estruturados ou semi-estruturados, como logs de servidores, dados de redes sociais ou documentos JSON, um grande case é o Twitter/X, que em 2010 apresentaram o FlockDB, um banco de dados de grafos distribuídos para armazenar grafos sociais (quem segue quem, quem bloqueia quem) e índices secundários. Em abril de 2010, o cluster FlockDB do Twitter armazenava mais de 13 bilhões de nós e sustentava tráfego de pico de 20 mil gravações/segundo e 100 mil leituras/segundo. O que para um banco de dados MySQL poderia ser absurdo.

Mas então, isso significa que, se eu quiser criar uma nova rede social, devo partir direto ao NoSQL?
Provavelmente não! A menos que você tenha certeza que sua rede social terá o mesmo tráfego que o Twitter isso acabará se tornando apenas uma otimização prematura na sua aplicação.

Big data

Big Data refere-se a conjuntos de dados vastos e complexos que não podem ser gerenciados, processados ​​ou analisados ​​de forma eficaz usando ferramentas e métodos tradicionais de processamento de dados. Esses conjuntos de dados normalmente exibem três características principais alto volume de dados (geralmente terabytes, até mais), alto fluxo de ingestão de dados e variedade, muitas vezes contendo dados semi-estruturados como JSON ou até mesmo não estruturados como texto, imagem e vídeos.

Essas características podem trazer uma grande dificuldade a um banco de dados SQL tradicional. Fazendo que a melhor escolha seja um banco não relacional como MongoDB e Cassandra.

Sistemas de recomendação e auto preenchimento

Sistemas de recomendação e auto preenchimento são áreas em que bancos de dados NoSQL brilham devido à sua capacidade de lidar com grandes volumes de dados e realizar consultas rápidas e complexas. Aplicações como plataformas de streaming, e-commerce e redes sociais dependem fortemente de recomendações personalizadas e funcionalidades de auto preenchimento para melhorar a experiência do usuário.

Bancos como Neo4j (orientado a grafos) ou Elasticsearch (orientado a documento), são ideais para armazenar e consultar rapidamente esses dados complexos, permitindo a geração de recomendações precisas em tempo real.

CACHE

O único caso onde vejo que aplicações de pequeno e médio porte podem se beneficiar verdadeiramente de um banco de dados não relacional, o cache.
O cache é uma técnica utilizada para armazenar dados temporários em uma memória de acesso rápido, permitindo que aplicações acessem esses dados de maneira mais eficiente. Bancos de dados NoSQL como Redis e Memcached são frequentemente utilizados como soluções de cache devido à sua alta performance e baixa latência.

Ao armazenar resultados de consultas frequentes e dados temporários no cache, a necessidade de acessar o banco de dados principal é reduzida. Isso diminui a carga sobre o banco de dados e até mesmo sobre algum processamento pesado que possa vir a acontecer, permitindo que ele lide com um menor número de solicitações e mantenha um desempenho mais estável e rápido, isso não só transforma sua aplicação em algo mais escalável mas também faz com que as instâncias envolvidas na sua aplicação possam ser de menor nível inicialmente, trazendo um baixo custo em um momento que pode ser crucial à vida do seu projeto.

sequenceDiagram
    participant App as Aplicação
    participant Cache as Cache Redis
    participant DB as Banco de Dados

    App->>Cache: Consulta Dados
    alt Dados Encontrados no Cache
        Cache-->>App: Retorna Dados
    else Dados Não Encontrados no Cache
        Cache->>DB: Consulta Dados
        DB-->>Cache: Retorna Dados
        Cache-->>App: Armazena e Retorna Dados
    end

Considerações finais

Meu projeto deveria utilizar NoSQL?

No fim das contas, a resposta sempre será: depende. Para projetos padrão em empresas estruturadas onde você precisa de um MVP e já possui esforços em infraestrutura para provisionar bancos de dados relacionais de formas padrão, eu provavelmente me manteria no bom e velho SQL, mas facilmente recorreria a soluções de cache com algo como um Redis à medida que a maturidade da aplicação cresce.
Em projetos pessoais onde tudo que eu quero é um banco de dados com plano gratuito, é muito mais fácil encontrar opções NoSQL como o supabase, firebase ou faunadb.
Já em projetos extremamente escalados e com milhões de leituras e escritas por minuto, é necessário pensar na estrutura dos dados, na velocidade das operações, na criticidade das informações e muitas outras regras advindas do negócio. Então, é impossível trazer em um pequeno post um playbook, afinal, muitas soluções ainda estão sendo desenvolvidas até hoje e nunca haverá um final.