/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

De 0 a 10, o quanto você recomendaria este artigo para um amigo?

 

Deixe um comentário! 11

leia mais
Este projeto é oferecido pelas empresas:
Este projeto é mantido pelas empresas:
Este projeto é apoiado pelas empresas: