Big Data- Parte IX- Os Big Data e as formas de armazenamento-Novas soluções-II.

Continuação do post anterior: Discutindo alternativas para implantação de Big Data com novas proposições e estruturações físicas.

Triplestore:

Outra forma de estruturação de dados se avizinha, buscando uma maior flexibilidade na definição dos bancos de dados construídos na era dos zettabytes. É chamada de Triplestore e nasceu como uma forma de embutir dados e metadados na própria estrutura armazenada. Diferentemente dos modelos relacionais que se baseiam na definição de ênuplas(várias colunas com valores, numa relação normalizada), conceito simplificado para tuplas, a abordagem de triplestore chega com uma proposta diferente. A ideia é que a unidade de armazenamento mínima seja uma tripla, ou seja a conjugação de “sujeito” “predicado”  e “objeto”. Por exemplo, “Barbieri” “escreveu” “livro” , ou “Isabella”  “toca”  “violão”, ou “Cláudio”  “tem”  “30”  (idade). Dessa forma, o armazenamento se dá conjugando os metadados com os dados, explicitados através da tripla combinação desses elementos. Isso sugere uma maior flexibilização na incorporação de novos atributos, visto que se insere uma estrutura atômica do modelo, sem impacto direto em conceitos de tabelas, linhas, etc. O modelo se baseia no framework RDF- Resource Description Framework (RDF) . Semelhantemente ao modelo relacional existe também acoplado a ele uma linguagem de acesso e possibilidades de indexações instantâneas. Os gerenciadores de triplestore já se mostram com a capacidade para  armazenar bilhões de triplas e alguns nomes já surgem nesse novo cenário, engrossando os conceitos da Web semântica. Por exemplo, 3store, Allegrograph, Bigdata, BigOWLIM, Sesame, Soprano,Virtuoso,etc são nomes que aparecem nesse cenário de novas alternativas estruturais. O site da W3C http://www.w3.org/wiki/LargeTripleStores mostra uma relação com diversos produtos desta nova cepa e alguns resultados alcançados por mais de 15 desses RDF Data Base Engine. Alguns desses produtos, como Virtuoso apresenta novas formas de indexações com bitmap, tradicionalmente usado em pesquisas de campos de baixa cardinalidade.

Casssandra:

Outra variante de modelo de dados para esses novos tipos de Bancos de dados é, por exemplo, o usado no Cassandra:

a)As colunas, que são as residências das informações, são associadas logicamente em conjuntos chamados “família”. Uma família de colunas pode ter várias colunas, ou até uma outra família dentro dela. As famílias são definidas no momento da criação do BD. Porém, após esse momento, pode-se criar colunas novas dentro daquela família de colunas;

b)As colunas são associadas a chaves específicas, ou seja uma tupla(linha no relacional) pode ter colunas diferentes. No modelo relacional deve-se usar o conceito de “nulos” para as colunas que não tem valores naquela tupla. Os valores de uma família de colunas, associadas a uma chave, são armazenadas juntas.

Em alguns produtos semelhantes, as colunas são armazenadas também contendo as regras de  de domínios, numa espécie de acoplamento dos dados com os seus metadados, todos habitando o mesmo espaço. Isso permite que  consistências e integridades sejam aplicadas no momento de acesso ao dado, agilizando as verificações e manipulações  aplicadas sobre eles e definidas como regras.

MongoDB

