resenha de artigo - query processing over data warehouse using relational databases and nosql

1 MBA em Arquitetura de Soluções 1 Administração de SGDB e Modelagem de Dados

PÓS-GRADUAÇÃOPÓS-GRADUAÇÃO

MBA em Arquitetura de Soluções

Módulo Arquitetura de Informações

Query Processing Over Data Warehouse using relational Databases and NoSQL

Constantino Junior

Felipe Caparell

Felipe Lima

Robson Moreira

Profa Dra Regina CanteleOut/2013


1. Introdução 1.1 Resenha do Artigo

1.2 Objetivo(s)

1.3 Contribuições do Artigo

1.4 Organização

2. Fundamentos: Data Warehouse

3. Fundamentos: NoSQL

4. Resultados

5. Conclusões

SUMÁRIOSUMÁRIO


Comparar o desempenho do processamento de consulta em bases NoSQL e relacionais

Exemplificar a aplicação de cada modelo (NoSQL e relacional)Apresentar os 3 tipos existentes de modelos de dados NoSQL: Chave-valor Orientado a coluna Orientado a documentos

• São comparadas ferramentas que seguem os modelos orientados a colunas e documentos com o modelo relacional

1.1 INTRODUÇÃO: RESENHA DE ARTIGO1.1 INTRODUÇÃO: RESENHA DE ARTIGO


Motivação do artigo: Investigar e Comparar o uso de modelos de dados NoSQL e relacional, utilizando as principais técnicas para otimização de processamento de consultas OLAP sobre DW.

1.2 OBJETIVO(S)1.2 OBJETIVO(S)


Comparação das técnicas de processamento de consultas sobre DW em diferentes ferramentas desenvolvidas seguindo modelos de bases de dados NoSQL e relacional;

Realização de testes experimentais usando duas bases de dados sintéticas contendo diferentes volumes de dados para cada um dos modelos orientados a colunas e a documentos, além de bases de dados relacionais;

Identificação de cenários eficientes, usados nas comparações nesse artigo, para o processamento de consultas em DW, auxiliando a construção de ferramentas OLAP para processar consultas com baixo tempo de resposta.

1.3 CONTRIBUIÇÕES DO ARTIGO1.3 CONTRIBUIÇÕES DO ARTIGO


O artigo está dividido em:

Seção 2: Apresentação dos conceitos fundamentais

Seção 3: Discussão dos resultados dos testes

Seção 4: Conclusão sobre os resultados obtidos

1.4 ORGANIZAÇÃO DO ARTIGO1.4 ORGANIZAÇÃO DO ARTIGO


2. FUNDAMENTOS: DATA WAREHOUSE2. FUNDAMENTOS: DATA WAREHOUSE

Integra informações de diversas fontes para a tomada de decisões estratégicas.

Base de dados histórica, não volátil, e intrinsecamente volumosa.

São executadas Consultas Analíticas processadas por OLAP.



Conceitualmente um DW é representado por meio de um hipercubo de dados multidimensional



O projeto lógico de um DW pode utilizar o esquema estrela ou o esquema floco de neve.



Ambos os esquemas são compostos por uma tabela de fatos e por tabelas de dimensão

Tabela de fatos: armazena as medidas que representam quantitativamente o negócio analisado, além de manter chaves estrangeiras para as tabelas de dimensão

Tabela de dimensão: fornece as características do negócio e seus atributos podem formar hierarquias



Hierarquias de atributos permitem a agregação de dados e consequentemente o processamento de consultas drill-down e roll-up, amplamente usadas em aplicações OLAP

O esquema floco de neve difere do esquema estrela por normalizar as hierarquias contidas nas tabelas de dimensão, aumentando assim o número de junções.



Ferramentas OLAP

Processam Consultas Analíticas

Fornecem Visões Multidimensionais

Suportam Planejamento Estratégico

Para a tomada de decisão estratégica, um fator de importância é o processamento eficiente de consultas OLAP para reduzir o alto tempo de resposta



Processamento no DW:

Junção Estrela - forma mais custosa para se processar uma consulta em DW

Técnicas para melhorar o desempenho:

Fragmentação dos dados

Visão materializada

Estruturas de indexação



Fragmentação dos dadosVisão fragmentada verticalmente (VFV)

Conjunto mínimo de atributos necessários

VFV computa previamente junções envolvidas entre as tabelas de dimensão e fatos

Consultas sobre VFV dispensam o uso de junções



Visão materializada (VM)Conjunto mínimo de atributos

VM ocupa menos espaço de armazenamento que uma VFV em operações de filtragem

A construção da VM computa previamente as junções e agrupamentos entre as tabelas de dimensão e fatos

Processa previamente agrupamentos e resultados das funções de agregação sobre as medidas

VM reduz os dados armazenados devido ao seu agrupamento



Estrutura de IndexaçãoÍndice bitmap de junção

Composto por vetores de bits (valores 0 e 1)

Um vetor para cada valor distinto do domínio

Principal vantagem: realiza operações bit-a-bit

Criado sobre atributos das tabelas de dimensão

Objetivo: evitar a operação de junção das tabelas de dimensão com a tabela de fatos


2. FUNDAMENTOS: NoSQL2. FUNDAMENTOS: NoSQL

NoSQL: desenvolvidos visando atender os seguintes aspectos:

Alta concorrência na escrita e leitura de dados

Armazenamento e processamento de consultas eficientes em grande volumes de dados

