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/