Stores NoSQL de dados contra o Hadoop

armazenamentos de dados NoSQL originalmente subscrito com a noção # 147-Just Say No to SQL # 148- (parafraseando a partir de uma campanha publicitária anti-drogas na década de 1980), e eles foram uma reação às limitações percebidas de bancos de dados relacionais (baseadas em SQL). Não é que essas pessoas odiado SQL, mas eles estavam cansados ​​de forçar pinos quadrados em buracos redondos, resolvendo problemas que bancos de dados relacionais não foram projetados para.

Um banco de dados relacional é uma ferramenta poderosa, mas para alguns tipos de dados (como pares chave-valor, ou gráficos) e alguns padrões de uso (como o armazenamento extremamente grande escala) de um banco de dados relacional apenas não é prático. E quando se trata de armazenamento de alto volume, banco de dados relacional pode ser caro, tanto em termos de custos de licença de banco de dados e os custos de hardware. (Bancos de dados relacionais são projetados para trabalhar com hardware de nível empresarial.)

Assim, com o movimento NoSQL, programadores criativos desenvolvidos dezenas de soluções para diferentes tipos de problemas de armazenamento e processamento de dados espinhosas. Esses bancos de dados NoSQL normalmente fornecem escalabilidade por meio de clustering, e muitas vezes são projetados para permitir alto rendimento e baixa latência.

O nome NoSQL é um pouco enganador, porque muitos bancos de dados que se encaixam na categoria Faz tem suporte SQL (em vez de # 147 NoSQL # 148- suporte). Pense em seu nome, em vez de # 147-Not Only SQL # 148.;

As ofertas de NoSQL disponíveis hoje em dia pode ser dividido em quatro categorias distintas, com base na sua concepção e finalidade:

• lojas de valores-chave: Esta oferta fornece uma maneira de armazenar qualquer tipo de dados sem ter que usar um esquema. Isso está em contraste com bancos de dados relacionais, onde você precisa para definir o esquema (estrutura de tabela) antes de qualquer dado é inserido. Desde que as lojas de valor-chave não requerem um esquema, você tem uma grande flexibilidade para armazenar dados em vários formatos.

  Em uma loja de key-value, uma linha consiste simplesmente de uma chave (um identificador) e um valor, que pode ser qualquer coisa de um valor inteiro para uma grande cadeia de dados binário. Muitas implementações de lojas de valor-chave são baseados em papel Dynamo, da Amazon.

• lojas familiares coluna: Aqui você tem bancos de dados em que as colunas são agrupadas em famílias de colunas e armazenados juntos no disco.

  Estritamente falando, muitos desses bancos de dados não são coluna-orientado, porque são baseadas em papel BigTable do Google, que armazena dados em um mapa classificadas multidimensional.

• repositórios de documentos: Esta oferta depende de coleções de documentos semelhante codificados e formatados para melhorar a eficiência. repositórios de documentos permitir que documentos individuais em uma coleção para incluir apenas um subconjunto de campos, de modo que apenas os dados que é necessário é armazenado. Para conjuntos de dados esparsos, onde muitos campos muitas vezes não são preenchidos, isso pode se traduzir em economia de espaço significativa.

  Por outro lado, colunas vazias em tabelas de banco de dados relacional não ocupam espaço. lojas documento também permite a flexibilidade do esquema, porque apenas os campos que são necessários estão armazenados e novos campos podem ser adicionados. Mais uma vez, em contraste com bancos de dados relacionais, estruturas de tabela são definidas na frente antes de os dados são armazenados, e mudando colunas é uma tarefa tediosa que afeta todo o conjunto de dados.

• bancos de dados de gráfico: Aqui você tem bancos de dados que armazenam grafos - representações que mostram coleções de entidades (vértices ou nós) e suas relações (bordas) uns com os outros. Estas estruturas permitem que os bancos de dados do gráfico a ser extremamente bem adequado para o armazenamento de estruturas complexas, como as relações que ligam entre todas as páginas web conhecidos. (Por exemplo, páginas web individuais são nós, e as bordas de ligação deles são links de uma página para outra.)

  Google, é claro, é tudo sobre a tecnologia de gráfico, e inventou um mecanismo de processamento gráfico chamado Pregel para alimentar seu algoritmo PageRank. (E sim, há um livro branco sobre Pregel.) Na comunidade Hadoop, há um projeto Apache chamado Giraph (com base no papel Pregel), que é um mecanismo de processamento gráfico projetado para processar gráficos armazenados no HDFS.

As opções de armazenamento e processamento de dados disponíveis no Hadoop são, em muitos casos as implementações das categorias NoSQL listadas aqui. Isso irá ajudá-lo a avaliar melhor as soluções que estão disponíveis para você e ver como Hadoop pode complementar armazéns de dados tradicionais.