Alta escalabilidade e disponibilidade

Redução de custos e gerenciamento operacional



No contexto de DW: NoSQL se torna um mecanismo interessante:

Armazenamento

Processamento de consultas em grandes volumes de dados

Principais modelos de bases de dados NoSQL:

Armazenamento chave-valor

Orientado a coluna

Orientado a documentos



Chave-valor: Armazena dados estruturados como pares de chaves e valores

Uma chave é um identificador para diversos valores (podem ser expressos por índices hash)

Modelo de estrutura mais simples

Inserções de dados e consultas realizadas intrinsecamente sobre as chaves

Alto Desempenho

Um modelo baseado somente em chave-valor é inviável modelar um DW para processar consultas ad-hoc



Orientado a colunas: Armazena os dados em colunas de uma tabela

Diferente do modelo relacional, as tabelas não possuem relacionamento e são armazenadas separadamente

Cada coluna é exclusivamente independente em cada tabela

As colunas podem ter índices padrões e formas de compressão dos dados (melhorar o processamento de consultas e o armazenamento)

LucidDB – SGBD orientado a colunas, criado para ambiente Data Warehousing.



Orientado a documentos: Armazena documentos

Geralmente JSON com uma chave associada

Utilizado o modelo chave-valor, associando a uma chave um respectivo documento

Permite consulta e indexação dos valores contidos nas chaves (documentos)

Consultas ad-hoc sobre atributos dos documentos armazenados


3. RESULTADOS3. RESULTADOS

Ferramentas Utilizadas:FastBit e LucidDB (modelo orientado a coluna)

FastBit: resultados satisfatórios em processamento de consultas sobre DW ao utilizar o índice bitmap de junção

LucidDB: projetado para o ambiente de data warehousing

MongoDB (modelo orientado a documentos)MongoDB: software muito utilizado na indústria; armazena dados em JSON

PostgreSQL (SGBD) sistema gerenciador de banco de dados relacional

Todos eles são softwares livres



Ferramentas Utilizadas: 2 bases de dados (DW01 e DW10)

Construídas utilizando o Star Schema Benchmark (SSB)

PC: processador Intel(R) Pentium(R) D com frequência de 2,80Ghz, HD SATA de 320 GB com 7200 RPM, e 2 GB de memória principal.

SO: Fedora 16

Foi investigado o desempenho de cada ferramenta para processar consultas OLAP sobre DW



Os testes foram realizados localmente para inibir a latência da rede.

Todas as consultas do SSB foram executadas e o cache limpo após a execução de cada consulta.

Cada consulta foi executada 5 vezes, e posteriormente calculado o tempo de execução médio em segundos.



O desempenho do MongoDB + DI foi o pior entre todas as outras configurações com tempos médios proibitivos

MongoDB + VFV apresentou melhores tempos que a configuração MongoDB + DI

As configurações que utilizaram a junção estrela (LucidDB + SJ e PostgreSQL + SJ) apresentaram também resultados proibitivos

A configuração FastBit + VFV apresentou os melhores resultados no desempenho do processamento de consultas



índices bitmap de junção beneficiaram o tempo de resposta no processamento de consultas

Apesar da configuração LucidDB + VFV utilizar índices bitmap de junção, esta configuração não apresentou bons resultados (justificada pela implementação dos referidos índices)

FastBit + VFV apresentou reduções de tempo de resposta significativas em relação as outras configurações (mais eficiente entre todas as configurações)

Índices bitmap de junção implementado pelo FastBit melhoraram o desempenho para processar consultas sobre DW



O tempo total de construções das configurações Postgres + VFV, LucidDB + VFV, MongoDB + VFV e FastBit + VFV são mostradas na Tabela abaixo (DW1)



Em relação ao espaço de armazenamento das visões fragmentadas verticalmente (VFV) e índices bitmap de junção, seus requisitos são mostrados no gráfico abaixo (DW1)



Visões fragmentadas verticalmente e índices bitmap de junção construídos para o grupo Q1 requereram menos espaço que para os demais grupos

MongoDB requereu um maior espaço de armazenamento

O LucidDB mostrou bons resultados, devido à compressão dos dados por padrão, além da compressão dos índices bitmaps construídos

O espaço de armazenamento requerido variou de acordo com a consulta



O tempo total de construções das configurações Postgres + VM, LucidDB + VM, MongoDB + VM, FastBit + VM e FastBit + VFV são mostradas na Tabela abaixo (DW10)



Espaço requerido de armazenamento requerido para as visões materializadas e índices bitmap de junção de cada grupo de consultas (DW10)


4. CONCLUSÕESCONCLUSÕES

O objetivo foi identificar um modelo de dados (NoSQL ou relacional) que proporcionasse o melhor desempenho no processamento de consultas OLAP + bom uso do espaço de armazenamento

Resultados

LucidDB MongoDB FastBit

Melhor Custo de Armazenamento X

Melhor Execução das Consultas X

Melhor uso Espaço de Armazenamento X


4. CONCLUSÕESCONCLUSÕES

Isso indica que a utilização do FastBit com a ferramenta, irá se sobressair sobre outras ferramentas OLAP baseadas nos modelos avaliados neste artigo.

O FastBit, como mecanismo de busca, favorece a tomada de decisão estratégica, uma vez que diminui o tempo de respostas das consultas analíticas sobre DW.

resenha de artigo - query processing over data warehouse using relational databases and nosql

Technology