Segue para o conteúdo

28 de março de 2010

8

Os problemas de um termo infeliz

Hoje o meu amigo @epx141 escreveu o seguinte no Twitter:

#NoSQL is a typical confusion between API and backend implementation. SQL indeed sucks, but the storage engines behind it are great.
Instead of writing a new db from scratch, with 20 years of bugfixing ahead, why not take MySQL and make a better query language/API on top?

O termo NoSQL é tão infeliz que levou o @epx141 a compreender de maneira totalmente inversa o que, de fato, é o tal NoSQL.

O que o @epx141 diz que é “great” (storage-engine, modelo de dados, etc) é justamente o que os desenvolvedores desses bancos de dados acham que “sucks”. E o que o @epx141 diz que “sucks” é justamente o que esses desenvolvedores gostariam de ter em seus bancos de dados (uma linguagem universal que explore bem as características de cada banco).

NoSQL é um termo infeliz porque os bancos de dados que fazem parte desse grupo não tem nada contra a linguagem SQL em si. Eles estão justamente ‘contestando’ a hegemonia do *modelo relacional* dos bancos de dados que, em sua imensa maioria, utiliza a linguagem SQL para manipular os seus dados.

Uma definição mais adequada para esse tipo de banco de dados deveria dizer algo similar à “bancos de dados não-relacionais”. Algumas pessoas, no Brasil, estão usando a sigla MRNN, mas não acho que esse termo ‘pegue’.

O termo NoSQL ‘pegou’ porque a linguagem SQL só faz sentido no contexto dos bancos de dados relacionais. Mas ninguém é contra a criação de uma linguagem ‘universal’ para manipulação de dados em bancos de dados não-relacionais.

O CouchDB até mesmo fez isso: usa REST, JS e MapReduce para manipulação dos seus dados. O MongoDB, criou uma variante do SQL. Já para Bancos de dados do tipo chave-valor talvez não faça muito sentido criar uma linguagem para acesso aos dados, afinal, esse tipo de banco de dados não passa de um ‘big dicionário distribuído, redundante, etc’.

O @epx141 é um cara que gosta do modelo relacional para bancos de dados. Ele também acha que eu não gosto. A minha opinião é um pouco mais “cinza”: Eu acho que bancos de dados relacionais tem a sua utilidade mas ela, é muito menor que a utilidade de um banco de dados OO (ZODB, Caché, …) ou um banco de dados de documentos (CouchDB, MongoDB, etc).

É comum eu adotar uma postura ‘radical’ pra expressar essa opinião, mas a razão disso é justamente a de chocar e provocar a reflexão de uma manada de desenvolvedores que usa bancos de dados relacionais “por que sim”.

É óbvio que os bancos de dados não-relacionais ainda não dispõem da maturidade, robustez, etc, etc dos bancos de dados relacionais que existem hoje. É óbvio que ‘ninguém é demitido por usar RDBMS’. Mas não podemos nos esquecer de contextualizar as discussões.

Quando a IBM surgiu com a idéia do modelo relacional (Edgar F. Codd trabalhava para a IBM) os desenvolvedores torceram o nariz da mesma maneira. Os bancos de dados relacionais eram pavorosos e pouco maduros. O ciclo se repete agora.

Esse tipo de reação é freqüente no nosso mundo. É o medo da mudança. O medo do novo. Lembro de vários desenvolvedores Java falando da perfeição da sua linguagem/plataforma que hoje são referências no desenvolvimento Ruby. Tudo isso no tempo em que eu defendia o uso de Python (que, exceto pela sintaxe, é uma linguagem próxima de Ruby).

Precisamos ter em mente que a adoção de ferramentas (r)evolucionárias aumenta o risco dos projetos e que grandes riscos podem trazer grandes retornos (ou grandes prejuízos). O mundo da TI é muito cruel com os reacionários.

