Post on 22-Apr-2015
transcript
Query processing in main memory
Vitor Silva
Bibliografia “Query Processing in Main Memory Database
Management Systems” - Tobin J. Lehman & Michael J. Carey, 1986
“Implementation Techniques for Main Memory Database Systems” - David J. deWitt, Randy H. Katz, Frank Olken, Leonard D. Shapiro, Michael R. Stonebraker, David Wood, 1984
“Database Management Systems”, 2nd Edition - Mcgraw Hill
“Join Processing in Database with Large Main Memories” - Leonard D. Shapiro, 1986
“A Study of Index Structures for Main Memory Database Management Systems” - Tobin J. Lehman, Michael J. Carey
http://en.wikipedia.org/wiki/Relational_algebra
O que nos espera (nesta apresentação)
Analisar estruturas de dados que permitem colocar a informação em memória para ser processada
Procurar explorar alguns algoritmos para quatro operadores de querys Selecção Join Projecção Agregação
Estruturas de Dados
AVL Tree (Árvores Binárias) B+ Tree Array Chained Bucket Hashing Linear Hashing Modified Linear Hashing T Tree
Estruturas de Dados
Estruturas de Dados
Sistema de Testes
PDP VAX 1 l/750 – 2 MB de memória Linguagem C 30.000 elementos unívocos Índices compostos apenas por
ponteiros Teste de 60% pesquisas, 20%
Inserções, 20% Remoções
Velocidade T Tree melhor que AVL Tree e B
Tree no conjunto pesquisa, actualização
AVL mais rápido que B Tree em pesquisa, mas em actualizações a B Tree é mais rápida
Os algoritmos de hashing têm velocidades semelhantes de pesquisa para valores baixos de nós, e enquanto não é necessário redimensionar o directório têm velocidades de actualização iguais
Linear Hashing mais lento porque para manter uma utilização de espaço estável perde muito tempo a fazer reorganização de dados
Os arrays são ineficazes devido à necessidade de reorganização de dados para manter-se ordenado (1 actualização significa mover ½ array, em média)
Espaço Arrays ocupam menos espaço AVL Tree ocupam sensivelmente o triplo do
espaço dos arrays (para cada ponteiro para dados existem mais dois ponteiros para nós filhos)
Chained Bucket Hashing e Modified Linear Hashing ocupa o espaço dos elementos + espaço da tabela de hash (sensivelmente o dobro do espaço do array)
Linear Hashing, B Trees, Extendible Hashing and T Trees neste teste ocuparam sensivelmente 1,5 do tamanho do array
Extendible Hashing obtém os piores resultados chegando a ocupar cerca de 6 vezes mais que um array devido ao facto de duplicar a tabela de hash de cada vez que um bucket fica cheio
Relação Velocidade/Espaço
Extendible Hashing e Modified Linear Hashing têm boa performance para quantidade de nós baixa, mas à custa de uma grande quantidade de espaço
Chained Bucket Hashing tem boa performance na pesquisa e na actualização, mas à custa de algum espaço
Linear Hashing é simplesmente demasiado lento
AVL Tree em tempos de execução de pesquisa e actualização razoáveis mas grandes custos de espaço
Arrays têm um tempo de pesquisa razoável e um custo de espaço baixo, mas o tempo de actualização é muito elevado
T Trees e B Trees tem o melhor desempenho no conjunto
Ponto de Situação
Estas estruturas de dados proporcionam a pesquisa de tuplo(s) - um dos operadores básicos de querys – Selecção
“ SELECT * FROM Reserves R WHERE R.rname=`Joe‘ ”
Algoritmos de Join
Nested Loops Join Hash Join Tree Join Sort Merge Join Tree Merge Join
Nested Loops Join
Para cada tuplo r Є R Para cada tuplo s Є S
Se ri==sj adiciona (r,s) ao resultado
O(N²)
Sort Merge Join A ideia base passa por ordenar as duas relações a juntar e
depois procurar fundir as duas relações. Ao ordenar os tuplos é mais fácil identificar grupos com o
mesmo valor de atributo de join. Ao identificarmos as partições comparamos as partições da
primeira relação com as partições iguais na segunda relação
O algoritmo começa por pesquisar duas relações R e S, à procura de tuplos cujo valor do atributo de join seja igual.
De seguida é feito uma pesquisa com o primeiro tuplo de cada relação.
Vai-se avançando na relação R enquanto o tuplo de R for menor que o tuplo de S
Analogamente, avança-se na relação S enquanto o valor do atributo de join for menor que o valor de R
Vai-se alternando a pesquisa até encontrar os valores pretendidos
Tree Merge Join
O conceito é similar ao Sort Merge Join, mas com recurso a T Trees de índices
Hash Join Similar as sort merge mas baseado em
tabelas de hash Se a função de hash for perfeitamente
uniforme os buckets de R terão correspondência nos buckets de S
Tree Join
Conceptalmente similar ao Hash Join, mas com recurso a T Trees
Bateria de Testes1. Variar Cardinalidade – variar a dimensão das relações |R1|=|R2|2. Variar Cardinalidade da relação interior – variar a dimensão de
R2 (|R2| = 1-100% de |R1l, com |R1l = 30,000 elementos)3. Variar Cardinalidade da relação exterior – variar a dimensão de
R1 (|R1l = 1-100% de |R2|, com |R2| = 30,000 elementos)4. Variar percentagem de duplicados (enviesada) – variar a
percentagem de duplicados das duas relações de 0-100% com |R1l=|R2|=20,000 elementos, de distribuição de duplicados enviesada
5. Variar percentagem de duplicados (uniforme) – variar a percentagem de duplicados das duas relações de 0-100% com |R1|=|R2|=20,000 elementos, de distrbuição de duplicados uniforme
6. Variar selectividade de semijoin – variar a selectividade de semijoin entre 1-100% com |R1|=|R2|=30,000 elementos e uma percentagem de duplicados de 50% de distribuição uniforme
Foram feitos apenas join de igualdade
Resultado do Nested Loop Join
Mesmo com menos elementos nas relações (de 1-20,000) os resultados demonstram que o Nested Loop Join nunca deverá ser considerado como eficaz
Resultados
Resultados
Resultados
Resultados algoritmos de Join Se já existirem as àrvores de índices o Tree Merge
demonstra ser o algoritmo mais vantajoso Se não existir pelo menos um dos índices ou os
dois índices o algoritmo de Hash Join demonstra ser o mais eficaz
Excepções: (que confirmam a regra) Se apenas existirem índices numa relação e na outra
não, mas esta segunda fôr menos de metade da maior então o T Tree Join é mais rápido que o Hash Join porque o tempo de pesquisa nos tuplos da relação menor é inferior ao tempo de construção e pesquisa da tabela de hash
Se a selectividade de semijoin e a percentagem de duplicados forem elevadas a melhor opção é o Sort Merge dado que este lida melhor com grandes volumes de pesquisa
Projecção
SELECT DISTINCT R.sid, R.bidFROM Reserves R
Critíco: Remoção de duplicados
Sort Scan Hashing
Resultados
Resultados Algoritmos de Projecção No 1º teste não foram inseridos duplicados e o
que domina o desempenho dos algoritmos é o tempo de inserção dos elementos nas estruturas de dados (no hashing o crescimento é linear, enquanto o custo do sort scan é O(|R| log |R|))
No 2º teste, ao inserir elementos duplicados, a tabela de hash passa a guardar menos elementos (descarta duplicados) o que leva a que o desempenho seja melhor que o sort scan em que só se eliminam os duplicados após todos os elementos já estarem inseridos e ordenados no array
Agregação
SELECT AVG(S.age)FROM Sailors S
O algortimo básico passa por pesquisar em toda a tabela e ir guardando informação adicional que permita calcular o valor final
Para querys com grouping novamente pode recorrer-se ao sorting e ao hashing
Pontos Finais Uma ideia sobre alguns dos algoritmos
que podem implementar três dos operadores de query
Existem mais algoritmos (pelo menos de Join) como o Hybrid Hash ou o GRACE
Existem critérios que permitem efectuar a escolha dos algortimos (quantidade de tuplos, quantidade de duplicados, entre outros)
Obrigado