/Banco de dados

voltar
/Banco de dados

Minhas primeiras impressões sobre o NoSQL

PorWagner Crivelini em

Minha experiência com bases de dados NoSQL é, para todos os efeitos práticos, zero. Meu primeiro contato com a ideia de uma base NoSQL foi em 2010, gravando um programa do DatabaseCast em que íamos entrevistar alguns especialistas.

Passados três anos, eu continuo um leigo no assunto. Mas, durante esse tempo, o NoSQL ficou no meu radar. Leio, converso com gente que entende e procuro ir aprendendo aos poucos.

Não que um dia eu pretenda me transformar numa DBA de SGBD NoSQL. Honestamente eu não acho que vá existir essa profissão. Mas eu entendo que tenho obrigação de ter uma noção sobre o assunto, até para poder recomendar soluções mais adequadas para meus clientes.

Constantemente vejo gente colocando SGBDs relacionais e NoSQL como concorrentes. Eu acredito que isso é um absurdo tão grande quanto perguntar em quantos segundos a sua motoniveladora vai de 0 a 100 km/h. Ou quantas toneladas de carga seu carro esporte é capaz de transportar.

Eu entendo que essa competição não leva a lugar algum e resolvi escrever aqui minhas impressões sobre algumas questões.

Tecnologias concorrentes?

Primeiramente, eu vejo tecnologias muito diferentes destinadas a atender necessidades completamente distintas. De igual, temos a palavra “dados”, tanto no relacional como no NoSQL. Assim como temos rodas tanto na motoniveladora como no carro esporte.

Para ser bem honesto, a minha impressão é que o universo NoSQL não se restringe a uma tecnologia. Cada produto foca em coisas tão diferentes entre si que eu diria que podem facilmente ser classificadas em categorias distintas.

De qualquer modo, aí a ideia de competição me parece um erro. Os SGBDs relacionais são muito bons naquilo que fazem, que é prover bancos de dados robustos para trabalhar em ambientes transacionais com alta concorrência. Dificilmente um NoSQL vai poder concorrer nesse nicho.

E os NoSQL são muito rápidos e flexíveis, ótimos para trabalhar com dados desestruturados e em ambientes que exigem mudanças ao longo do tempo, já que o modelo de dados não é rígido. Nesse aspecto, o mínimo que se pode dizer dos relacionais é que eles estão engessados aos seus modelos, e alterações nessas estruturas são difíceis e muitas vezes caras.

Velocidade de operação

Outra questão que ouço com frequência é a comparação de velocidade entre SGBDs NoSQL e relacionais. Eu vejo novamente um problema de interpretação.

Vamos partir da premissa que todo SGBD, seja qual for, tem que trabalhar num ambiente de alta concorrência, no qual centenas de pessoas acessam os mesmos dados ao mesmo tempo e todos podem, ao menos em teoria, ler o dado, alterá-lo, excluí-lo ou até inserir um novo dado.

Os SGBDs relacionais são projetados para trabalhar com transações e, por definição, toda transação é isolada das demais (este é o “I” da sigla “ACID”). Em outras palavras, uma transação não pode interferir nas demais. Por conta disso, os SGBDs relacionais são obrigados a gerenciar mais três tipos de ação:

  • bloqueio de objetos (tabelas, páginas ou registros)
  • enfileiramento de transações
  • log das transações realizadas (para o caso de perda)

Se não considerarmos as transações, como no caso do NoSQL, e tratarmos os dados no esquema de chave/valor, evitamos bloqueios, evitamos filas e eventualmente até podemos dispensar um log das ações.

Isso é impensável para o caso de uma movimentação bancária, mas é plenamente aceitável, por exemplo, no acesso aos dados do meu mural do Facebook: meus amigos podem ler, mas só eu altero o que está lá. E se algum amigo estiver lendo a página enquanto eu faço uma alteração, não vai ser um desastre se ele ler a versão antiga do texto (a menos que você tenha postado uma daquelas frases que causam arrependimento automático).

Esse é o conceito de leitura suja (“dirty read”), que nós também usamos nos SGBDs relacionais nos casos em que queremos reduzir o número de bloqueios aplicados ao dado (nível de isolamento de transações conhecido como “Read Uncomitted”).

Porém é importante observar o seguinte:

  1. SGBD NoSQL não vai trabalhar bem com transações e garantir de forma eficaz as qualidades ACID, porque ele não é projetado pra isso.
  2. SGBD relacional, ao contrário, sempre vai criar bloqueios de dados e filas, mesmo quando eles não são necessários, porque ele é projetado para tratar tudo como transações.

Modelo de dados

O terceiro ponto que eu destaco é a questão do modelo de dados usado no NoSQL. Para os que são acostumados com o modelo relacional, como eu, é difícil admitir que exista um modelo por trás de tudo.

O modelo relacional exige que o tudo seja formalizado e estruturado: propósito do modelo, as relações entre objetos e as restrições dos dados. Já o modelo NoSQL é muito menos exigente, concentrando o foco no propósito dos dados.

Mas aí entra outro aspecto importante: na verdade, existem diferentes modelos de dados que são usados em SGBDs NoSQL, representados por produtos distintos, sendo todos eles classificados como “NoSQL”. Entre esses modelos, temos:

  • Armazenamento chave/valor
  • Armazenamento de chave ordenada
  • Bancos de dados de documentos
  • Bancos de dados de grafos (hierárquicos)
  • Outros