A Triveos é especializada no desenvolvimento de aplicações Web e utiliza Python e Django em grande parte de seus projetos. Tendo como base esse know-how no uso de Python e Django criamos o Curso de Desenvolvimento Web com Python e Django nas modalidades in-company e online.
Leia mais sobre Sem categoria
  • http://epx.com.br Elvis

    Aqui é o @epx141, vamos a alguns esclarecimentos :)

    Eu não confundi o termo. Eu sei que #nosql refere-se a remover também o modelo relacional. Eu simplesmente acho que:

    a) isto é uma opinião pessoal, mas acho que o REAL motivo que leva as pessoas a procurar com tamanha sofreguidão uma coisa diferente de SQL é o ódio à sintaxe do SQL, e o termo #nosql “entrega” esta intenção;

    b) Este “ódio” poderia ser reciclado (bem como o termo) em uma coisa mais construtiva, realmente matando o SQL sem jogar fora os 20 ou 30 anos de desenvolvimento nos backends.

    Peço desculpas pelo “salto mortal lógico” entre as duas coisas no Twitter, mas 140 caracteres são um limite complicado :)

    SQL (linguagem) tem três problemas para mim.

    Primeiro, foi imaginada para que secretárias e estagiários pudessem extrair informação de bancos de dados. Uma linguagem para pobres é uma linguagem pobre.

    Segundo, SQL expressa cálculo relacional, enquanto os backends só sabem fazer álgebra relacional. E a conversão de um para o outro é NP-difícil. Os bancos de dados fazem o melhor que podem, usando heurísticas e aproximações, e principalmente usando índices, quando o modelo relacional teoricamente não depende de índices para funcionar. Isto é a origem daqueles famosos problemas de desempenho de SQL, onde uma vírgula fora do lugar faz uma consulta levar 100 anos em vez de 0,2 segundos.

    Outro problema dessa conversão cálculo-álgebra é que em cima disso você tem os tais frameworks Web com seus adaptadores OO-SQL, que “mostram” os dados ao programador no estilo álgebra relacional (como uma tabela do Clipper :) e tem de converter cada operação para cálculo relacional (SQL) que no banco de dados vira álgebra de novo.

    Como álgebra relacional implica em poder “navegar” as tabelas, uma coisa que o SQL não tem (embora há os tais “cursores”, que são concessões do modelo relacional à realidade) aí entra toda aquela problemática de manter cache do lado cliente, coerência desse cache etc. etc.

    Então, não me surpreende que os usuários de frameworks Web tenham más experiências com SQL. Também tive nas poucas “brincadeiras” que fiz com eles. Mas existe espaço para melhorias SEM jogar fora os backends relacionais: eliminando a dupla tradução álgebra-cálculo-álgebra relacional.

    Que bancos de dados não relacionais tenham seu lugar? É claro que têm. LDAP e DNS são exemplos de bancos hierárquicos e distribuídos, e prestam serviços que jamais cairiam bem num banco de dados centralizado e relacional.

  • http://epx.com.br Elvis

    Ah, e eu não gosto do modelo relacional. Se gostasse, estaria trabalhando com ERP ou como DBA, ganhando três vezes mais do que ganho fazendo coisas “divertidas”.

    Só acho que o modelo relacional entrega o peixe, enquanto os demais ainda têm de provar que também entregam. Vejo nego dizendo que converteu seu blog com meia dúzia de leitores para NoSQL, é um exagero simétrico àquelas lojinhas de shopping rodando sistema de check-out monousuário com Oracle…

  • http://www.pythonologia.org/ Osvaldo Santana

    Quando eu digo que os bancos de dados não-relacionais ‘querem uma linguagem universal’, estou dizendo que eles provavelmente querem uma linguagem “completa” (python, js, …) que se integre de maneira ‘natural’ aos bancos de dados e que permita a troca dos bancos de dados sem a reescrita da aplicação (algo impossível até com a SQL :D).

    Mesmo sem usar SQL a modelagem relacional ainda exige que você modele seus dados usando uma estrutura rígida de conjuntos. Se seus dados são ‘tabulares’ (e uma quantidade grande de informações se encaixa nessa categoria), ok. O modelo relacional se mostra tão bom quanto outros modelos. Em Clipper, o que a gente fazia era o mesmo que os bancos de dados relacionais fazem. A diferença (brutal) era que implementávamos isso ‘na mão’ em Clipper. Mas a modelagem estava toda lá nas tabelas.

    Mas se os dados que você precisa manipular apresentam características um pouco mais sofisticadas (geo-info, hierarquicos, meta-dados semânticos, informação não-estruturada, etc) as coisas começam a ficar ‘cabulosas’.

    Em aplicações OO (não essas aplicações que tem as classes Model que são só representações de tabela como nos casos do Django/RoR), é muito fácil você chegar em situações onde a tal ‘impedance mismatch’ (http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch) começa a te morder e você se vê criando relacionamentos N-N (exemplo do Django: contenttype) ou 1-1 (modelar herança) só pra vencer as limitações do modelo relacional.

    Além disso temos os problemas de implementação dos bancos de dados relacionais. Não é muito incomum encontrar casos onde é necessário desnormalizar tabelas ou replicar informações em tabelas distintas para tornar uma pesquisa viável em termos de performance.

    O artigo que o @rstm apontou (http://teddziuba.com/2010/03/i-cant-wait-for-nosql-to-die.html) apresenta uma visão muito limitada do problema. Se ele tá falando sobre trocar o MySQL/PostgreSQL em uma aplicação Django que lida com dados ‘tabulares’ só porque “NoSQL está na moda” tudo bem.

    Mas se ele está falando de um caso onde os dados a serem manipulados não forem tabulares ou que esteja forçando o desenvolvedor a desnormalizar suas tabelas e a replicar seus dados para tornar sua aplicação escalável, já pode ser interessante avaliar uma alternatica.

    Aí pra justificar o ponto de vista dele ele ilustra com uma escolha equivocada para o caso enunciado. Se o Cassandra tem a tal limitação (não sei se tem) o CouchDB/MongoDB não tem. Talvez fosse melhor ter escolhido uma delas.

    Na aplicação que estamos fazendo na Triveos, tem que ser possível ‘criar colunas em uma tabela’ em tempo de execução. Banco de dado relacional nenhum faz isso.

  • http://www.pythonologia.org/ Osvaldo Santana

    Sim, toda escolha tem que ser fundamentada.

    Mas os DBs já começaram a não entregar mais os peixes em certas situações. Estas situações começaram a surgir em ambientes de alta demanda (que exigem alta escalabilidade) de empresas como o Google, Facebook, Twitter, etc.

    Esse blog aqui precisa disso? Não. E por isso ele roda com MySQL.

    Até mesmo no caso da nossa aplicação (citada no meu comentário anterior) o backend do nosso ZODB (para quem não sabe é um banco de dados OO para Python) é o MySQL. Mas ele é usado basicamente pra gerenciar transações e armazenar os objetos num “tabelão único”.

    Usamos ele porque oferece boas soluções de replicação, backup, recuperação, etc e não por conta do modelo relacional dele.

  • http://www.robteix.com Roberto Teixeira

    OMFG! Chuuuuuuuuuuuuuuuuuuuuuuuuuuuuupa, epx!!! :)

  • Guilherme

    Vamos esquematizar:

    Todos os fenômenos listados abaixo existem:

    a) Existem pessoas que gostam de bancos de dados relacionais e odeiam SQL
    b) Existem pessoas que acham que bancos de dados relacionais “são ruins” (para algumas coisas)

    Note que são tipos diferentes de pessoas :). À sua forma, ambos os tipos de pessoas têm opiniões legítimas.

    c) Tem gente que acha que banco de dados relacional “modela o mundo”. São os fascistas de bancos de dados relacionais. (fenômeno “se seus dados não cabem no modelo, os seus dados estão ERRADOS”)
    d) Realmente tem gente demais desenhando solução para a escala de bilhões de usuários que não precisa disso. (fenômeno “Acabei de instalar um cluster Hadoop para servir meu blog que tem 6 acessos do Googlebot por semana”)

    Ambos estão errados e são manés.

    e) NoSQL significa “qualquer coisa não-relacional”. O nome é besta, mas todo mundo achava o termo AJAX besta. O “X” é de XML mas todo mundo usa JSON e continua chamando de AJAX. Só porque o nome não é rigorosamente correto não quer dizer que não seja útil.

  • http://www.pythonologia.org/ Osvaldo Santana

    e) NoSQL significa “qualquer coisa não-relacional”. O
    nome é besta, mas todo mundo achava o termo
    AJAX besta. O “X” é de XML mas todo mundo usa
    JSON e continua chamando de AJAX. Só porque o
    nome não é rigorosamente correto não quer dizer
    que não seja útil.

    É verdade Guilherme. Nisso você tem razão. AJAX é um nome/acrônimo tão infeliz quanto NoSQL.

    Não há dúvidas que o termo “NoSQL” é o que “pegou”. Mas o “No” carrega uma carga pesada do pensamento “anti” alguma coisa.

    Meu passado ‘evangelizador’ de SL e Python me mostrou que essa postura ‘anti-algo’ é prejudicial porque ela ‘ataca’ o status-quo e força as pessoas entrarem em modo defensivo.

  • http://epx.com.br Elvis

    Bom, eu me enquadro no modelo A do Guilherme. Não sei porque as pessoas me vêem como um reacionário. Eu nunca dei motivos pra isso! :) cof cof