Um dos produtos que começa a aparecer nessa nova seara de NoSQL é o MongoDB. Já usado em algumas aplicações específicas em BH, o produto se denomina um Banco de dados de documentos. Na realidade, o conceito de documento apresentado pelo produto pode ser entendido como o de um “objeto complexo”. Semelhantemente aos SGBDOO(Bancos de Dados orientados a objetos) dos anos 80, o Mongo permite sob a capa de um documento, a definição de um objeto complexo.  E o que é um objeto complexo, então? Um objeto complexo é a definição de uma estrutura de dados, totalmente flexível e sem regras estruturais colocadas, como vimos no modelo relacional, ou um pouco nos anteriores(hierárquico e rede). Nessa nova proposta, por exemplo, cada linha(só para dar a equivalência conceitual com os relacionais), pode conter qualquer número de dados associados a uma chave primaria, um Object-id definido internamente. Os dados associados a cada chave podem formar famílias de colunas, sendo que cada coluna pode ser , por sua vez, uma estrutura complexa, como outra família de colunas, ou array, ou apontadores recursivos. Cada linha, identificada, pode ter um número de colunas diferente de outras linhas da mesma Entidade.  Por exemplo, um  certo cliente poderá ter 20 colunas, e outro 100, fugindo um pouco das abordagens de campos nulos, trazidos nos conceitos relacionais, para tornar as linhas homogêneas. Assim, por exemplo,  um documento (objeto) Projeto pode ser formado de dados de projetos, de dados de Equipes, que por sua vez são formadas de dados de Empregados. O que acontece é que o que seriam estruturas bem comportadas em modelos relacionais ou hierárquicos, no MongoDB, pode aparecem como um objeto complexo, como que já “joined” e entrelaçados. Embora com uma estruturação complexa, passível de recursividades, o produto permite que a busca seja feita somente trazendo os pedaços de informações desejadas. Usam a indexação baseada em BTree e permitem acessos muito rápidos em dados estruturados segundo essa concepção. Não oferece conceitos transacionais padrão de ACID e de SQL, ficando por conta do programador a incumbência de estabelecer esses controles, caso desejados. Tem forte vocação para inserções em massa, com dados sem grande volatilidade de modificações. Exatamente como se espera em aplicações como Twitter, Linkedin,Facebook, e-mails, etc onde milhões de “posts”  são inseridos, mas não deletados ou modificados. A sua estrutura de objeto complexo permite a modelagem de informações de forma rica, criando possibilidades de aplicações em gerência de conhecimento, repositórios para produtos de BPM, etc.

Resumo da ópera:

Com a diminuição de custos de armazenamento e a busca por maior rapidez e flexibilidade nas estruturações e pesquisas, o conceito de BI2 também se valerá dessas novas proposições, principalmente para armazenamento de grandes volumes de dados que se mostram como forte tendência nessa década. Existe um conjunto enorme de alternativas desenvolvidas e em desenvolvimento, na sua maioria dentro do espaço dos códigos livres. O segredo para se adotar uma proposição correta  será:

1)Analisar cuidadosamente os seus requisitos de dados(estruturados, semi-estruturados, ou não estruturados), com análise crítica das necessidades de volumes, velocidade de processamento e periodicidade e tipos de atualização;

2)Executar provas de conceitos, usando essas novas propostas e verificando a sua efetiva aplicação no item anterior(requisitos). Essas ferramentas podem ser “baixadas” de núcleos sérios como Fundação Apache, por exemplo;

3)Analisar a relação custo benefício, que envolverá não somente a parte de arquitetura de “nós” , mas também a capacitação da equipe em técnicas em conceitos returbinados como DFMS(Distributed File Management System), processamentos em arquiteturas  paralelas, ambiente de alta tolerância, replicações,etc;

4)Finalmente decidir na teoria do melhor “encaixe” nas necessidades da empresa,  cuidando para deixar de lado o ímpeto pelo uso dos modismos. Lembre-se que para cada problema poderá aparecer uma solução adequada, seja ela o velho e tradicional SGBDD, ou os novos e desafiadores frameworks, como Hadoop/MapReduce, ou soluções NOSQL.

A figura abaixo ilustra os principais conceitos que diferenciam o tradicional modelo relacional e os novos modelos NoSQL.

A figura abaixo ilustra os principais conceitos que diferenciam o tradicional modelo relacional e os novos modelos NoSQL.

Fontes:

Barbieri,C. BI2-Business Intelligence-Modelagem e Qualidade. Elsevier,2011

Roebuck, K. Storing and managing  big data-NoSQL,Hadoop and more

O´Reilly Radar Team. Big Data Now: Current perspectives from O´Reilly Radar

Sydle-Entrevista com a equipe de BD da empresa, sobre a aplicação de MongoDB-Novembro de 2011