Administração de Banco de Dados

Transcrição

1 Administração de Banco de Dados Adriano J. Holanda 28/8/2015 Índices Para os testes com os índices criaremos uma tabela chamada tteste com o comando teste=> CREATE TABLE tteste (id int4); CREATE TABLE A tabela será preenchida com uma sequência de números de 1 a para o campo id usando o comando teste=> INSERT INTO tteste SELECT * FROM generateseries(1, ); INSERT Para obter informações sobre a consulta usamos o comando EXPLAIN antes da consulta SQL teste=> EXPLAIN SELECT * FROM tteste; Seq Scan on tteste (cost= rows= width=4) (1 row) As informações indicam que foi feita uma varredura sequencial (Seq Scan) e os números entre parênteses são: O custo estimado de inicialização é 0.00, ou seja, o tempo gasto para a fase de saída começar. O custo estimado total é , que é o tempo gasto para todas as tuplas estarem disponíveis para acesso. O número de tuplas retornadas na consulta é Média estimada do tamanho das tuplas de saída é 4 bytes. Para obter mais informações da consulta de EXPLAIN ANALYZE teste=> EXPLAIN ANALYZE SELECT * FROM tteste; Seq Scan on tteste (cost= rows= width=4) \ (actual time= rows= loops=1) Total runtime: ms Adicionando a restrição id= teremos teste=> EXPLAIN ANALYZE SELECT * FROM tteste WHERE id=987987; Seq Scan on tteste (cost= rows=1 width=4) \ (actual time= rows=1 loops=1) Filter: (id = ) Rows Removed by Filter: Total runtime: ms (4 rows) 1

2 O tempo de execução da consulta foi aproximadamente 1,6s, mesmo que parte do tempo tenha sido gasto com a geração da explicação, é um tempo considerávelmente alto. Vamos criar um índice no campo id da tabela tteste: teste=> CREATE INDEX itesteid ON tteste(id); CREATE INDEX E executar novamente a consulta de seleção do id=987987: teste=> EXPLAIN ANALYZE SELECT * FROM tteste WHERE id=987987; Index Only Scan using itesteid on tteste (cost= rows=1 width=4) \ (actual time= rows=1 loops=1) Index Cond: (id = ) Heap Fetches: 1 Total runtime: ms (4 rows) Ao invés da varredura sequencial (Seq Scan), a tabela de índices é usada como indicado pela informação Index Only Scan, o que reduziu o tempo de saída para 21,993 ms. O PostgreSQL usa uma variação da árvore B chamada árvore de Lehman-Yao para armazenamento dos índices. Esta estrutura permite acesso concorrente aos valores armazenados na árvore. Métodos de varredura O PostgreSQL possui três métodos de varredura (scan): 1. Sequencial: as tuplas são acessadas sequencialmente e aquelas que satisfizerem à condição de busca serão recuperadas; 2. Indexada somente (index): pega um ponteiro para a tupla por vez do índice, e imediatamente visita aquela tupla na tabela; 3. Indexada com mapa de bits (bitmap index): todas os ponteiros para as tuplas do índice são capturados em uma passada, ordenados na memória principal usando uma estrutura de dados chamada mapa de bits (bitmap), e então visita as tuplas na tabela, seguindo a ordem do endereço físico da tupla. Esta varredura usa a localidade espacial das tuplas para melhorar a performance de acesso, ao custo de manter e gerenciar o mapa de bits na memória. A tupla não é recuperada na ordem de armazenamento no índice, o que só fará diferença para a consulta, se esta for feita com ORDER BY. De modo geral, a varredura somente com índice ganha para um pequeno número de tuplas, a varredura com mapa de bits e índice ganha para um número maior de tuplas e a varredura sequencial ganha quando o número de tuplas se aproxima do tamanho da tabela. Para exemplificar a diferença entre os três métodos vamos usar a tabela pgclass SELECT relname FROM pgclass ORDER BY 1 LIMIT 8; relname pgforeigndatawrappers pgforeignservers pgforeigntablecolumns pgforeigntables pgusermappings administrableroleauthorizations applicableroles attributes (8 rows) 2

