Administração e Optimização de BDs

Transcrição

1 Departamento de Engenharia Informática 2010/2011 Administração e Optimização de BDs Mini-Projecto 2 Entrega a 16 de Abril de º semestre A resolução deve ser claramente identificada com o número de grupo e entregue sob a forma de um relatório impresso, seguindo o template dado na página da cadeira. A entrega electrónica deve incluir o código Java com a solução das perguntas 4 e Considere que numa BD relacional existem as seguintes três relações: EMPLOYEE(EMPID, NAME, STREET, CITY) COMPANY(COMPANYNAME, CITY) WORKS(EMPID, COMPANYNAME, SALARY) Considere que o tamanho de cada página são 8KB e que as relações têm as seguintes propriedades: A relação EMPLOYEE contém 135,000 tuplos com um record size de 90 bytes A relação COMPANY contém 30,000 tuplos com um record size de 40 bytes A relação WORKS contém 126,000 tuplos com um record size de 18 bytes a. Considerando que não existem índices, apresente, explicando sempre os cálculos necessários, a estimativa do número de operações de page I/O necessários à execução do plano de acesso referente à seguinte consulta: SELECT * FROM EMPLOYEE INNER JOIN WORKS WHERE SALARY > 5000 Na resolução desta pergunta deve indicar estimativas considerando que a operação de junção recorre a cada seguintes algoritmos de junção: i. Merge join, assumindo que as duas relações não se encontram ordenadas. ii. Hash join, assumindo que não existem colisões na função de hash. iii. Block nested-loop join, com a relação EMPLOYEE como a inner table. b. Estime o tamanho do resultado da relação denotada pela interrogação da alínea anterior e apresente uma estratégia eficiente (i.e. o plano de execução com os algoritmos) para o seu processamento. Poderá agora assumir a existência de índices sobre qualquer uma das relações envolvidas na interrogação. Tenha em atenção o tamanho das relações e indique o custo em termos de operações de I/O. Pág. 1 de 5

2 2. Considere a seguinte interrogação sobre o esquema relacional da pergunta anterior: SELECT FROM WHERE AND * EMPLOYEE INNER JOIN WORKS INNER JOIN COMPANY SALARY > 5000 COMPANYNAME > TELE Considere ainda um optimizador de interrogações semelhante ao apresentado nas aulas teóricas. Assuma que a selectividade do predicado COMPANYNAME > 'TELE' é 25%, e que a selectividade do predicado SALARY > 5000 corresponde a 0,05% da relação COMPANY. Com a informação disponível, e assumindo a existência de índices sempre que isso seja vantajoso, indique um possível plano de execução eficiente para a interrogação e indique os algoritmos escolhidos a cada passo. Justifique a sua escolha dos algoritmos com os cálculos necessários. 3. Considere as seguinte interrogações sobre o esquema relacional da primeira pergunta: a. σ EMPID> EMPID< (EMPLOYEE) b. σ (EMPID= ) (EMPID) c. COMPANYNAME(σCITY= LISBOA SALARY> 5000(COMPANY WORKS)) d. ɣmax(salary), COMPANYNAME(WORKS) Para cada uma das interrogações, indique qual o plano de execução mais eficiente, justificando a resposta com os cálculos necessários. Considere que o atributo EMPID pode tomar valores entre e Considere ainda que existe um índice clustered B+Tree sobre o atributo EMPID, e um índice non-clustered B+Tree também sobre o atributo EMPID, que inclui junto com a chave de pesquisa o atributo SALARY. Note ainda que, em algumas situações, o optimizador pode substituir as expressões por outras que lhes sejam equivalentes. 4. Tomando como base a classe MergeJoin.java que se encontra na página da cadeira, implemente o algoritmo merge join entre duas relações. Tenha em atenção que a sua implementação do algoritmo deve considerar os casos em que existem valores duplicados em ambas as relações, para o atríbuto pelo qual se estiver a efectuar a operação de join. 5. Tomando como base a classe ExtendibleHashing.java que se encontra na página da cadeira, implemente os algoritmos de pesquisa e inserção de valores numa estrutura de dados do tipo Extendible Hashing. Pág. 2 de 5

