Universidade Federal de São Carlos - UFSCar Departamento de Computação - DC Programa de Pós-Graduação em Ciência da Computação - PPGCC

Transcrição

1 Universidade Federal de São Carlos - UFSCar Departamento de Computação - DC Programa de Pós-Graduação em Ciência da Computação - PPGCC Revisão da R*-tree Aluno:Marcos Henrique de Paula Prof: Dr. Ricardo Ciferri Área: Banco de Dados 1

2 Sumário Introdução Deficiências de R-trees Algoritimos: EscolheFolha e de Particionamento Experimentos do artigo Conclusão 2

3 INTRODUÇÃO O objetivo principal da R-tree é atribuir retângulos às folhas de forma que a proximidade espacial seja preservada. Um objeto complexo espacial é representado por um retângulos envolvente mínimo (MBR) indispensável, preservando as propriedades geométricas 3

4 INTRODUÇÃO Altura da árvore balanceada semelhante a uma B-tree, com registros de índice em seus nós folha contendo ponteiros para objetos de dados. Heurística de Otimização: minimizar a área de cada retângulo delimitador nos nós internos. 4

5 INTRODUÇÃO A inserção de um novo retângulo na R-tree começa em sua raiz. A Rotina ChooseSubtree (EscolheFolha) é chamada para determinar um nó filho iterativamente até que uma folha é encontrada. O retângulo é inserido na folha e as modificações da MBR na folha são propagadas para cima ao longo do caminho de inserção. 5

6 INTRODUÇÃO Se a folha já contém M objetos, a rotina Split é chamada distribuindo os objetos em dois grupos: um continua na folha original, enquanto o outro é armazenado em uma nova folha. Posteriormente, a entrada do índice original é atualizada e, uma nova entrada, referindo-se à nova folha, é inserida no nó pai, o que pode ter que ser dividido de forma análoga. 6

7 INTRODUÇÃO R*-tree tem servido de orientação para muitas implementações de R-tree, influenciando projetos de métodos de acesso. Propostas emergentes para o R-tree diferem, principalmente, no algoritmo de particionamento (Split) e no algoritmo de travessia para a inserção de novos objetos (comumente chamado ChooseSubtree). 7

8 Diferenças entre a R-tree e R*-tree Minimização da área, margem e sobreposição é crucial para o desempenho de R-tree / R *- tree. As tentativas da R*- tree para reduzir a árvore, usando uma combinação de um algoritmo de particionamento revisado e o conceito de reinserção forçada para node overflow. Esta baseada na observação de que as estruturas R-tree são altamente suscetíveis a ordem em que as suas entradas são inseridas, portanto, com uma inserção construída (e não por carregamento) a estrutura é suscetível de ser sub-óptima. Exclusão e reinserção de entradas lhes permite "encontrar" um lugar na árvore que pode ser mais apropriado do que a sua localização original -> Melhora o desempenho de recuperação 8

9 Exemplo R1 R2 R1 R2 R5 R4 R5 R4 R3 Preferred by R-tree R3 R1 R2 R5 R4 Preferred by R*-tree R3 9

10 Diferenças entre a R-tree e R*-tree Em diferentes estudos experimentais a R*- tree tem se mostrado como uma estrutura mais eficiente em relação ao desempenho da consulta. A aplicação dos algoritmos da R*-tree apresenta algumas deficiências. 10

11 Deficiências Re-inserção de entradas: considerada uma das contribuições essenciais para melhorar desempenho de consultas, é um conceito complicado em DBMS. 11

12 Deficiências A sobreposição otimizada durante ChooseSubtree: importante para a melhorar o desempenho da consulta, é realizada apenas rudimentarmente. É restrita ao menor nível de diretório e limitada a um parâmetro constante para manter a CPU em um custo aceitável. 12

13 Deficiências A função de pontuação no particionamento não leva em conta o equilíbrio das páginas particionadas. O desequilíbrio no particionamento é limitado por um parâmetro m e o grau de desequilíbrio de inserções não influencia a divisão de uma página. 13

14 Deficiências R-trees não são bem projetados para dados de alta dimensão. Como MBRs com volume zero não são incomuns em dados de alta dimensão, as estratégias comumente usadas baseados no particionamento de volume estão se tornando ineficazes. 14

15 ChooseSubtree - CSOrig 15

16 ChooseSubtree - CSOrig CSOrig melhora o desempenho da pesquisa em relação a outras estratégias, mas a sobreposição otimizada só é realizada no menor nível de diretório devido ao alto custo de CPU desta estratégia. 16

17 ChooseSubtree - CSOrig O parâmetro r originalmente introduzido para reduzir o custo de CPU para O (MlogM + Mr), r M. Se r é for muito pequeno, a probabilidade de falta de entrada com menor sobreposição e expansão é alta. Se for muito grande o custo da CPU se torna um fator crucial. 17

18 ChooseSubtree - CSOrig Outro grave problema do algoritmo é a estratégia de otimização baseada no volume que pode se tornar ineficaz para dados de alta dimensão. Caixas delimitadoras com volume zero não são incomuns e podem estar em subespaços de menor dimensão. 18

