Programação · dados · bases de dados

SQL vs NoSQL

Quando escolhe como guardar os dados de uma aplicação, a bifurcação clássica é SQL vs NoSQL. Ambos conservam os seus dados e devolvem-nos, mas fazem apostas opostas: o SQL privilegia dados estruturados, consistentes, ligados; o NoSQL dados flexíveis, escaláveis, desnormalizados. Este guia compara-os honestamente quanto a modelo de dados, consistência, escalabilidade e consulta – e quando escolher cada um. (Novo nas bases de dados? Comece por o que é uma base de dados.)

A diferença fundamental

• SQL (relacional) – os dados vivem em tabelas de linhas e colunas, com esquema fixo; as relações são explícitas e consulta-se em SQL. Exemplos: PostgreSQL, MySQL, SQLite.
• NoSQL (não relacional) – um termo genérico para modelos flexíveis: documento (MongoDB), chave-valor (Redis), coluna larga (Cassandra), grafo (Neo4j). Esquemas flexíveis, dados muitas vezes desnormalizados.

O SQL é estrutura primeiro («define a forma, depois guarda»); o NoSQL é flexibilidade primeiro («guarda agora, a forma varia»).

Consistência e transações

As bases de dados relacionais são construídas em torno das transações ACID e de uma forte consistência: uma transferência faz-se por inteiro ou é totalmente anulada, e todos leem o mesmo estado confirmado. É por isso que o SQL domina os pagamentos, os stocks e tudo em que a correção não é negociável. Muitos sistemas NoSQL inclinam-se, pelo contrário, para a consistência eventual (BASE), trocando a consistência imediata por disponibilidade e escala. A fronteira esbateu-se (alguns NoSQL oferecem agora transações), mas a mentalidade por defeito difere.

Escalabilidade

As bases de dados SQL tradicionais escalam verticalmente – um servidor mais potente – e distribuir as escritas por várias máquinas é mais difícil (embora réplicas de leitura e o SQL distribuído moderno ajudem). O NoSQL foi concebido para escalar horizontalmente: acrescentar nós comuns e fazer sharding dos dados, o que se adequa a débitos de escrita muito elevados e a volumes enormes. Se espera um débito de escrita à escala da internet, o modelo scale-out do NoSQL é uma verdadeira vantagem; para a maioria das apps, uma única base de dados relacional bem afinada vai notavelmente longe.

Consulta e flexibilidade

A grande força do SQL é a consulta ad hoc: joins, agregações e filtros arbitrários sobre tabelas ligadas, com décadas de ferramentas. O NoSQL sacrifica parte disso – os joins são muitas vezes limitados ou feitos no código – em troca da liberdade de guardar dados variados, aninhados ou mutáveis sem migrações. Se o seu padrão de acesso é conhecido e simples (pesquisa por chave, leitura de um documento), o NoSQL adapta-se naturalmente; se for preciso reporting flexível sobre relações, ganha o SQL.

Como escolher

• Escolha SQL para dados relacionais, transações e forte consistência, e consultas ad hoc variadas (pagamentos, stocks, a maioria das apps de negócio).
• Escolha NoSQL para dados sem esquema ou mutáveis, escalabilidade horizontal na escrita e acesso simples por chave (cache, sessões, registos de eventos, grandes catálogos).
• Ambos – persistência poliglota: uma fonte de verdade relacional mais um armazenamento NoSQL (por ex. cache Redis) para um papel preciso. Muito difundido.

Perguntas frequentes

Qual é a diferença entre SQL e NoSQL?

As bases de dados SQL (relacionais) guardam os dados em tabelas de linhas e colunas, com um esquema fixo e predefinido, e consultam-se em SQL através de tabelas ligadas – por exemplo PostgreSQL, MySQL e SQLite. NoSQL é um termo genérico para as bases de dados não relacionais, com modelos flexíveis (documento, chave-valor, coluna larga, grafo), que muitas vezes flexibilizam os esquemas rígidos e os joins para ganhar flexibilidade e escala – por exemplo MongoDB, Redis, Cassandra e DynamoDB. Em resumo: o SQL privilegia a estrutura e a consistência; o NoSQL a flexibilidade e a escalabilidade horizontal.

O NoSQL é mais rápido do que o SQL?

Não intrinsecamente. O NoSQL pode ser mais rápido para os padrões de acesso a que se destina – pesquisas simples por chave, alto débito de escrita, dados que cabem num único documento – e escala horizontalmente com mais facilidade por muitos nós. O SQL é muitas vezes mais rápido e simples para consultas complexas que juntam dados ligados, e as bases de dados relacionais modernas são muito otimizadas. A velocidade depende muito mais do seu modelo de dados, dos índices e das consultas do que da etiqueta SQL/NoSQL.

Quando usar NoSQL em vez de SQL?

Escolha NoSQL quando os seus dados são naturalmente sem esquema ou evoluem depressa, quando precisa de escalar as escritas horizontalmente por muitos servidores, ou quando o acesso é sobretudo por chave (cache, sessões, registos de eventos, grandes catálogos). Escolha SQL quando os dados são muito relacionais, quando são precisas transações e forte consistência (pagamentos, stocks, tudo em que a correção conta) e quando vai fazer consultas ad hoc variadas.

Pode-se usar SQL e NoSQL em conjunto?

Sim, e muitos sistemas fazem-no – fala-se de persistência poliglota. Um padrão comum: uma base de dados relacional como fonte de verdade para os dados centrais e consistentes (utilizadores, encomendas) mais um armazenamento NoSQL para um papel preciso: Redis para cache e sessões, um armazenamento de documentos para conteúdo flexível, ou um motor de pesquisa para texto integral. Use cada ferramenta onde é adequada em vez de forçar tudo num único modelo.

Em resumo

O SQL e o NoSQL não são tanto rivais como ferramentas para formas de dados diferentes. O SQL ganha na estrutura, na consistência e na consulta rica – a escolha certa por defeito para dados relacionais e críticos. O NoSQL ganha na flexibilidade e na escalabilidade horizontal – a escolha certa por defeito para dados sem esquema e escritas à escala da internet. Escolha consoante os seus dados e padrões de acesso, e não hesite em usar ambos.