3 Abaixo encontram-se as resoluções para os problemas propostos no Mini-Projecto 2. Resolução do Problema 1 Relação EMPLOYEE : tuplos, 90 bytes por página, (135000*90)/8192=1484 páginas Relação COMPANY : tuplos, 40 bytes por página, (30000*40)/8192=147 páginas Relação WORKS : tuplos, 18 bytes por página, (126000*18)/8192=277 páginas Resolução do Problema 1.A Merge Join custo = reads(employee) + reads(works) + sort(employee) + sort(works) = * (2 * ROUNDUP(LOG(1484 /3,2),0) + 1) * (2 * ROUNDUP(LOG(277 /3,2),0) + 1) (NOTA: no pior caso, podemos considerar M=3 para o custo do algoritmo de ordenação) Hash Join custo = 3 * (reads(employee) + reads(works)) = 3 * ( ) = 5283 Block-Nested Loop Join custo = (reads(employee) * reads(works)) + reads(employee) = (1484 * 277) = Resolução do Problema 1.B Relação EMPLOYEE : 1 tuplo = 1484/ = 0,011 páginas Relação COMPANY : 1 tuplo = 147/30000= 0,005 páginas Relação WORKS: 1 tuplo = 277/126000= 0,002 páginas Estimativa para tamanho das relações resultantes das operações de JOIN EMPLOYEE JOIN WORKS 1 tuplo = 0, ,005 = 0,016 páginas (desta forma, conta-se 1 atributo repetido) Máximo de tuplos, 131 (0,016* 8K) tuplos por página, ou seja o tamanho da relação é de aprox. 962 páginas. Pág. 3 de 5

4 O algoritmo mais eficiente, segundo a alínea anterior é o algoritmo Hash Join com 5283 operações de I/O. A forma mais eficiente de executar o algoritmo de Hash Join seria utilizar a relação mais pequena (WORKS) para a fase de build e a relação maior (EMPLOYEE) para a fase de probe. No entanto, o predicado SALARY>5000 poderá inverter esta situação. Se considerarmos a estimativa por omissão para uma range query de 12%, então 12% x 1484 será 178 páginas, enquanto que a relação WORKS tem 277. Deve efectuar-se um table scan à table EMPLOYEE uma vez que vai ser necessário determinar quais as linhas para as quais SALARY > Resolução do Problema 2 De acordo com as heurísticas usadas pelo optimizador do IBM System R, introduzido nas aulas teóricas: Deve-se efectuar as selecções sobre as tabelas WORKS e COMPANY logo que possível, por forma a diminuir o tamanho das relações envolvidas nos joins. Adicionalmente existe uma restrição sobre cada uma delas conseguindo-se assim um bom factor de redução. Logo, a tabela EMPLOYEE será a última a ser testada. A alternativa mais eficiente será efectuar um clustered index scan sobre a tabela COMPANY e utilizar um hash join com probe sobre um clustered index da relação WORKS sobre a qual poderemos também avaliar o predicado SALARY > Resolução do Problema 3 a) σ EMPID> EMPID< (EMPLOYEE). Na tabela EMPLOYEE apenas temos a alternativa do índice clustered e podemos, por isso, efectuar uma range-query sobre o índice. b) σ (EMPID= ) (WORKS). Numa point-query, sem outra informação, o optimizador estima que cerca de 10% dos registos se qualificam. Logo a seletividade de (EMPID= ) é de 90%. O optimizador terá de escolher de seguida entre utilizar o índice clustered ou o índice non-clustered sobre EMPID para a tabela WORKS. Cada registo (EMPID,SALARY) é bem mais pequeno do que um registo (EMPID>COMPANYNAME, SALARY). Logo será efectuado um índex-scan utilizando o índice non-clustered. Pág. 4 de 5

5 c) COMPANYNAME(σCITY= LISBOA SALARY> 5000(COMPANY WORKS)). Será re-escrita como: COMPANYNAME( COMPANYNAME σcity= LISBOA (COMPANY) SALARY, COMPANYNAME σsalary> 5000(WORKS)). Neste caso, assumindo que a selectividade de σsalary> 5000 é 12% isso significaria das 277 páginas apenas necessitaríamos de 33. Ou seja o join será efectuado considerando a relação WORKS em primeiro lugar. d) ɣmax(salary), COMPANYNAME(WORKS). Neste caso, não é possível utilizar nenhum dos índices uma vez que os grupos estão a ser formado por COMPANYNAME. O único índice que se poderia qualificar seria o índice (EMPID, SALARY) mas como a tabela tem sempre de ser lida completamente não compensa usar o índice. Resolução do Problema 4 O código Java com a resolução da Pergunta 4 encontra-se online na página da disciplina. Resolução do Problema 5 O código Java com a resolução da Pergunta 5 encontra-se online na página da disciplina. Pág. 5 de 5