ISSN: 1981-8882 _______________________________________________________________
Arquitetura para Seleção de Índice no SGBD PostgreSQL,
utilizando abordagem baseada em custos do Otimizador
Wendel Góes Pedrozo1, Maria Salete Marcom Gomes Vaz1,2 1Departamento de Informática – Universidade Federal do Paraná (UFPR)
Caixa Postal 15.064 – 91.501-970 – Curitiba – PR – Brazil
2Departamento de Informática – Universidade Estadual de Ponta Grossa (UEPG) Caixa Postal 15.064 – 91.501-970 – Ponta Grossa – PR – Brazil
wendel@inf.ufpr.br, salete@uepg.br
Abstract. This paper presents a architheture for solution of the problem of selection of
indices in relational data base. The system offer a tool that analyzes commands SQL submitted to the SGBD and recommends the indices to increase the performance of this command. The efficiency of the approach based on costs of Otimizer for solution of the problem as well as the extensions necessary is shown to be carried through in the SGBD PostgreSQL for implementation of the work.
Resumo. Este artigo apresenta uma arquitetura para solução do problema de seleção
de índices em banco de dados relacionais. O sistema propõe uma ferramenta que analisa comandos SQL submetidos ao SGBD e recomenda os índices para aumentar o desempenho deste comando. É mostrada a eficiência da abordagem baseada em custos do Otimizador para solução do problema bem como as extensões necessárias a serem realizadas no SGBD PostgreSQL para implementação do trabalho.
1. Introdução
Uma atividade comumente realizada por administradores de sistemas de bancos de dados para acelerar o desempenho de consultas submetidas a um SGBD relacional é a seleção de índices sobre as tabelas presentes na base de dados. Essa atividade é complexa e envolve diversos fatores como, por exemplo: obtenção da carga de trabalho e a escolha de quais tabelas e colunas devem ser indexadas.
Neste artigo será apresentada a proposta de arquitetura para prover a seleção e criação de índices em um sistema de bancos de dados. Serão discutidas todas as etapas para prover a seleção e criação dos índices, bem como questões de implementação no SGBD objeto relacional PostgreSQL.
O restante deste artigo está organizado conforme descrito a seguir. A Seção 2 faz um estudo sobre Índices em banco de dados. Na seção 3 é mostrada uma visão geral do problema de seleção de índices e discutida a metodologia empregada em algumas ferramentas já existentes para resolver este problema. Na Seção 4 é apresentada a infra-estrutura necessária para implementação da proposta no SGBD PostgreSQL. As características da Arquitetura, bem como tecnologias utilizadas são abordadas na seção 5. Na Seção 6 é feito um estudo comparativo dos trabalhos correlatos, discutindo suas vantagens e desvantagens em relação à arquitetura proposta. Por fim, na Seção 7 são apresentadas as conclusões e perspectivas de trabalhos futuros.
2. Índices em Banco de dados
Um índice é uma organização de dados que permite acelerar o processamento de consultas. Uma chave de um índice é uma seqüência de atributos e são feitos mapeamentos entre os valores desta seqüência e seus registros correspondentes. A estrutura mais comumente utilizada para representar índices são as arvores B+1, como ilustrado na figura 1.
Figura 1. Exemplo de arvore B+ 3. Descrição do Problema
Como o problema da seleção de índices sobre as tabelas presentes na base de dados envolve muitas questões, vamos iniciar com um exemplo. Consideremos uma carga de trabalho que envolva os seguintes comandos SQL sobre uma tabela denominada Venda:
(1) insert into Venda (idproduto, data, qtd, valor) values (4, current_timestamp, 20, 348); (2) select idproduto, data, sum(valor) as total
From Venda
where valor > 1500000 and
data between ‘20070501’ and ‘20070531’ group by idproduto, data;
Suponha, inicialmente, que os comandos são submetidos ao SGBD de forma concorrente e que temos uma freqüência de comandos do tipo (2) muito maior do que a de comandos do tipo (1). Neste tipo de cenário, um índice sobre as colunas de valor e data da tabela Venda pode trazer benefícios de desempenho no processamento das transações em que estes comandos estão inseridos.
Como os comandos do tipo (1) são menos freqüentes, espera-se um pequeno custo decorrente da atualização do índice sobre a tabela de vendas, compensando a criação do mesmo. De outra forma, se tivermos a freqüência de comandos do tipo (1) muito superior do que a freqüência de comandos do tipo (2), a criação de índices não é recomendável, devido ao custo de atualização dos índices presentes sobre a tabela.
3.1 Metodologias empregadas na Seleção de Índices
Uma das tarefas que DBA’s precisam realizar é a escolha de índices que possam melhorar o desempenho das consultas submetidas ao SGBD. Os trabalhos existentes que tratam da seleção de índices, procuram construir ferramentas de apoio ao DBA na escolha dos índices para uma determinada carga de trabalho W = {(Qi, fi), i = 1, ..., n}. Onde Qi representa um comando SQL2
e fi sua freqüência de submissão. Estas ferramentas implementam algoritmos que objetivam minimizar o custo total de processamento de W pelo sistema respeitando um limite de espaço S disponível para a criação de índices. O custo total de processamento é a soma dos custos de acesso e atualização dos dados e dos custos de manutenção dos índices. Já foi demonstrado que uma versão restrita do problema de seleção de índices é NP-complexo [Comer 1978].
1- Uma árvore B+ é uma árvore balanceada cujas folhas contêm uma seqüência de pares chaves-ponteiro. As chaves
são ordenadas pelo seu valor.
2- Structured Query Language, ou Linguagem de Consulta Estruturada, é uma Linguagem de pesquisa declarativa
Nos trabalhos realizados sobre este assunto, pode-se perceber que existe uma metodologia comum para a escolha de índices que se adequam a uma carga de trabalho, como mostra a figura 2.
Figura 2. Metodologia para seleção de Índices
O primeiro passo para a seleção de índices é obter a carga de trabalho W sobre a qual a ferramenta irá operar. Normalmente, as ferramentas possuem duas formas de aquisição dos comandos SQL e suas freqüências de execução: a entrada manual e a utilização de arquivos de
trace. Na entrada manual, o DBA insere na ferramenta uma lista de comandos SQL e suas
freqüências estimadas. Já na coleta de trace, o DBA usa um utilitário do sistema que permite o registro, em um arquivo de estatísticas sobre todos os comandos SQL submetidos pelos usuários. Esse arquivo é processado pela ferramenta para detectar quantas vezes os comandos SQL foram executados durante o período de coleta. Em alguns sistemas também é possível obter os comandos recentemente executados no sistema através da varredura do cachê reservado para operações SQL [Oracle], [Lohman et Al 2000].
Em seguida, para cada comando da carga de trabalho, é aplicada uma heurística de escolha de índices candidatos, que irá determinar os melhores índices para cada comando SQL da carga de trabalho. Na literatura existem diversas abordagens para a construção de heurística de escolha de candidatos. Podemos citar as estratégias baseadas em regras [Rozen and Shasha 1991], [Choenni et al 1993] e as estratégias baseadas em custos do Otimizador [Finkelstein et Al 1988], [Chaudhuri and Narasayya 1997] e [Lohman et Al 2000].
No primeiro tipo de abordagem, a escolha de quais índices é interessante para um comando SQL é baseada no uso de regras derivadas a partir do conhecimento de especialistas. Um exemplo de regra seria sempre criar um índice para consultar uma tabela com mais de 50 blocos e filtrada por um predicado que obtém menos de 5% das tuplas.
Já na segunda abordagem, o próprio Otimizador de consultas do sistema é utilizado para classificar quais índices poderão trazer maior benefício para o comando. Esta abordagem apresenta como principal vantagem a característica de evitar que a ferramenta crie um modelo de custos separado do que é utilizado pelo Otimizador. Isto permite garantir que os índices criados serão realmente considerados pelo sistema. Conforme veremos na próxima sessão, nosso trabalho está mais relacionado às técnicas baseadas em custos do Otimizador.
Por fim, após a escolha dos índices candidatos, é aplicada uma heurística final de seleção de índices que procura determinar quais índices oferecem a melhor relação custo-benefício para
a carga de trabalho como um todo. Este tipo de heurística pode levar em conta o compromisso existente entre os custos de manutenção dos índices e as melhorias trazidas por estes em consultas.
Após a aplicação da heurística final de seleção de índices, as ferramentas recomendam criações ou remoções de índices para o DBA, que irá decidir se, e quando, estas recomendações deverão ser efetivadas.
4 Infra-estrutura do SGBD PostgreSQL
Um dos recursos muito utilizado por DBAs, para analisar o comportamento do Otimizador de consultas do SGBD é o comando explain. A utilização deste comando retorna informações importantes sobre o plano de execução para um determinado comando SQL, bem como suas métricas de tempo e custo.
Para ilustrar o comportamento desse recurso, vejamos a seguir. Supondo, inicialmente
que estamos escrevendo uma consulta sobre uma base de dados simples de vendas. Utilizando o comando explain é possível ver o plano que o SGBD escolhe para a consulta:
simple=# explain
simple-# select idproduto, data, sum(valor) as total simple-# from venda
simple-# where valor > 1500000 and
simple-# data between ’20070101’ and ’20070131’ simple-# group by idproduto, data;
QUERY PLAN
---HashAggregate (cost=25388.79..25388.83 rows=12 width=21)
-> Seq Scan on venda (cost=0.00..25367.00 rows=2906 width=21) Filter: ((valor > 1500000::numeric) AND
(data >= ’2007-05-01’::date) AND (data <= ’2007-05-31’::date)) (3 rows)
No plano, podemos perceber que o SGBD fará uma varredura seqüencial sobre a tabela de vendas e aplicará os predicados sobre as colunas de valor e de data. A quantidade de linhas esperada como resultado é de 2906 e o custo de processamento da varredura será de 25367.00. Após a varredura, um operador de agregação será aplicado para processar a cláusula group by do comando. O custo total esperado é de 25388.83.
Como a arquitetura proposta utiliza a abordagem baseada em custos do Otimizador, será necessário estender alguns comandos, como é o caso do explain, para ser possível tratar simulações de configurações hipotéticas, como será visto a seguir.
4.1 Simulação de Índices Hipotéticos
A possibilidade de simulação de configurações hipotéticas de índice no schema do banco de dados, é um pré-requisito para a arquitetura proposta. O sistema deve possuir mecanismos necessários para estimar através do próprio Otimizador do sistema o quanto um índice pode trazer benefícios para uma determinada consulta. Também será necessário estender a interface do SGBD, de modo que seja possível simular a presença de índice na base de dados, sem que seja necessário materializar fisicamente este índice. Para isto, será preciso implementar um mecanismo para registro dos índices hipotéticos no catálogo do SGBD.
Outra alteração que se faz necessária é estender o Otimizador de consultas para reconhecer as configurações hipotéticas registradas, possibilitando ao Otimizador a produção de planos de execução e seus custos levando em conta a existência das estruturas hipotéticas. Esta
última capacidade é importante porque aproveita o próprio Otimizador para avaliar os custos, evitando assim a construção de um modelo de custo especializado na ferramenta de seleção de índices.
4.2 Criação de Índices On-line
Um outro mecanismo importante para a tarefa de seleção e criação de índices é o de permitir que esta operação seja feita on-line, ou seja, enquanto atualizações e consultas são concorrentemente processadas sobre a tabela base. Este tipo de técnica é de grande utilidade para aplicações que precisam ficar permanentemente disponível, como por exemplo aplicações de
e-commerce. Este tipo de técnica se revela bastante importante também para situações onde a
atualização dos dados se concentra em períodos de baixo uso do SGBD. Neste cenário, pode ser interessante remover os índices da tabela, antes das atualizações e voltar a criá-los depois.
Alguns sistemas comerciais já possuem facilidades para criar índices sem impedir a realização de transações concorrentes. É o caso dos SGBDs Oracle [Oracle] e IBM DB2 [IBM], por exemplo. O SGBD PostgreSQL na versão mais recente, já possui a facilidade de criação de índices on-line também.
5. Arquitetura Proposta
A proposta de arquitetura e ferramenta, está direcionada para implementação no SGBD objeto relacional PostgreSQL, devido a ser um SGBD Open Source (código aberto), o que facilita a realização de alterações no seu código fonte. Outro ponto é a carência de ferramentas de auxilio ao DBA para esta plataforma, e o fato do PostgreSQL estar se consolidando como um dos grandes SGBD corporativos para aplicações OLTP3. A figura 3 traz a descrição dos módulos da ferramenta de recomendação de índices.
Figura 3. Módulos da ferramenta de recomendação de índices
Interface de linha de comando: módulo de interface com o usuário que permite a entrada de
comandos de linha, utilizada para recomendação de índices.
3- Online Transaction Processing ou Processamento de transações em tempo-real. São sistemas que se encarregam
de registrar todas as transações contidas em uma determinada operação organizacional. Por exemplo: um sistema de transações bancárias que registra todas as operações efetuadas em um banco.
Interface Gráfica: módulo de interface gráfica com o usuário, que disponibiliza vários recursos
que facilitam a entrada e a saída de dados na ferramenta de recomendação de índices.
Tabelas Auxiliares: essas tabelas tem o propósito de guardar diversas informações úteis para a
ferramenta de recomendação de índices, e são utilizadas como veículo de comunicação entre a ferramenta de recomendação e o Otimizador do PostgreSQL.
Para utilizar a ferramenta de recomendação, os usuários poderão optar pela interface gráfica ou pela interface de linha de comando. Tanto no modo gráfico como por linha de comando, é necessário informar uma carga de trabalho (W).
Na interface gráfica, para entrada da carga de trabalho (W) é possível usar o recurso chamado “HISTÓRICO SQL”, que procura automaticamente recentes declarações SQL e suas freqüências de execuções, essas informações são previamente gravadas na tabela RECENT_SQL no módulo de Tabelas Auxiliares.
Após escolher a carga de trabalho de entrada, a ferramenta gera índices candidatos utilizando a Heurística adaptada de [Lohman et Al 2000], depois disso é chamado o Otimizador do PostgreSQL para executar o processo de otimização para a carga de trabalho (W), considerando os índices hipotéticos. Por fim, os índices hipotéticos constantes no plano de execução gerado pelo Otimizador são apresentados ao usuário como solução, bem como métricas de desempenho com sua utilização.
Outro recurso disponível na interface gráfica da ferramenta é a possibilidade de entrada manual de declarações SQL ou através dos recursos de copiar e colar.
5.1 Heurística de seleção de índices
Para que o processo seja eficiente, o importante é limitar de forma inteligente a enumeração de índices hipotéticos realizados antes da otimização. Segue a descrição da heurística utilizada neste trabalho, a qual leva em conta os principais usos de acessos indexados aos dados e suas combinações para criar índices hipotéticos com múltiplas colunas:
Ao receber uma carga de trabalho (W) a ferramenta utiliza uma heurística para escolha de índices candidatos adaptada de Lohman et al (2000).
Na literatura existem várias heurísticas para seleção de índices, entre elas destacam-se os trabalho de Finkelstein et Al (1988), Frank et Al (1992), Chaudhuri and Narasayya (1998) e Lohman et al (2000) utilizada neste trabalho, por sua simplicidade e eficiência. Ela foi implementada no SGBD IBM DB2 UDB [IBM] e permite que a seleção de índices para recomendação seja realizada para um dado comando SQL com a execução de apenas uma chamada ao Otimizador do SGBD.
Diferente de outras abordagens, as quais utilizam o Otimizador apenas para avaliar possíveis conjuntos de índices, esta propõe uma integração muito mais próxima entre o Otimizador de consulta e a ferramenta de seleção de índices. É sugerido que o próprio Otimizador do SGBD tenha a capacidade de enumerar os melhores índices para uma dada consulta SQL. Para isto, todos os índices hipotéticos relevantes são enumerados antes do processo de otimização e fica totalmente a cargo do Otimizador selecionar quais índices serão efetivamente selecionados.
Para a enumeração dos índices candidatos, a heurística analisa predicados e cláusulas presentes no comando SQL submetido para encontrar colunas que poderiam ser indexadas. Os usos interessantes de colunas são classificados e combinados para formar índices hipotéticos. Todos os índices hipotéticos enumerados são criados no sistema, e então, uma chamada é feita ao Otimizador.
Por fim, os índices hipotéticos escolhidos pelo Otimizador no plano de execução gerado durante o processo de otimização são indicados como os índices recomendados para o comando.
5.1.1 Método de Classificação e algoritmo
A heurística procura encontrar no comando SQL cinco tipos de usos interessantes de colunas:
• EQ: colunas envolvidas em predicados de igualdade,
• O: colunas envolvidas em cláusulas ORDER BY, GROUP BY e predicados de junção;
• RANGE: colunas que aparecem em restrições de intervalos,
• SARG: colunas que aparecem em outros predicados indexáveis (por exemplo, like). Este uso de colunas remete ao conceito de predicados de busca (sargable predicates) discutido em Selinger (1979),
• REF: demais colunas referenciadas no comando SQL.
A heurística combina os grupos de colunas das seguintes formas para formar índices hipotéticos com múltiplas colunas, em ordem, eliminando colunas duplicadas:
1. EQ + O 2. EQ + O + RANGE 3. EQ + O + RANGE + SARG 4. EQ + O + RANGE + REF 5. O + EQ 6. O + EQ + RANGE 7. O + EQ + RANGE + SARG 8. O + EQ + RANGE + REF
Outro grupo de uso interessante de colunas proposto por Salles (2004) é denominado BAD. Este grupo é formado por colunas afetadas por comandos de atualização como insert e delete. Este grupo é interessante para determinarmos posteriormente, quais índices são prejudicados pelo comando.
Estas combinações procuram refletir usos típicos de índices para acelerar consultas [Lohman et Al 2000]. Segue abaixo o algoritmo em pseudocódigo utilizado em nosso trabalho. Recomenda Índices (carga de trabalho W)
1. Geração de Índices utilizando Heurística adaptada de Lohman et Al (2000); 2. Inserção dos índices candidatos no Schema;
3. Chamada ao Otimizador;
4. Verifica plano ótimo gerado, identifica índices hipotéticos presentes no plano;
5. Apresentação ao usuário dos índices recomendados, suas métricas de desempenho e comando para materialização dos índices.
O Algoritmo acima, mostra a simplicidade e eficiência da abordagem baseada em custos do Otimizador. A essência deste algoritmo é que a recomendação de novos índices e o cálculo de seu desempenho, ambos ocorrem em apenas uma chamada ao Otimizador do PostgreSQL. Esta abordagem tem muitas vantagens, uma delas é que o próprio Otimizador faz a enumeração dos melhores índices para uma dada consulta, isto garante que índices recomendados serão realmente considerados pelos SGBDs, quando materializados fisicamente. Outra vantagem é que não é necessário manter uma ferramenta externa ou secundária, para recomendar índices ou para avaliar seus custos. Outra importante vantagem, é que o Otimizador do PostgreSQL, não necessita significantemente ser modificado. É necessário apenas permitir que o Otimizador reconheça índices hipotéticos inseridos no Schema durante o processo de otimização. Com isso, o Otimizador continua trabalhando normalmente, fazendo os planos de execução, ordenando junções, métodos de acesso, etc.
Muitos artigos tem sido escritos sobre este assunto. A Ferramenta proposta neste artigo, é um dos poucos trabalhos que para recomendar índices para uma declaração SQL, simplesmente faz uma chamada ao SGBD, e utiliza o próprio Otimizador do SGBD para prover a recomendação de índices.
Os primeiros projetos de recomendação de índices foram iniciados em meados dos anos 80 [Maggie et al 1983], [Barucci et al 1990], [Frank et al 1992], [Capara et al 1995], [Gupta et al 1997] e [Choenni et al 1993]. Estes artigos iniciais tem várias deficiências. Primeiro, eles são restritos a determinados SGBDs. Outra deficiência é que nenhum destes trabalhos utilizam o Otimizador para estimar os seus custos. Um exemplo disso pode ser visto em Choenni et al (1993), onde são desenvolvidos modelos de custos detalhados para a ferramenta de seleção de índices. Estes modelos não estão em sincronia com o modelo utilizado pelo Otimizador de consultas do sistema. Isto não é desejável, uma vez que o Otimizador não pode realizar as mesmas suposições sobre custos que a ferramenta e esta discrepância pode causar, até mesmo, a escolha de métodos de acesso distintos dos previstos pela ferramenta para o processamento das consultas.
O trabalho de Filkestein et. al (1998), propõe que ao realizar a seleção de índices para um determinado banco de dados, sejam criadas réplicas, no catálogo do SGBD, das tabelas envolvidas. Estas réplicas não possuem extensão física, mas recebem todas às informações estatísticas das tabelas originais. A ferramenta então cria índices sobre as réplicas e faz estimativas de custos. Filkestein et. al (1998) propõem, ainda, que o SGBD possua um comando para obtenção do custo e do plano de execução que o Otimizador gera para uma determinada consulta. Este comando chamado de explain, é um recurso atualmente disponível em muitos SGBD comerciais. Para obter uma estimativa de custos de execução de uma consulta sob uma configuração hipotética, a ferramenta de seleção de índices troca as referências às tabelas na consulta pelas suas respectivas réplicas e utiliza o comando explain para estimar métricas de desempenho sobre os índices recomendados.
Uma desvantagem desta abordagem é o fato de que a ferramenta de seleção de índices precisa ter privilégios de acesso suficientes às informações críticas presentes no catálogo sobre estatísticas de otimização e as altere diretamente. Em nosso trabalho é adicionado o conceito de índices hipotéticos ao sistema, que permite que uma ferramenta de seleção de índices faça simulações de configurações no SGBD de forma mais elegante do que através da criação de réplicas de tabelas no catálogo.
O trabalho de Frank et al. (1992) propõe que o Otimizador de consultas do SGBD seja estendido para permitir a obtenção de um plano de execução sob a suposição de que um dado conjunto de índices hipotéticos existe na base. Porém, o trabalho de Frank et al (1992) não explora quais alterações seriam necessárias no SGBD para dar suporte à noção de índices hipotéticos.
Outras soluções, como encontradas em [Chaudhuri and Narasayya 1998] e [Zilio 1998], utilizam o Otimizador do SGBD para avaliar os custos dos índices recomendados, mas nunca para recomendar índices. O processo de recomendação sempre ocorre em um módulo externo ao SGBD.
O trabalho de Chaudhuri and Narasayya (1998) que foi implementado no SGBD Microsoft SQL Server oferece uma importante contribuição. Foram combinadas as vantagens dos algoritmos de recomendação de única coluna com os algoritmos de otimização de múltiplas-colunas. Considerando índices candidatos com um pequeno número de colunas, há mais possibilidade para otimizar várias queries usando os mesmos índices candidatos e ainda compactá-los dentro de pequenas restrições de disco.
Levando isso em conta, seu projeto começa considerando índices de simples colunas primeiro, e trabalha sobre os índices de múltiplas colunas se o tempo permitir. Essa estratégia procura diminuir o número de chamadas ao Otimizador.
Entretanto, as mesmas vantagens de reduzir o número de chamada ao Otimizador pode ser obtida se for inserido o algoritmo de seleção de índices sobre o Otimizador, como é implementado em nosso trabalho, o qual acreditamos ser a melhor técnica para solução deste problema. A diferença de performance entre ambas é muito grande, considerando por exemplo uma simples consulta SQL, nosso algoritmo recomenda índices, fazendo apenas um chamado ao Otimizador. Outras vantagens de nossa abordagem comparada ao trabalho em Chaudhuri and Narasayya (1998) é a recomendação em larga escala de índices, intrínseco na Heurística de seleção de índices adaptada de Lohman et al. (2000). A heurística de seleção de índices, considera os 3 mais prováveis usos de índices e procura combinar a ocorrência de cada tipo.
Em Lohman et al. (2000), tem-se a proposta de uma ferramenta para seleção de índices para o IBM DB2. Este trabalho utiliza o próprio Otimizador do SGBD para enumerar os melhores índices para uma carga de trabalho (W) e disponibiliza também recursos de restrições de disco. Dentre todos os trabalhos relacionados acima, nossa pesquisa está mais relacionada ao trabalho de Lohman et al. (2000).Este trabalho foi o primeiro que utilizou o próprio Otimizador para recomendar e avaliar os índices.
7. Conclusões e trabalhos futuros
A atividade realizada por DBAs, em escolher quais índices devem ser criados em uma base de dados para acelerar o desempenho, como foi visto é uma atividade complexa e que envolve diversos fatores. Já existem ferramentas de auxilio ao DBA nesta tarefa em SGBDs comerciais, mas iniciativas para SGBDs Open Source ainda são escassas.
O objetivo deste trabalho foi apresentar uma arquitetura que provê a seleção e criação de índices para o SGBD PostgreSQL. Foram abordados também características das extensões necessárias a serem realizadas no SGBD para a implementação da proposta. Foram apresentadas as características da abordagem baseada em custos do Otimizador, bem como um estudo comparativo com outras abordagens presentes na literatura sobre este assunto, demonstrando as vantagens da arquitetura proposta.
A implementação da arquitetura proposta neste trabalho é promissora, devido à comprovada eficiência e simplicidade da abordagem baseada em custos do Otimizador para o problema de seleção de índices, já demonstrada no trabalho de Lohman et al. (2000) e implementado no SGBD IBM DB2. Outro ponto é a facilidade de implementação em qualquer SGBD, devido à reduzida necessidade de alterações no mesmo.
Como trabalhos futuros, uma das direções para este projeto, seria estender o algoritmo para recomendação de visões materializadas e índices sobre essas visões. Atualmente no PostgreSQL a decisão de se criar uma visão materializada parte do administrador do sistema, neste caso pode ser utilizado o Otimizador do SGBD para avaliar as várias alternativas, considerando inclusive estimativas de custo e restrições de armazenamento. Outro ponto que este trabalho poderia ser estendido é a investigação de diferentes heurísticas de decisão para o problema.
8. Referências
Barucci, Elena, Pinzani, Renzo and Sprugnoli, Renzo (January 1990) ”Optimal Selection of Secondary Indexes”, IEEE Trans. on Software Engineering, 16(1) p.32-38.
Capara, A., Fischetti, M., and Maio, D. (1995). “ Exact and Approximate Algoritms for the Index Selection Problem in Physical Database Design”. IEEE Transactions on Knowledge and Data Engeineering, 7 (6), p. 955-967.
Chaudhuri, S. and Narasayya, V. (1997) “ An Effcient, Cost-driven Index Selection Tool for
Microsoft SQLServer ”. Proceedings of the International Conference on very large Databases (VLDB), p. 146-155.
Chaudhuri, S. and Narasayya, V.(1998) “ Microsoft Index Tuning Wizard for Sql Server 7.0”. Proceedings of the ACM Sigmod International Conference Management of data, p.553-554. Choenni, S., Blanken, H. and Chang, T. (1993). “On the Selection of Secondary Indices in
Relational Databases”. IEEE Data and Knowledge Engineering, 11(3), p. 207-233.
Comer, D.(1978) “The Difficulty of Optimum Index Selection”. ACM Transactions on Data-base Systems (TODS). 3 (4): 440-445.
Comer, D. (1979) “The ubiquitous b-tree”. ACM Computing Surveys (CSUR), 11(2), p.121-137, 1979.
Finkelstein, S., Schkolnick, M. and Tiberio, P. (1988) “ Physical Data-Base Design for relational databases”. ACM Transactions on Data-base Systems (TODS), p. 91-128.
Frank, Martin R., Omiecinski, Edward R. and Navathe, Shamkant B.(March 1992) ”Adaptive and Automated Index Selection in RDBMS”, International Conference on Extendig Database Technology (EDBT), Vienna, Austria, p. 277-292.
Gupta, H. , Rajaraman, A., and Ullman, J. D. (1997). “Index Selection for Olap”. In Proceedings of the IEEE International Conference on Data Engineering (ICDE), p. 208-2019.
IBM, DB2 Universal Database (2007). http://www.ibm.com/db2, April.
Lohman, G. and Valentin, G. and Zilio, D.and Zuliani, M.and Skelley, A. (2000) “DB2 advisor: An optimizer smart enough to recommend its own indexes”. In: Proceedings of the IEEE International Conference on Data Engineering (ICDE). p.101-110.
Maggie, Y. L. Ip, Saxton, L.V., and Vijay, V.Raghavan. (March, 1983) ” On the Selection of an Optimal Set of Indexes”, IEEE Transactions on Software Engineering, 9(2) p.135-143.
M. Salles. (2004) “Criação Autônoma de Índices em Banco de dados”. Dissertação de Mestrado, Depto de Informática, Pontifícia Universidade Católica do Rio de Janeiro.
Oracle Corporation (2007). http://www.oracle.com, April.
Rozen, S. Shasha, D. (1991) “A framework for automating physical database design. In: Proceedings of the International Conference on Very Large Databases (VLDB) p. 401-411. Selinger, P. G., Astrahan, M. M., Chamberlin, D. D., Lorie,R. A. and Price, T. G..(1979)
“Access Path Selection in a Relational Database Management System”. Proceedings of the ACM Sigmod International Conference on Management of Data, p. 23-34.
Zilio, Daniel C. (1998) ”Physical Database Design Decision Algorithms and Concurrent Reorganization for Parallel Database Systems”, PhD Thesis, University of Toronto.