3 Se selecionarmos somente a primeira letra de cada entrada de relname temos: SELECT substring(relname, 1, 1) FROM pgclass ORDER BY 1 LIMIT 8; substring a a a (8 rows) Criaremos uma tabela temporária com as primeiras letras de relname no primeiro campo e a letra x repetida 250 vezes no segundo campo da seguinte maneira: CREATE TEMPORARY TABLE temp(letra, lixo) AS SELECT substring(relname, 1, 1), repeat('x', 250) FROM pgclass ORDER BY random(); SELECT 294 E vamos criar uma tabela de índices para o campo letra da tabela temp teste=> CREATE INDEX itempletra ON temp(letra); CREATE INDEX Vamos criar uma função para gera a distribuição de letras teste=> CREATE OR REPLACE FUNCTION buscarletra(text) RETURNS SETOF text AS $$ BEGIN RETURN QUERY EXECUTE ' EXPLAIN SELECT letra WHERE letra = ''' $1 ''''; END $$ LANGUAGE plpgsql; CREATE FUNCTION E verificar a distribuição para a tabela temp teste=> WITH letras (letra, count) AS ( SELECT letra, COUNT(*) GROUP BY 1 ) SELECT letra, count, (count * / (SUM(count) OVER ()))::numeric(4,1) AS "%" FROM letras ORDER BY 2 DESC; letra count % p c s r f t

4 u d v a e i k (14 rows) Vejamos a estatística da letras p, d e k WHERE letra = 'p'; Index Only Scan using itemp on temp (cost= rows=1 width=32) Index Cond: (letra = 'p'::text) WHERE letra = 'd'; Index Only Scan using itemp on temp (cost= rows=1 width=32) Index Cond: (letra = 'd'::text) WHERE letra = 'k'; Index Only Scan using itemp on temp (cost= rows=1 width=32) Index Cond: (letra = 'k'::text) Com o uso de ANALYZE na tabela temp, a varredura sequencial é usada para valores repetidos teste=> ANALYZE temp; ANALYZE Analisando de novo as consultas da da seleção em temp para as letras p, d e k WHERE letra = 'p'; Seq Scan on temp (cost= rows=227 width=2) Filter: (letra = 'p'::text) Apesar da criação do índice, a consulta não é feita utilizando-o 4

5 WHERE letra = 'd'; Bitmap Heap Scan on temp (cost= rows=4 width=2) Recheck Cond: (letra = 'd'::text) -> Bitmap Index Scan on itempletra (cost= rows=4 width=0) Index Cond: (letra = 'd'::text) (4 rows) WHERE letra = 'k'; Bitmap Heap Scan on temp (cost= rows=2 width=2) Recheck Cond: (letra = 'k'::text) -> Bitmap Index Scan on itempletra (cost= rows=2 width=0) Index Cond: (letra = 'k'::text) (4 rows) Vamos verificar qual índice de varredura é usado para cada letra armazenada no campo letra da tabela temp teste=> WITH letra (letra, count) AS ( SELECT letra, COUNT(*) GROUP BY 1 ) SELECT letra AS l, count, buscarletra(letra) FROM letra ORDER BY 2 DESC; l count buscarletra p 227 Seq Scan on temp (cost= rows=227 width=2) p 227 Filter: (letra = 'p'::text) c 12 Seq Scan on temp (cost= rows=12 width=2) c 12 Filter: (letra = 'c'::text) s 9 Filter: (letra = 's'::text) s 9 Seq Scan on temp (cost= rows=9 width=2) r 8 Filter: (letra = 'r'::text)... Vamos agrupar os índices com o comando teste=> WITH letra (letra, count) AS ( SELECT letra, COUNT(*) GROUP BY 1 ) SELECT letra AS l, count, (SELECT * FROM buscarletra(letra) AS l2 LIMIT 1) AS buscarletra FROM letra ORDER BY 2 DESC; l count buscarletra

6 p 227 Seq Scan on temp (cost= rows=227 width=2) c 12 Seq Scan on temp (cost= rows=12 width=2) s 9 Seq Scan on temp (cost= rows=9 width=2) r 8 Seq Scan on temp (cost= rows=8 width=2) f 6 Bitmap Heap Scan on temp (cost= rows=6 width=2) t 6 Bitmap Heap Scan on temp (cost= rows=6 width=2) 5 Bitmap Heap Scan on temp (cost= rows=5 width=2) u 5 Bitmap Heap Scan on temp (cost= rows=5 width=2) v 4 Bitmap Heap Scan on temp (cost= rows=4 width=2) d 4 Bitmap Heap Scan on temp (cost= rows=4 width=2) a 3 Bitmap Heap Scan on temp (cost= rows=3 width=2) e 2 Bitmap Heap Scan on temp (cost= rows=2 width=2) i 2 Bitmap Heap Scan on temp (cost= rows=2 width=2) k 1 Bitmap Heap Scan on temp (cost= rows=2 width=2) (14 rows) Vamos desabilitar as varreduras sequencial e por mapa de bits para que a consulta seja feita usando índices teste=> SET enableseqscan = false; SET teste=> SET enablebitmapscan = false; SET E executamos de novo o agrupamento das letras por método de varredura teste=> WITH letra (letra, count) AS ( SELECT letra, COUNT(*) GROUP BY 1 ) SELECT letra AS l, count, (SELECT * FROM buscarletra(letra) AS l2 LIMIT 1) AS buscarletra FROM letra ORDER BY 2 DESC; l count buscarletra p 227 Index Only Scan using itempletra on temp (cost= rows=227 width=2) c 12 Index Only Scan using itempletra on temp (cost= rows=12 width=2) s 9 Index Only Scan using itempletra on temp (cost= rows=9 width=2) r 8 Index Only Scan using itempletra on temp (cost= rows=8 width=2) f 6 Index Only Scan using itempletra on temp (cost= rows=6 width=2) t 6 Index Only Scan using itempletra on temp (cost= rows=6 width=2) 5 Index Only Scan using itempletra on temp (cost= rows=5 width=2) u 5 Index Only Scan using itempletra on temp (cost= rows=5 width=2) v 4 Index Only Scan using itempletra on temp (cost= rows=4 width=2) d 4 Index Only Scan using itempletra on temp (cost= rows=4 width=2) a 3 Index Only Scan using itempletra on temp (cost= rows=3 width=2) i 2 Index Only Scan using itempletra on temp (cost= rows=2 width=2) e 2 Index Only Scan using itempletra on temp (cost= rows=2 width=2) k 1 Index Only Scan using itempletra on temp (cost= rows=2 width=2) (14 rows) Notamos que o custo da busca usando a tabela de índices para a letra p é 42,93, maior que o custa da busca sequencial que foi 14,68. O mesmo acontece para o custo de busca da letra f que usou a varredura por mapa de bits e foi 14,16, enquanto que usando o índice foi de 17,66. Vamos verificar o espaço em disco ocupado pela tabela tteste e pelo índice itesteid 6

7 teste=> SELECT pgsizepretty(pgrelationsize('tteste')), pgsizepretty(pgrelationsize('itesteid')); pgsizepretty pgsizepretty MB 214 MB (1 row) Notamos que a tabela de índices ocupa um espaço considerável. Vamos apagar a tabela tteste teste=> DROP TABLE tteste; DROP TABLE E adicionar um campo w teste=> CREATE TABLE tteste (id int4, w text); CREATE TABLE E inserir a palavra alice para cada entrada da série gerada de 1 a teste=> INSERT INTO tteste SELECT w, 'alice' FROM generateseries(1, ) as w; INSERT E vamos criar índices para p campo w da tabela tteste, isto exigirá um pouco de paciência teste=> CREATE INDEX itestew ON tteste(w); CREATE INDEX Verificamos o espaço em disco ocupado teste=> SELECT pgsizepretty(pgrelationsize('tteste')), pgsizepretty(pgrelationsize('itestew')); pgsizepretty pgsizepretty MB 214 MB (1 row) E fazemos a busca utilizando o índice do campo w teste=> EXPLAIN SELECT * FROM tteste WHERE w = 'alice'; Index Scan using itestew on tteste (cost= rows= width=10) Index Cond: (w = 'alice'::text) Habilitamos a varredura sequencial teste=> SET enableseqscan = true; SET e repetimos a consulta teste=> EXPLAIN SELECT * FROM tteste WHERE w = 'alice'; Seq Scan on tteste (cost= rows= width=10) Filter: (w = 'alice'::text) 7

8 O custo da varredura sequencial foi menor ( ) do que a indexada ( ,43). O índice neste caso é inútil, pois há muitas repetições para o campo w. A busca forçando o uso do índice faz com que o PostgreSQL leia todas as entradas do índice e depois todas as entradas na tabela. Com a varredura sequencial habilitada, o otimizador de plano de consultas verifica o custo do uso ou não do índice e opta pela estratégia de menor custo, que no caso é a não utilização de índices, que provoca a leitura sequencial da tabela, reduzindo as requisições de entrada/saída. O uso de índice é justificado quando há pouca ou nenhuma repetição do elemento indexado, por exemplo, se procurarmos um valor que não está na tabela, o custo utilizando índice será bem menor, conforme mostrado a seguir: teste=> EXPLAIN SELECT * FROM tteste WHERE w = 'foo'; Index Scan using itestew on tteste (cost= rows=1 width=10) Index Cond: (w = 'foo'::text) Desabilitamos os índices teste=> SET enableindexscan = true; SET e repetimos a consulta teste=> EXPLAIN SELECT * FROM tteste WHERE w = 'foo'; Seq Scan on tteste (cost= rows=1 width=10) Filter: (w = 'foo'::text) Não houve alteração do custo para a varredura sequencial, porém, para a varredura com índice o custo foi bem menor (4,45). Isto ocorreu pelo fato de a palavra não existir na árvore de índices, o que reduz o custo da busca na árvore B. Além disso, como o valor não é encontrado no índice, nem é procurado na tabela. É interessante que o administrador de banco de dados verifique a utilização dos índices, pois se um índice estiver sendo pouco utilizado poderá ser removido, liberando espaço em disco e evitando que haja sobrecarga no banco de dados devido à manutenção da estrutura dos índices. No PostgreSQL podemos ver a estatística de utilização do índice usando o comando: teste=> select * from pgcatalog.pgstatuserindexes; Referências. A apresentação Explaining the Postgres Query Optimizer de Bruce Momjian disponível em é uma fonte adicional de informações sobre índices. O livro Troubleshooting PostgreSQL de Hans-Jürgen Schönig também é uma boa referência, por mostrar exemplos de uso dos índices. Os exemplos deste manuscrito foram extraídos destas referências. 8