Daniel J. Abadi – Yale - New Haven, USA Samuel R. Madden – MIT – Cambrigde, USA Nabil Hachem...

Daniel J. Abadi – Yale - New Haven, USASamuel R. Madden – MIT – Cambrigde, USA

Nabil Hachem – Avantgarde Consulting – Shrewbury, USASIGMOD '08

Apresentado por Jhean M Lanski e Rodrigo A Araujo

Column-Stores vs. Row-Stores: How Different Are They Really?

Introdução Motivação Proposta/Objetivo Star Schema Benchmark Modificações no Row-Oriented Resultados: Row-Oriented Modificações no Column-Oriented Resultados: Column-Oriented Conclusões

Agenda

Introdução

Column-StoreAtributos ao invés de Tuplas.

Orientado a leitura.

Escritas podem demandar vários acessos.

Data Warehouse, Decision Support, Business Intelligence.

Introdução

Motivação

Column-Store vs Row-Store?Depende do cenário,

Não é uma comparação que faz sentido.

Primeira Questão:É possível obter o desempenho de um Column-Oriented em um Row-Oriented usando um design físico mais orientado a coluna?

Proposta/Objetivo

1) Simular um sistema Column-Oriented usando um sistema Row-Oriented.

2) Analisar as funcionalidades exclusivas de um Column-Oriented explorando o aumento na performance que cada funcionalidade proporciona.

Proposta/Objetivo

Primeiro Objetivo:

Modificar o design físico do sistema RO de modo que este pareça com um CO;

Testar o sistema no Star Schema Benchmark;

Avaliar se um sistema orientado a linha pode ter o desempenho de um sistema orientado a coluna.

Star Schema Benchmark

Benchmark feito para Data Warehouse, baseado no TPC-H.

É formado de uma tabela de fatos, e tabelas de dimensão ligadas a ela.

13 queries, separadas em 4 blocos chamados de “flights”.

queries compostas de 2-4 junções e 1-2 agregações.

Star Schema Benchmark

**ScaleFactor usado nos testes 10

Modificações no Row-Oriented

Para simular um sistema orientado a coluna em um orientado a linha foram analisadas 3 abordagens:

Particionamento Vertical

Índice apenas nos planos

Visões Materializadas


Particionamento Vertical

Divide as relações em tabelas de dupla entrada (key, attribute)

Inserções e Junções feitas por Hash

Existe overhead por tupla, devido ao acréscimo de chaves


Índice apenas nos planos

Atribui índices a cada coluna de cada tabela

Os índices são estruturados em uma árvore B

É eficaz em consultas com intervalo definido


Visões Materializadas

Foram criadas visões “ótimas” das querys a serem usadas nos testes.

O sistema acessa apenas as colunas necessárias para realizar a query.

Ótimo, porém necessita de conhecimento prévio das querys.

Resultados: Row-Oriented

Legenda:T: Tradicional Row-OrientedT(B): Traditional with Bitmap enabledMV: Materialized ViewsVP: Vertical PartitionatingAI: All-Index

Houve perda no desempenho:

-Overhead nas tuplas-Junções na construção das tupla

Resultados: Row-Oriented

• C-Store tem melhor desempenho do que a versão ótima do sistema orientado a linha.

• Segunda Questão: Quais as funcionalidades específicas do CO que são responsáveis pelo alto desempenho?

Proposta/Objetivo

1) Simular um sistema Column-Oriented usando um sistema Row-Oriented.

2) Analisar as funcionalidades exclusivas de um Column-Oriented explorando o aumento na performance que cada funcionalidade proporciona.

Proposta/Objetivo

Segundo Objetivo:

Retirar as funcionalidades específicas do CO, uma a uma;

Testar o sistema no Star Schema Benchmark;

Avaliar o impacto de cada funcionalidade na performance do sistema orientado a coluna.

Modificações no Column-Oriented

Para verificar o desempenho do CO, foram retiradas, uma a uma, as seguintes funcionalidades:

Compressão

Processamento por Bloco

Materialização Tardia

Junção Invisível


Compressão

Dados do mesmo tipo contíguos em disco

Run-Lenght Enconding

Permite acesso sem descompressar


Processamento por Bloco

Blocos de dados são enviados uma única vez para o operador

Reduz Overhead de processamento

Se a largura da coluna for fixa, os dados no bloco podem ser acessados como um array -> permite processamento paralelo


Materialização Tardia

Realiza, preferencialmente, todas as operações antes de construir a tupla

Não necessita descompressar os dados tão cedo

Permite os benefícios de operar por bloco


Materialização Tardia - exemplo

Where Where

ANDQuery:

Select custID, SUM(price)From tableWhere (prodID = 4) AND

(storeID =1)Group By custID

Construção da Tupla


Junção Invisível

Junção feita especialmente para CO executando um Star Schema;

Rescreve junções na tabela de fatos em predicados, e os processa em paralelo;

Cria uma tabela hash para cada tabela de dimensão, processa os índices com a tabela de fatos, e cria entradas de 0 e 1 para cada tupla, indicando quais satisfazem os predicados;

Faz um bit AND entre as tabelas, e só então une os atributos das tabelas de dimensão com a de fatos.


Junção Invisível – Exemplo (Passo 1)


Junção Invisível – Exemplo (Passo 2)

Resultados: Column-Oriented

Legenda:t: Processamento por BlocoT: Processamento por Tuplai: Sem Junção InvisívelI: Com Junção Invisívelc: Sem CompressãoC: Com Compressãol: Materialização CedoL: Materialização Tardia

Constatações:-Materialização Tardia-Compressão-Junção Invisível vs. Denormalização

Conclusões

• Existem diferenças entre um sistema CO e um RO a

nível de execução de querys, além das óbvias

diferenças a nível de armazenamento.

• As variações no RO para atingir o desempenho de um

CO não obtiveram bons resultados, principalmente

pelo overhead na construção das tuplas.

• Os testes nas funcionalidades do CO mostraram que os

principais responsáveis pelo alto desempenho são a

Materialização Tardia e a Compressão.

Daniel J. Abadi – Yale - New Haven, USA Samuel R. Madden – MIT – Cambrigde, USA Nabil Hachem...

Documents

Transcript of Daniel J. Abadi – Yale - New Haven, USA Samuel R. Madden – MIT – Cambrigde, USA Nabil Hachem...