NoSQL — Uma introdução a bancos de dados NoSQL

Neste artigo pretendo mostrar uma pequena introdução aos bancos de dados NoSQL. Um breve histórico, suas motivações e sua importância nos dias de hoje. Não é um conteúdo aprofundado, mas serve pra dar um norte na sua pesquisa. Direto ao ponto.

• NoSQL é um movimento que está em constante expansão no mundo da tecnologia desde os anos 90
• A cada dia novas iniciativas são criadas para resolver problemas do mundo real em que soluções com bancos relacionais não são tão eficientes.
• Iniciou completamente independente de qualquer organização comercial
• Algumas ideias vieram de organizações comerciais, como Google (Bigtable) e amazon (key-value store), porém o que popularizou o NoSQL foi o open source.

Um breve histórico

• O termo foi lançado mais ou menos em 1998 juntamente com um banco de dados que era controlado por linguagem SQL. O termo correto, segundo o autor (Carlo Strozzi) deveria ser NoREL, fazendo referencia ao fato de ser não relacional.
• O termo foi re-introduzido no mercado em 2009 em um evento técnico em que seriam discutidas tecnologias e metodologias de utilização de bancos de dados distribuídos.
• Inicialmente, o termo significava No SQL (algo como “sem SQL”), mas posteriormente, com a evolução das tecnologias envolvidas, se tornou Not Only SQL (algo como “Não somente SQL”)
• Não é uma tecnologia inventada por uma entidade específica. Os conceitos de NoSQL foram sendo desenvolvidos lentamente ao longo dos anos, principalmente pela comunidade open source.
• Vamos agora entender um pouco sua evolução baseada em dois papers, do google e Amazon.

BigTable

• Paper lançado pelo Google em 2006
• Armazenamento distribuído para gerenciamento de estruturas de dados que podem atingir tamanhos extremamente grandes: petabytes de dados em milhares de servidores.
• A ideia seria trazer todos os dados relacionados a uma busca utilizando apenas um id, sem a necessidade de joins complicados e muitas vezes ineficientes.
• Pode ser compreendido como uma alternativa a um relacionamento com muitas tabelas.
• Projetado para ser utilizados em muitas máquinas de médio porte ao invés de uma única máquina extremamente cara e robusta.

Amazon Dynamo

• Paper lançado pela Amazon em 2007
• “Utilizado para gerenciar o estado de serviços que possuem requisitos de alta confiabilidade e um bom custo-benefício com relação a performance, disponibilidade e consistência”
• O paper descreve como muitos dados da Amazon são armazenados com o uso de chave primária, e como os hashs são consistentes em particionar e distribuir dados, além de versionamento de objetos para manter consistências entre data centers

Esses dois papers inspiraram muitas organizações a criar seus próprios bancos NoSQL. Aconteceram tantas modificações nos papers, que um grupo de estudos foi criado com o objetivo de se encontrar e discutir as várias abordagens para este conceito.

NoSQL hoje em dia

• Hoje existem litealmente centenas de bancos de dados NoSQL
• Cada tipo de problema que um banco de dados relacional tradicional não era efetivo fez surgir um novo tipo de NoSQL nessa área particular
• Cada tipo de problema requer um tipo de banco de dados

Features Comuns

Apesar do que falei acima, que cada NoSQL reflete um tipo de problema específico, algumas features atravessam a maioria destes bancos, em comparação com um banco de dados tradicional, relacional. Algumas delas eu tentei listar a seguir:

Não é necessário um schema

• um schema é a descrição de todos os dados possíveis em um banco de dados relacional. Em uma base NoSQL um schema não é necessário, dando ao desenvolvedor a liberdade de armazenar as informações sem precisar obrigatoriamente de uma estrutura bem definida.

Não Relacional

• Em um banco de dados relacional, como o próprio nome já diz, é fundamentado na relação entre as entidades. Em bancos de dados NoSQL a informação é armazenada como uma agregação, um único registro contendo tudo sobre aquela transação. Rapidamente podemos pensar em duas vantagens para um banco de dados não relacional:
• Facilidade de armazenamento e recuperação
• Performance da query. Diferente de bancos relacionais, não é necessário realizar joins entre tabelas. Bancos de dados NoSQL são desnormalizados.

Pouca infraestrutura:

• diferente de alguns bancos de dados relacionais que precisam de um poder de processamento alto e um maquinário especifico, bancos NoSQL podem ser armazenados em servidores mais simples, o que pode ser muito favorável quando tratamos de escalabilidade.

Operações distribuídas

• Bancos de dados distribuídos podem armazenar e processar um conjunto de informações em mais de um dispositivo. Porém, não são todo os bancos NoSQL que suportam operações altamente distribuídas.

Open Source

• Esta não é uma característica de todos os bancos NoSQL, porém foi assim que eles surgiram. Sempre que existia uma nova necessidade, os desenvolvedores criavam uma nova solução e a publicavam como open source
• Hoje a realidade é um pouco diferente e já existem vários bancos NoSQL corporativos, com vários modelos de negócios.

Ok, mas, e eu com isso?

Você pode estar se perguntando o que tem a ver com toda essa mudança. O banco relacional resolveu todos os problemas do mundo até agora, não é? Mudar agora seria muito arriscado…

Não é bem assim… A seguir tento listar uma série de argumentos que ajudam a digerir a ideia de NoSQL numa organização. Observe que um banco NoSQL não necessariamente substitui um banco relacional ou vice-versa. Essa é a maravilha: podemos combinar e criar uma solução incrivelmente robusta e performática. Abordagens relacionais foram de extrema importância nos últimos anos, e vão continuar sendo!

• Quaisquer problemas que não são especificados para o padrão linha/coluna não são os dados ideais para se colocar num banco relacional. Dá pra ser feito, mas não é o ideal e não é performático. Um livro, por exemplo, com estrutura em árvore, com indices, capítulos, headers, footers, notas de rodapé… Você pode estar pensando que tudo isso cabe num banco relacional. Sim, cabe, mas você acha que é a melhor forma de armazená-los?
• Qualquer mudança no schema de um banco pode ser bem traumático pra todos que atuam nos sistemas que o utilizam. Em bancos relacionais é investido um grande esforço no design (e redesign) do modelo de dados de maneira que, quando essas informações são alteradas, muitas pessoas são envolvidas: os administradores do banco devem alterar as tabelas; alterar as views; migrar dados, se necessário; desenvolvedores devem alterar exatamente todas as queries que envolvem essa estrutura, etc. Um alto custo. Como NoSQL não tem um schema estruturado, essa mudança é bem menos traumática.
• Em um banco relacional, devemos pensar no tratamento de dados históricos. Como tratar os dados que foram inseridos em uma estrutura anterior? Em uma tabela antiga, que precisou ser remodelada ou mesmo removida do projeto. Devemos versionar os dados? Devemos manter a tabela no banco, correndo o risco de um desenvolvedor desavisado passar a utilizá-la novamente? Em bancos NoSQL, você mantém o dado exatamente da forma que foi inserido.
• Em um banco relacional, devemos manter campos que sempre (ou quase sempre) serão nulos. E Estes campos causam sujeira e ocupam um espaço precioso em nossa aplicação. Bancos NoSQL não possuem esse problema, pois salvam somente o que a aplicação passa para ele, somente o que é necessário para aquele cadastro.

Se essas questões foram provocativas pra você, então iniciamos nossa jornada no mundo de NoSQL. Escreverei alguns próximos artigos com mais conceitos e visitando alguns dos tipos mais famosos utilizados no mundo corporativo e outros, nem tanto. Até o próximo artigo!