Olá amigos, boa parte das questões acerca do NoSQL estão relacionadas à discernir quando é melhor utilizá-lo, e quando desta, qual modelo se adere melhor a nossa necessidade.

Antes de iniciar gostaria de frisar que NoSQL não significa a abolição dos bancos de dados relacionais, como o SQL Server, MySQL e Oracle (para citar alguns dos mais conhecidos), mas este assunto deixo para abordar melhor em outro post com mais detalhes. Vamos focar em definir as situações para escolher o melhor banco de dados.

Quando usar NoSQL

Por definição, os banco de dados NoSQL (not only sql) foram desenvolvidos para fornecer boa performance para trabalhar com grandes volumes de dados – principalmente os dados não relacionais – em um ambiente que necessita grande escalabilidade. Então use o NoSQL quando você estiver em um cenário onde:

Necessitamos trabalhar com grandes volume de dados

Quando temos um cenário onde temos um volume muito grande de dados – na casa dos terabytes e petabytes – a serem manipulados, como por exemplo os dados de indexação de páginas do Google (BigTable)

Quando necessitamos de desempenho para escrita dos dados

Quando necessitamos escrever os dados com um bom desempenho (tendo como única barreira o tempo de I/O da storage), como por exemplo armazenar um grande volume de dados de Log ou Auditoria de um sistema grande.

Ter rápido acesso a dados armazenados como Chave/Valor

Quando necessitamos recuperar rapidamente dados armazenados no esquema de Chave/Valor no meio de petabytes de informação.

Quando seus dados não tem um esquema definido

Quando armazenamos dados que  não possuem um esquema de dados bem definido, como um conjunto de arquivos de um usuário no 4Shared (não sei se é assim que eles utilizam hoje).

Ter alta disponibilidade com fácil balanceamento dos dados

Quando necessitamos que os dados estejam bem distribuídos entre os servidores, e que seja fácil adicionar novos nós de armazenamento na árvore, sem grandes esforços e sem criar grandes indisponibilidades.

Qual modelo escolher

Para atender este grupo de necessidades, há diferentes tipos de bancos de dados NoSQL, lendo pela internet, você verá que eles geralmente são agrupados entre 4 a 6 categorias, eu pessoalmente prefiro – e acredito que se encaixem muito bem – em apenas 4, sendo elas:

Chave/Valor

É o modelo mais simples, baseia-se em uma “tabela hash”, onde cada chave é unica. Este modelo é muito prático para se armazenar sessões de usuários por exemplo.

Documento

São muito similares ao modelo Chave/Valor, sendo um próximo nível de complexidade do modelo, armazenando coleções de chave/valor, permitindo valores aninhados associados a cada chave. São muito usados na Web e para a criação de CRUD

Tabular

Foram criadas para armazenar e para processar grandes quantidades de dados distribuídos em muitas máquinas. As chaves apontam para múltiplas colunas. Pode ser bem usado para log de atividades ou uma time line por exemplo.

Grafos

É um sistema de armazenamento baseado em relacionamento entre os nós que possuem flexibilidade de formato. Ideal para uso em redes sociais e outros problemas de grafos.

 

Para tentar demonstrar melhor o problema, fiz uma pequena adaptação de uma demonstração criada originalmente pelo Martin Fowler em seu post que fala sobre a persistência poliglota. A persistência poliglota, de forma ampla, nada mais é do que usar em um único sistema, diversos recursos de persistência (entre NoSQL e Relacional) para as mais diferentes funcionalidades a fim de conseguir o melhor benefício de cada das plataformas, solucionando de forma otimizada cada um dos problemas.

Neste exemplo, vemos para cada parte de um sistema WEB para vendas de varejo (como a Amazon, Americas, Submarino, etc..) qual a melhor persistência utilizar.

Para as sessões dos usuários e itens do carrinho, usamos um modelo baseado em Chave/Valor. Para o catálogo de produtos, usamos um bando de dados de documentos. Para Log de atividade e dados analíticos, um modelo tabular. Para o lista de recomendações – aquele típico “Quem comprou isto também comprou aquilo” – usamos um bando de dados de grafos. Enquanto para os dados financeiros e reports, usamos o já bem consolidado Bando Relacional (SQLServer, MySQL, Oracle, etc…).

Dicas Finais

O mais importante no momento de decidir qual a melhor forma de persistir seus dados é não ter preconceito e não ficar preso a modinhas, grande parte das reclamações que li pela internet sobre bancos de dados NoSQL vieram em principal de pessoas que ou resolveram abolir o SQLServer para adotar 1 (um) banco de dados NoSQL, e depois vir reclamar que ele não foi bom para isto ou aquilo (como disse, para cada problema um banco NoSQL diferente, e para vários casos, ainda prevalecerá o bom e velho modelo relacional).

Estude bem seu problema e reflita sobre suas necessidades, escolha o melhor modelo para o problema, e teste as diferentes soluções disponíveis até verificar qual melhor se adéqua.

 

Bom, espero que o post possa lhes facilitar na hora de escolher o melhor banco NoSQL para seu problema. Agora baixe algumas soluções e se divirta um pouco, nada melhor do que botar a mão na massa para ver os poderes e possibilidades da tecnologia.

 

Enjoy!