19 CSRevised O CSRevised aborda os problemas mencionados. Primeiro, uma simples estratégia de adaptação é proposta para a computação de um conjunto de entradas candidatas que são verificados quanto à sobreposição e alargamento melhorando performance e custo. 19

20 CSRevised Com as reduções de custos, a sobreposição otimizada pode ser executada em todos os níveis de diretórios. 20

21 CSRevised Em segundo lugar, o algoritmo identifica situações em que critérios baseados no volume tornam-se ineficazes, e em seguida, muda para uma estratégia baseada em perímetro. 21

22 CSRevised 22

23 CSRevised 23

24 CSRevised 24

25 CSRevised O custo de CPU do novo algoritmo é O(MlogM + qp), onde q indica o tamanho da CAND. O primeiro termo representa o custo para a classificação, enquanto o segundo representa o custo de CheckComp, desde de que q p M, resultando, num pior caso de desempenho, em O(M2). 25

26 CSRevised No experimento observou-se que em média p e q são muito menores que M. O custo de CPU do CSOrig no pior caso é O(MlogM + Mr), r M (proposta: r = 32), mas a sobreposição otimizada só é realizada no menor nível de diretório, ou seja, uma vez para cada inserção. 26

27 CSRevised CSRevised tem otimização mais eficaz, com uma redução substancial no custo de CPU para o método de inserção. A idéia de re-inserção foi abandonada, uma vez que impede a aplicação em um DBMS. 27

28 CSRevised Entradas irrelevantes, que não são capazes de acolher o novo objeto, são descartadas. Isso reduz consideravelmente o tempo de CPU, de modo que uma sobreposição efetiva e otimizada pode ser aplicada agora em todos os níveis de diretórios. 28

29 Particionamento A estratégia da divisão de um nó em dois baseia-se na classificação dos retângulos com relação à sua projeção para cada dimensão. 29

30 Particionamento Dois tipos de ordens são considerados para cada dimensão. Uma refere-se ao limite mínimo dos retângulos e outra a seu limite máximo. 30

31 Particionamento A divisão de um nó corresponde à computação da divisão ideal do candidato SCu, onde u é o índice de partição no eixo a dividir. O algoritmo R*- tree original prossegue duas etapas: 31

32 Particionamento 32

33 Particionamento O algoritmo de particionamento revisado se diferencia do original na segunda etapa. Distingue a divisão interna entre nós e folhas, relativa a escolha do eixo de divisão. 33

34 Particionamento Para dividir uma folha, o eixo de divisão é ainda determinado conforme descrito na etapa 1, mas em caso de nós internos o primeiro passo é deixado de fora e todas as dimensões são consideradas no cálculo da segunda etapa. 34

35 Particionamento O novo algoritmo de particionamento não está limitado a critérios de optimização bem conhecidos (sobreposição, volume, perímetro), mas também utiliza função de ponderação wf (weighting function) que leva em conta o equilíbrio da divisão. 35

36 Particionamento Ao manter o registro da modificação de um nó MBB, somos capazes de antecipar onde os dados são susceptíveis de serem inseridos no futuro. Isso leva a um novo algoritmo de divisão altamente adaptável. 36

37 Particionamento ChooseSubtree e Split, identificam quando a estratégia de otimização baseada no volume não é mais eficaz e se modificam em tais situações, utilizando estratégias baseadas perímetro. 37

38 Experimentos no artigo Metodologia Experimentos com cargas de trabalho em diversos conjuntos de dados simulados e reais Avaliação das decisões de projeto Performance de inserção Performance de consulta 38

39 Resultados: Inserção Para a inserção na memória principal (100% de buffer), o Hilbert R-tree é duas vezes mais rápido que o RR *- tree. 39

40 Resultados: Consulta 40

41 Resultados: Consulta Média de performance da query. Acessos à folha em percentual. 41

42 Conclusão Deficiências foram abordadas nos projetos de R-trees, e em particular da árvore R*-tree. Nenhum dos membros da família R-tree tem em conta o desequilíbrio de uma divisão como um critério de otimização, nem o fato de que otimização baseada no volume se tornar ineficaz quando caixas delimitadoras estão em subespaços de menor dimensão. 42

43 Conclusão Foi proposta uma revisão da R*-trees denominado RR*-tree. A complexa técnica de otimização da R*-tree, a re-inserção, foi abandonada. As consultas foram consideradas com um número limitado de respostas ao invés de com um volume limitado. 43

44 Conclusão O tratamento de dados multidimensionais foi melhorado, tal como foram propostas estratégias adaptativas, se a otimização baseada no volume falhar muda-se para a baseada em perímetro. 44

45 Conclusão RR*-tree foi mais robusta que R-tree e superior para a maioria dos arquivos de dados e consultas. Acredita-se que RR*-tree é ideal para ser aplicado dentro de um SGBD, uma vez que proporciona excelente desempenho e não colide com as exigências da concorrência comuns de protocolos. 45

46 Referências Beckmann, Norbert and Seeger, Bernhard : A revised r*-tree in comparison with related index structures. SIGMOD Conference 2009: