1estudo de viabilidade de uma plataforma de baixo custo para data warehouse estudo de viabilidade de...

1Estudo de Viabilidade de uma Plataforma de Baixo Custo para Data Warehouse

ESTUDO DE VIABILIDADE DE UMA PLATAFORMA DE ESTUDO DE VIABILIDADE DE UMA PLATAFORMA DE BAIXO CUSTO PARA DATA WAREHOUSEBAIXO CUSTO PARA DATA WAREHOUSE

Eduardo Cunha de AlmeidaEduardo Cunha de AlmeidaOrientador: Prof. Dr. Marcos SunyeOrientador: Prof. Dr. Marcos Sunye

Agosto / 2004Agosto / 2004


AgendaAgenda

✔Motivação

✔Objetivo

✔Data Warehouse

✔PostgreSQL

✔Metodologias de Benchmark

✔Resultados

✔Conclusão


MotivaçãoMotivação

✔Data Warehouse

✔Demanda crescente pela implementação de Data Warehouses

✔SW “Open Source” e HW de baixo custo

✔Três maiores desafios em Data Warehouse (KIM, W., 2003)

• Limpeza de dados• Seleção de Fontes • Desempenho


ObjetivoObjetivo

✔ Viabilidade de uma Plataforma de Baixo Custo para um Data Warehouse

• SGBD PostgreSQL• SO LINUX• HW – Equipamentos de baixo custo

✔ Futuras implementações no PostgreSQL visando Data Warehouse

✔ Fomentar:• Desenvolvimento de softwares “open source” para os outros componentes do ambiente Data Warehouse (OLAP e ETL)


Data WarehouseData Warehouse

ConceitoDW é um grande repositório de dados coletados de diversas fontes que destina-se a gerar informações para o nível gerencial sendo fonte para tomadas de decisão.

Características

• Orientado a consultas

• Exige grande capacidade de armazenamento

• Não volátil

• Permite redundância

• Poucos usuários

• Consultas complexas

• Não possui metodologia padrão, apenas recomendações de metodologias.


Data Warehouse – Poder de Data Warehouse – Poder de processamentoprocessamento

Consultas

• Varredura completa de tabela

• Agregações

• Múltiplas junções

Índices• Índices de Bitmap utilizados por SGBDs como Oracle e

DB2, também chamados de índices de HG pelo Sybase IQ

Carregamento

• Armazenado histórico de dados, ou seja, grande quantidade de dados

• Grandes segmento de rollback

• Carregamento periódico

Ex.1: GVT carrega diariamente 8 milhões de registros. Atualmente o DW possui 2,5 TB de dados.

Ex.2: BCP carrega diariamente 30 milhões de registros


PostgreSQLPostgreSQL

O PostgreSQL é um SGBD de código aberto que deriva seu desenvolvimento do SGBD Ingres.

Características

• SGBD de código aberto mais avançado

• Integridade referencial

• Suporte as especificações da SQL92 e SQL99

• Controle de concorrência, evitando bloqueios de leitura quando existe uma escrita no banco de dados

Próxima versão

• Tablespace

• Índice multi-coluna

• Melhorias no otimizador (rewriter)


PostgreSQL – Execução de ConsultasPostgreSQL – Execução de Consultas

1 - A consulta é submetida ao parser que verifica as definições dos objetos

no dicionário de dados;

2 - É realizado a reescrita das consultas;

3 - O planner constrói um plano de execução orientado pela consulta reescrita e pelas estatísticas coletadas pelo DBA;

4 - É executado o plano criado pelo planner.


Metodologias de Benchmark para DWMetodologias de Benchmark para DW

Visão Geral

Metodologia para simular a execução de uma carga de trabalho do mundo real.

Metodologias Utilizadas• TPC-H – Mantida pelo Transaction Processing Performance Council (TPC)• OSDL DBT3 – Mantida pelo Open Source Development Lab (OSDL)

O TPC é uma corporação sem fim lucrativo fundado para definir processamento de transações e benchmarks de banco de dados. O propósito do benchmark TPC é prover dados de desempenho relevantes e objetivos para a indústria. O OSDL é uma organização sem fim lucrativo que fornece o “estado da arte” em computação e ambientes de teste para acelerar o crescimento e adoção do SO Linux nas empresas.


Metodologia TPC-HMetodologia TPC-H

Visão Geral TPC-H é compreendido de consultas de negócio projetadas para exercitar as funcionalidades de um sistema buscando representar aplicações complexas de análises de negócios. São 22 consultas de natureza ad-hoc, com vários tipos de acesso, alto grau de complexidade e que examinam uma grande porcentagem dos dados disponíveis. Estas consultas são executadas de forma seqüencial e formam uma seqüência de consultas. São executadas também 2 consultas de atualização. Para a execução dos testes o driver foi desenvolvido em Java/Shell script. As escalas para o benchmark estão divididas em: 1 GB, 10 GB, 30 GB, 100 GB, 300 GB, 1.000 GB, 3.000 GB e 10.000 GB.

Operações realizadas• Varredura seqüencial de grandes volumes de dados;• Agregações de grandes volumes de dados; • Junções de múltiplas tabelas;• Ordenações.


Metodologia TPC-HMetodologia TPC-H

Regras de execuçãoCada seqüência de consultas deve corresponder a uma sessão;

Power TestExecução de uma seqüência de consulta entre a execução das duas consultas de atualização.

Throughput TestExecução em paralelo de várias seqüência de consulta entre a execução das duas consultas de atualização.A quantidade de seqüências é definida de acordo com a escala utilizada.

O sistema deverá ser o mesmo para os dois testes.

Medidas• TPC-H Power;• TPC-H Query-por-hora ou Consulta-por-hora;• TPC-H Price/Performance ou Preço / Desempenho.


Metodologia OSDL DBT3Metodologia OSDL DBT3

O OSDL DBT3 é uma adaptação do TPC-H para testar o sistema operacional Linux e sua pilha de softwares de código aberto.

• Possibilidade de reescrita das consultas, pois o PostgreSQL não resolve de maneira eficaz como será demonstrado. A reescrita é proibida pelo TPC;• Pode ser utilizado qualquer fator de escala e não somente os utilizados pelo TPC-H. Apesar disto foram utilizados neste trabalho as escalas 1GB e 100GB;• No TPCH algumas consultas são restringidas no retorno de linhas e esta restrição não é aplicada pelo DBT3. Neste trabalho utilizamos a mesma opção do DBT3;• Não é realizado o teste de ACID no DBT3;• Não é utilizada a métrica de preço/desempenho.

Diferenças entre DBT3 e TPC-H


Configuração do AmbienteConfiguração do Ambiente

Benchmark• OSDL DBT3 versão 1.4 e TPC-H versão 2.0.0• Fator de escala de 1GB e 100GB • Carregamento realizado utilizando arquivos (flat file)

Software• PostgreSQL 7.4.2• Mandrake Linux 64bits (kernel 2.6.5)• Java SDK 1.4.2_04 • PostgreSQL JDBC pg74.1jdbc3.jar• Utilitários TPC-H (DBGEN and QGEN)

Hardware• Dual Opteron 64bits Model 240 1.4GHz• 4 GB RAM• 960 GB Disk em RAID 0


ResultadosResultados

Carregamento

Distribuição Kernel Scala(GB) Script Data load PK and index Total load timeDebian 32bits 2.4.24 100 Monolitico 11:37:59 12:22:04 24:00:04Mandrake 64bits 2.6.5 100 Monolitico 07:24:23 13:42:31 21:06:54Mandrake 64bits 2.6.5 100 Distribuído 06:14:30 09:58:31 16:13:01Mandrake 64bits 2.6.5 1 Distribuído 00:03:40 00:03:39 00:07:19

Tempo(Hr)

TPC-H (100 GB)• Sybase / Solaris (2 CPU) : 6,27 H• MS SQL Server / Win 2003 (2 CPU): 4.79 H• DB2 / Linux (16 CPU): 0,63 H

DBT3 (1 GB)• PostgreSQL / RedHat (8 CPU) : 00:42:47 H• PostgreSQL / RedHat (4 CPU) : 00:39:54 H


Resultados – TPC-HResultados – TPC-H

1 – Execução com clausula de timeout (25000 s)PostgreSQL nunca foi submetido a uma carga de trabalho TPC-H de 100 GB

2 – Verificação dos resultadosVerificação das consultas que interromperam por timeout

