Executando verificação de segurança...
2
obrenoalvim
1 min de leitura ·

SQL vs NoSQL: depois de anos, quem ganhou essa guerra?

Por um tempo, NoSQL era o futuro. Schema flexível, escala horizontal, nada de joins. SQL era legado.

Isso não aconteceu como prometido. E vale entender por quê.

Por que NoSQL explodiu

O problema que NoSQL resolvia era real: bancos relacionais tradicionais tinham dificuldade com escala horizontal e esquemas que mudavam rápido. MongoDB, Cassandra e Redis chegaram resolvendo casos específicos muito bem.

O problema foi a generalização. "Use NoSQL" virou conselho padrão para qualquer projeto, independente do problema.

O que aprendemos na prática

Dados relacionais existem naturalmente na maioria dos domínios. Forçar relações em documento ou chave-valor cria problemas que SQL resolve com JOIN há 40 anos.

Consistência importa. Para sistemas financeiros, médicos, qualquer coisa onde dados incorretos têm consequências, ACID não é opcional.

SQL melhorou. PostgreSQL tem JSON nativo, arrays, full-text search, sharding com Citus. A rigidez de schema que afastava pessoas do SQL foi atenuada.

O que ficou de bom do NoSQL

Redis para cache e pub/sub. Cassandra para time series e write-heavy em escala massiva. Elasticsearch para busca full-text. Casos específicos onde NoSQL é genuinamente a solução certa.

MongoDB ganhou empresa, perdeu o argumento técnico. A maioria dos casos de uso que "exigiam" MongoDB funcionaria melhor em PostgreSQL.

A pergunta

Você usa NoSQL hoje por necessidade técnica ou por inércia de decisão anterior?

Carregando publicação patrocinada...
3
maniero

Basicamente é isto. Vou destacar:

Dados relacionais existem naturalmente na maioria dos domínios

Consistência importa

Muito mais domínios precisa de consistência

SQL melhorou

Sempre falo isso.

O que ficou de bom do NoSQL

Ou seja, não é o MongoDB

Adicionando meus 2 cents

(vou mandar mais 2 cents para o Oletros)

Vamos acertar um pouco a terminologia. Primeiro, apesar das pessoas usarem muito o termo NoSQL, isso não é um modelo de banco de dados. É uma guarda-chuva para vários modelos, o que por si só é estranho e pior ainda que alguns usam SQL. Mas mesmo não usando, n~çao ter SQL não é a característica que marca esses modelos, é a ausência de relacionamento, pelo menos no uso normal. Algo que mais ou menos eles têm em comum, e as pessoas não costuam falar sobre, é a ausência de consistência.

Então o NoSQL é muito usado onde não deve, e muitas vezes porque a pessoa não quer aprender SQL, o que é um erro de escolha, apesar de nem sempre fazer diferente. Boa parte da adoção de NoSQL é tão pouco importante que tanto faz se usar um banco de dados que usa SQL, possui relacionamento e não tem consistência (eventualmente pode dar um problema, mas passa batido, afinal para a maioria das pessoas basta funcionar, não ser o certo).

Em muitos casos poderia mudar o termo NoSQL para Documentos, porque é isso que está sendo comparado, e a esmagadora maioria da adoção errada é nesse modelo, em geral os outros modelos até costuma ser necessário. E isso se deve à divulgação muito bem feita sobre o MongoDB, o banco de ados que domina esse modelo. Noa parte dos casos onde pode usar MongoDb até o SQLite pode ser usado como banco de dados. Curiosamente o MongoDB existe para ser o oposto, é para ter uma necessidade que praticamente não tem casos. Alguns dos maiores sites do mundo usam bancos de dados relacionais como fonte primária ou até exclusiva.

MongoDB ainda tem muita utilidade em domínios específicos, em geral como satélite de um sistema maior, e em muitos casos que a adoção é marginal, mesmo não sendo o ideal não faz tanta diferença usar PostgreSQL, MariaDb, SQL Server, Oracle e até mesmo o SQLite dão conta do recado.

S2

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui).

3
1
obrenoalvim
  • Autor
    Autor

Boa adição sobre terminologia. 'NoSQL' sempre foi nome ruim porque agrupa coisas muito diferentes: documento, chave-valor, grafo, coluna. O que têm em comum de fato é ausência de relações e consistência, não ausência de SQL.

O ponto sobre MongoDB é cirúrgico. A adoção massiva foi em grande parte marketing bem feito na era do scale-everything, quando a maioria dos projetos nunca chegaria perto de precisar disso. E quem adotou para escapar do SQL continua sem saber SQL e agora tem queries esquisitas em cima de documentos aninhados.

Para domínios específicos faz sentido, concordo. Mas como banco principal de sistema com dados relacionais é escolha errada na maioria dos casos. O PostgreSQL resolve e ainda tem suporte a JSONB para os casos onde você realmente precisa de flexibilidade de schema.