Receptividade de cada tecnologia

No mundo relacional, existe certa disputa entre programadores e DBAs na maioria das empresas. Os programadores reclamam que os DBAs impõem uma série de regras que limitam o trabalho de programação.

Falando como DBA, eu diria que é inevitável que existam tais regras. São poucos os programadores que de fato entendem o que seu código representa em termos de ações requeridas no banco de dados. O universo SQL e o modelo relacional em si geralmente causam muita confusão para quem está acostumado com programação.

Trocando em miúdos, o mundo relacional é bastante confortável para DBAs, mas é limitador e burocrático para os desenvolvedores.

Do outro lado, a maioria dos SGBDs NoSQL de que ouvi falar trabalha nativamente com alguma linguagem de programação. A lista é grande: Java, JSON, Perl, PHP, Python, e por aí vai. Além dessa facilidade, os modelos de dados NoSQL podem ser mudados a qualquer momento sem grande impacto para a aplicação.

Claro que são ingredientes excelentes para cair no gosto dos programadores. Menos regras, reaproveitamento de conhecimentos anteriores e tecnologias mais acessíveis para programadores.

Pelos mesmos motivos, é inegável que DBAs encontram certa dificuldade para trabalhar com SGBDs NoSQL. Isso tem a ver com o nosso costume com o paradigma relacional. E também porque DBAs costuma ter pouco domínio sobre linguagens de programação. E, falando com todo sinceridade, eu me enquadro nas duas condições.

Mas aprendi muito tempo atrás que preferências pessoais não são um bom parâmetro para avaliar qualidades e defeitos de SGBDs ou qualquer outra coisa… Não podemos nos comportar como torcedores desta ou daquela tecnologia, porque aí rapidamente deixamos o bom senso de lado.

Conclusão

No fim das contas, a ideia do “quem é melhor” me parece uma bobagem. As tecnologias são complementares e podem facilmente coexistir numa mesma aplicação.

O que importa no final das contas é a necessidade do cliente. E aí sim as qualidades e os defeitos dos SGBDs relacionais e dos NoSQL vão mostrar qual deles é o mais adequado para executar o trabalho.

Referências

Deixe um comentário! 11

11 comentários

Comentários

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Comentando como Anônimo

  1. Muito boa a colocação, cada parafuso tem sua rosca, se tentarmos forçar roscas diferentes iremos destruir os dois. Vou pesquisar mais sobre essa ferramenta. Parabéns!

  2. Ótimo artigo Wagner. Precisamos sempre analisar bem para escolher a melhor forma de acondicionar nossos dados. O modelo relacional está consolidado, poucas mudanças tem acontecido, ainda acho o melhor modo de guardarmos informações. Os banco de dados NoSQL acredito que só devam ser usados se for necessário um armazenamento frenético de informações, e que não precise de uma ordem, logs e etc que amarrem documentos, e outras informações. Mas sempre é bom estarmos abertos a estas novas tecnologias. Obrigado por brindar-nos com mais conhecimento sobre Banco de Dados.

  3. Realmente um dos melhores pontos de vista que já, concordo com tudo o que foi dito, sou programador a muitos anos e sei que devemos dar importância a necessidade do cliente e aplicar a tecnologia que mais se encaixa, e não devemos colocar simplesmente nosso gosto por uma determinada tecnologia.

  4. Olá, Wagner. Parabéns pelo artigo, explica de uma forma simples as principais diferenças entre os dois tipos de SGBDs.
    Gostaria de deixar aqui uma sugestão, para aqueles que precisam trabalhar com dados não estruturados, em um ambiente que possibilite o controle transacional. Imagine um banco NoSQL, com as propriedades ACID. Sim, é possível, e já existe. Chama-se Informix, é da IBM, para aqueles que nunca ouviram falar, é uma grande nova feature de nosso produto. Alta disponibilidade, escalabilidade, execução em múltiplas plataformas (MacOS, Unixes, Windows), entre vários outros.
    Conheçam!
    Se precisarem de alguma ajuda, estou a disposição.

    1. Alexandre
      Eu nunca trabalhei diretamente com o INFORMIX, mas sei q ele é relacional, suporta SQL e funciona bem a mais de 20 anos
      No final dos anos 90 eles lançaram o INFORMIX UNIVERSAL DATABASE que teria extensões pra diversos tipos de dados não estruturados, mas o produto não vingou e a empresa foi comprada pela IBM.
      Atualmente esta estratégia de criar um BD relacional com funcionalidade NoSQL é meio que padrão no mercado, me parece q ORACLE e MICROSOFT tb estão neste caminho.
      Mas este é o problema… geralmente se trata de um mecanismo relacional adaptado pro NoSQL….
      O interessante seria o inverso. Um mecanismo NoSQL extendido para suportar propriedades ACID.

  5. Olá Wagner Crivelini, sou DBA PostgreSQL, eu também não tenho conhecimento nenhum sobre NoSQL, não sei como funciona na prática, mas pelo seu artigo pelo menos consegui absorver algo sobre NoSQL. Parabéns pelo artigo.

leia mais
Este projeto é mantido e patrocinado pelas empresas: