Meu Deus, existem tantas ferramentas para armazenamento do NoSQL por aí. É quase tão ruim quanto as marcas de bebidas esportivas, ou de água. Você notou que alguns supermercados imensos têm corredores inteiros dedicados ao que bebemos?

Como um administrador ou gerente de sistemas de TI, às vezes é muito difícil comparar várias ferramentas do NoSQL. Isso envolve a consideração das suas necessidades computacionais especiais, e o alinhamento das mesmas ao que é disponibilizado no mercado, combinando o que é certo para a sua empresa e então tomando a decisão certa!

É por isso que Monitis, um serviço tudo-em-um de monitoramento de performance de redes e sistemas para sysadmins, está publicando uma série de blogs que tinham o objetivo de oferecer um guia compreensivo para a tecnologia e para as marcas do NoSQL. O objetivo é te ajudar a fazer a escolha certa que atende à necessidade específica da sua empresa.

Por que deveríamos nos importar? - você pode se perguntar. Cada vez mais, nossos clientes, que dependem da nossa habilidade de monitorar servidores e redes e de várias outras métricas-chave dia e noite a partir da nuvem, também querem nosso conselho sobre qual tipo de tecnologia de banco de dados escalável e robusto usar. Portanto, estamos sendo prestativos!

Portanto, apresentaremos pesquisas em ferramentas populares existentes de armazenamento de dados NoSQL, que têm o intuito, geralmente, de armazenar quantidades imensas de dados sem precedentes, oferecer escalabilidade horizontal e flexível, e fornecer o processamento de consultas absurdamente rápido. Também chegaremos ao âmago da questão e iremos comparar vários bancos de dados NoSQL bastante conhecidos, como Cassandra, MongoDB, CouchDB, Redis, Riak, HBase e outros.

Neste primeiro artigo, vamos discutir sobre a razão pela qual a tecnologia NoSQL é importante.

Então, o que é NoSQL?

Geralmente, o NoSQL não é relacional e foi projetado para armazenamento distribuído de dados, para dados de grande escala (p.e. o Facebook ou o Twitter acumulam terabits de dados todos os dias para milhões de usuários), e não existem fixed schemas e joins. Enquanto isso, sistemas de gerenciamento de bancos de dados relacionais (RDBMS) geram escalonamento ao deixar seu hardware cada vez mais rápido e adicionando memória. O NoSQL, por outro lado, pode tirar vantagem de “escalar para baixo” – o que significa distribuir o carregamento entre muitos outros sistemas de conveniência.

O acrônimo NoSQL foi criado em 1998 e, enquanto muitos pensam que o NoSQL é um termo depreciativo criado para tirar sarro do SQL, na verdade ele significa “Não Somente SQL – Not Only SQL”. A ideia é que ambas tecnologias (NoSQL and RDBMSs) podem coexistir e cada uma delas tem o seu lugar. Empresas como Facebook, Twitter, Digg, Amazon, LinkedIn e Google usam o NoSQL de alguma maneira - então o termo tem estado nas notícias atuais nos últimos anos.

Qual o problema com RDBMSs?

Bom, nada, na verdade. Eles apenas têm suas limitações. Considere estes três problemas com RDBMSs:

RDBMSs usam uma abordagem de normalização com base em tabela de dados, e esse modelo é limitado. Certas estruturas de dados não podem ser representadas sem adulteração dos dados, programas, ou ambos...

Elas permitem versionamento ou atividades como: Criar, Ler, Atualizar e Deletar. Para banco de dados, atualizações nunca deveriam ser permitidas, porque elas destroem a informação. Em vez disso, quando os dados mudam, o banco de dados deveria apenas adicionar outro registro e anotar devidamente o valor para aquele registro.

A performance é perdida quando o RDBMSs normaliza os dados. O motivo: a normalização pede mais tabelas, joins de tabelas, chaves e índices e, dessa maneira, mais operações internas do banco de dados para implementar as consultas. Logo logo, o banco de dados começa a crescer para o tamanho de terabytes, e é aí que as coisas começam a ficar lentas.

As quatro categorias do NoSQL

1. Armazenamento Chave-Valor. A ideia principal aqui é usar uma tabela hash na qual há uma chave única e um indicador de um dado ou de um item em particular. O modelo chave-valor é o mais simples e fácil de implementar. Mas ele é ineficiente quando você somente está interessado em consultar ou em atualizar parte de um valor, entre outras desvantagens.

2. Armazenamento Column Family. Foram criadas para armazenar e para processar grandes quantidades de dados distribuídos em muitas máquinas. Ainda existem chaves, mas elas apontam para colunas múltiplas. As colunas são organizadas por família da coluna.

3. Banco de Dados orientado a Documentos. Foram inspirados por Lotus Notes e são similares ao armazenamento chave-valor. O modelo é basicamente documentos versionados que são coleções de outras coleções de chave-valor. Os documentos semi-estruturados são armazenados em formatos como JSON. Bancos de dados de documentos são essencialmente o próximo nível do chave-valor, permitindo valores aninhados associados a cada chave. Bancos de dados de documentos suportam as consultas mais eficientemente.

4. Banco de Dados orientado a Grafos. Em vez de tabelas com linhas e colunas e a rígida estrutura do SQL, um modelo gráfico flexível é usado e que pode, mais uma vez, ser escalado através de varias máquinas. Bancos de dados NoSQL não fornecem uma linguagem query declarativa de alto nível como o SQL para evitar tempo extra em processamento. Em vez disso, executar o querying nesse banco de dados é um modelo de dados específico. Muitas das plataformas NoSQL permitem interfaces RESTful nos dados, enquanto outras oferecem query APIs.

Geralmente, os melhores lugares para usar a tecnologia NoSQL é onde o modelo de dados é simples; onde flexibilidade é mais importante que controle rígido sobre estruturas definidas de dados; onde alta performance deve existir; consistência de dados rígida não é necessária; e onde é fácil mapear valores complexos para chaves conhecidas.

Alguns exemplos de quando usar NoSQL 

Logging/Arquivamento. Ferramentas de Log-mining vêm a calhar porque elas conseguem acessar logs através de servidores, relacioná-los e analisá-los..

Insight em computação social. Muitas empresas hoje forneceram a seus usuários a habilidade de atuar na computação social através de fóruns de mensagens blogs etc.

Integração de feed de dados externos. Muitas empresas precisam integrar os dados oriundos de seus parceiros. Mesmo se as duas partes conduzirem várias discussões e negociações, as empresas têm pouco controle sobre o formato dos dados que chegam a elas. Além disso, existem muitas situações em que esses formatos mudam muito frequentemente - baseado na mudança das necessidades de negócios dos parceiros.

Sistemas de processamento de pedidos Front-end. Hoje, o volume de pedidos, aplicações e serviços flutuando através de diferentes canais para comerciantes, banqueiros e seguradoras, fornecedores de entretenimento, logística etc é enorme. Esses pedidos precisam ser capturados sem nenhum interrupção sempre que um usuário final faz uma transação de qualquer parte do mundo. Depois disso, um sistema de reconciliação tipicamente os atualiza para sistemas de back-end, ao mesmo tempo que atualiza o usuário final com o seu status.

Serviço de gerenciamento de conteúdo empresarial. O gerenciamento de conteúdo agora é utilizado através de diferentes grupos funcionais da empresa, como RH ou vendas. O desafio é congregar grupos diferentes utilizando estruturas diferentes de metadados em um serviço comum de gerenciamento de conteúdo.

Estatísticas/análises em tempo real. Às vezes, é necessário usar o banco de dados como uma maneira de rastrear métricas de performance em tempo real para websites (visualizações de páginas, visitas únicas etc). Ferramentas como o Google Analytics são ótimas, mas não são em tempo real - às vezes, é util construir um sistema secundário que fornece estatísticas em tempo real. Outras alterativas, como monitoramento de tráfego 24/7, são uma boa opção também.

Que tipo de armazenamento devo usar?

Aqui está um breve resumo que deve te ajudar a decidir:

Em outros artigos, voltarei a falar do assunto, te guiando através de sete bancos de dados populares do NoSQL e discutindo seus méritos e seus problemas. Fique ligado!

⁂

Texto original disponível em http://blog.monitis.com/index.php/2011/05/22/picking-the-right-nosql-database-tool/