3 – Execução sem clausula de timeoutVerificar o tempo total da execução do benchmark

4 – Interrupção do teste após 72 H

5 – Verificação dos resultadosVerificação das consultas que foram interrompidas

6 – Estudo das consultas (texto e plano de execução) Identificação dos problemas de demora na execução das consultas

Procedimentos realizados


Resultados – TPC-HResultados – TPC-H

TPCH 100 GB - PostgreSQL 7.4.2

13.821621

6.84325.000

12.5681.383

15.73425.00025.00025.001

3892.381

3.3711.374

4.2733.171

6.7802.429

25.00025.001

5.57725.001

64561

-

2.5

00

5.0

00

7.5

00

10.

000

12.

500

15.

000

17.

500

20.

000

22.

500

25.

000

123456789

10111213141516171819202122

RF1RF2

Co

ns

ult

as

Tempo (segundos)


Resultados – TPC-H e DBT3Resultados – TPC-H e DBT3

Plano de execução

PostgreSQL gerou planos de execução ruins sendo necessário a reescrita das consultas.Motivo para a execução de outro benchmark que permita a reescrita.

Algumas consultas rodaram próximas ou mais rápido que os SGBDs Sybase e MS SQL Server. Estas consultas são as de numero 11 e 18. As consultas que consumiram o maior tempo mostraram algumas deficiências do PostgreSQL em comparação com outros SGBDs. Estas consultas são as de numero 4, 8, 9, 10, 19, 20 e 22. As operações realizadas foram:

• Sub-consultas dentro de outra sub-consulta;• Operadores EXISTS e NOT EXISTS• Agregações quando utilizado visões in-line, que são sub-consultas dentro da clausula FROM

Texto das consultas



Comparação entre consultas

Select sum(l_extendedprice* (1 - l_discount)) as revenue

from

lineitem,

part

where

(

p_partkey = l_partkey

and p_brand = ‘[BRAND1]'

and p_container in ('SM CASE', 'SM BOX', 'SM PACK', 'SM PKG')

and l_quantity >= [QUANTITY1] and l_quantity <= [QUANTITY1] + 10

and p_size between 1 and 5

and l_shipmode in ('AIR', 'AIR REG')

and l_shipinstruct = 'DELIVER IN PERSON'

)or

(


and p_brand = '[BRAND2]'

and p_container in ('MED BAG', 'MED BOX', 'MED PKG', 'MED PACK')

and l_quantity >= [QUANTITY2] and l_quantity <= [QUANTITY2] + 10




)or

...

Select sum(l_extendedprice* (1 - l_discount)) as revenue

from

lineitem,

part

where




and

