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
Excelente. E compacto. :-)
ResponderExcluirSó para somar às informações, seguem as ponderações
do Mestre Stonebraker et al. :
http://nms.csail.mit.edu/~stavros/pubs/hstore.pdf
Sds, LéoGrandi