( (

p_brand = '[BRAND1]'

and p_container in ('SM CASE', 'SM BOX', 'SM PACK', 'SM PKG')

and l_quantity >= [QUANTITY1] and l_quantity <= [QUANTITY1] +10


) or

(

p_brand = '[BRAND2]'

and p_container in ('MED BAG', 'MED BOX', 'MED PKG', 'MED PACK')

and l_quantity >= [QUANTITY2] and l_quantity <= [QUANTITY2] +10


)or

...

Consulta 19 - Original Consulta 19 - Reescrita



Comparação entre planos de execução

Aggregate (cost=672136305127.42..672136305127.43 rows=1 width=22)

-> Nested Loop (cost=7117.00..672136305127.15 rows=108 width=22)

Join Filter: (...........)

-> Seq Scan on lineitem (cost=0.00..218010.15 rows=6001215 width=79)

-> Materialize (cost=7117.00..9117.00 rows=200000 width=36)

-> Seq Scan on part (cost=0.00..7117.00 rows=200000 width=36)

(6 rows)

Aggregate (cost=288750.64..288750.64 rows=1 width=22)

-> Hash Join (cost=7617.00..288750.37 rows=104 width=22)

Hash Cond: ("outer".l_partkey = "inner".p_partkey)

Join Filter: ((("inner".p_brand = 'Brand#44'::bpchar) AND (("inner".p_container = 'SM CASE'::bpchar) OR ("inner".p_container = 'SM BOX'::bpchar) OR ("inner".p_container = 'SM PACK'::bpchar) OR ("inner".p_container = 'SM PKG'::bpchar)) AND ("outer".l_quantity >= 6::numeric) AND ("outer".l_quantity <= 16::numeric) AND ("inner".p_size >= 1) AND ("inner".p_size <= 5)) OR (("inner".p_brand = 'Brand#21'::bpchar) AND (("inner".p_container = 'MED BAG'::bpchar) OR ("inner".p_container = 'MED BOX'::bpchar) OR ("inner".p_container = 'MED PKG'::bpchar) OR ("inner".p_container = 'MED PACK'::bpchar)) AND ("outer".l_quantity>= 11::numeric) AND ("outer".l_quantity <= 21::numeric) AND ("inner".p_size >= 1) AND ("inner".p_size <= 10)) OR (("inner".p_brand = 'Brand#21'::bpchar) AND (("inner".p_container = 'LG CASE'::bpchar) OR ("inner".p_container = 'LG BOX'::bpchar) OR ("inner".p_container = 'LG PACK'::bpchar) OR ("inner".p_container = 'LG PKG'::bpchar)) AND ("outer".l_quantity >= 23::numeric) AND ("outer".l_quantity <= 33::numeric) AND ("inner".p_size >= 1) AND ("inner".p_size <= 15)))

-> Seq Scan on lineitem (cost=0.00..263019.26 rows=219565 width=36)

Filter: (((l_shipmode = 'AIR'::bpchar) OR (l_shipmode = 'AIR REG'::bpchar)) AND (l_shipinstruct = 'DELIVER IN PERSON'::bpchar))

-> Hash (cost=7117.00..7117.00 rows=200000 width=36)

-> Seq Scan on part (cost=0.00..7117.00 rows=200000 width=36)

(8 rows)

Plano de execução original

Plano de execução após reescrita


Resultados – DBT3Resultados – DBT3

OSDL DBT3 1 GB - PostgreSQL 7.4.2 -

50

100

150

200

250

300

350

400

Q01Q02Q03Q04Q05Q06Q07Q08Q09Q10Q11Q12Q13Q14Q15Q16Q17Q18Q19Q20Q21Q22RF1RF2

Co

ns

ult

as

Tempo (segundos)

Pow er

Throughput

Consulta Power ThroughputQ1 135,292 138,627 Q2 1,748 1,995 Q3 39,181 102,552 Q4 19,531 11,838 Q5 28,017 44,982 Q6 20,448 16,562 Q7 33,927 36,587 Q8 6,215 13,040 Q9 377,367 72,558 Q10 33,418 46,324 Q11 7,094 10,326 Q12 23,916 29,520 Q13 25,430 35,261 Q14 16,145 15,716 Q15 34,547 31,695 Q16 16,760 19,610 Q17 1,406 2,218 Q18 22,827 31,860 Q19 21,923 21,008 Q20 68,576 3,821 Q21 12,329 27,868 Q22 4,789 4,962 RF1 5,468 51,683 RF2 0,013 0,027


Resultados – DBT3Resultados – DBT3

Índices gerados

• Power@size = 332,35• Throughput@size = 224,85• Composite = 273,37

Resultado dos benchmarks

BenchmarkEscala (GB)

Situação Timeout por

consulta (seg)

Tempo final (seg)

Situação Tempo final

TPC-H 100 Executado (*) 25.000 256.424 Interrompido > 72HrTPC-H 1 - - - Interrompido > 24HrDBT3 1 - - - Executado 2.482 seg(*) somente power test

Timeout Sem Timeout


ConclusãoConclusão

✔ Atual versão do PostgreSQL (7.4.x) não executou satisfatoriamente o TPC-H sendo necessário executar o DBT3;✔ O PostgreSQL não possui um problema estrutural que impeça a execução das consultas, apenas não as executa de um forma adequada;✔ Implementação de estruturas que aumentem o desempenho de um bancos de dados de DW:

• Páginas PAX• Índices de bitmap• Paralelismo intra-query

✔ Diante do exposto concluímos que, atualmente, somente é viável utilizar o PostgreSQL num projeto de data warehouse de maneira restrita: • Escassez de recursos financeiros para adquirir SGBDs mais maduros • Monitorar constantemente as consultas submetidas ao banco de dados • Aceitar o baixo desempenho nas consultas apontadas neste trabalho

1estudo de viabilidade de uma plataforma de baixo custo para data warehouse estudo de viabilidade de...

Documents