1 / 69

Rumo a Processamento de Consultas em Ambientes Altamente Distribuídos

Rumo a Processamento de Consultas em Ambientes Altamente Distribuídos. Disciplina: Banco de Dados Pós-Graduação em Informática (UFCG). Índice. I- Objetivos da Apresentação II- Por que Ambientes Altamente Distribuídos? III- Processamento de Consultas Distribuídas

malik-harper
Download Presentation

Rumo a Processamento de Consultas em Ambientes Altamente Distribuídos

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Rumo a Processamento de Consultas em Ambientes Altamente Distribuídos Disciplina: Banco de Dados Pós-Graduação em Informática (UFCG)

  2. Índice I- Objetivos da Apresentação II- Por que Ambientes Altamente Distribuídos? III- Processamento de Consultas Distribuídas IV- Processamento de Consultas com Sistemas de Banco de Dados Cliente-Servidor V- Sistemas de Bancos de Dados Heterogêneos VI- Agenda de Pesquisa

  3. I- Objetivos • Entender por que os otimizadores clássicos de consultas distribuídas não estão preparados para operar em ambientes altamente distribuídos • Agenda de pesquisa em otimizadores de consultas para ambientes altamente distribuídos

  4. II- Por que Ambientes Altamente Distribuídos? • Sistemas distribuídos podem envolver milhares de nós heterogêneos (“sites”) • PCs • “Mainframes” • Sistemas distribuídos são extremamente dinâmicos • Mudanças de estado dos nós • Acréscimo de novos nós

  5. II- Por que Ambientes Altamente Distribuídos?(2) • Sistemas legados devem sobreviver • Convivência com outros (modernos) sistemas em um ambiente altamente distribuído

  6. II- Por que Ambientes Altamente Distribuídos?(3) • Necessidade de ambientes altamente distribuídos • Custo e Escala • Mil PCs custam mais barato e são significativamente mais poderosos do que um “big mainframe” • Fazer um “upgrade” de um “mainframe” é complicado • Acrescentar um novo PC à rede é muito simples • Alta disponibilidade pode ser alcançada via espelhamento (replicação) de dados

  7. II- Por que Ambientes Altamente Distribuídos?(4) • Necessidade de ambientes altamente distribuídos • Integração de diferentes pacotes de software • Nenhum pacote individualmente pode contemplar todos os requisitos de uma empresa • Um “bag” de pacotes (isto é, pacotes diferentes e/ou cópias), com potencialmente seu próprio BD, constitui um sistema de banco de dados distribuído (BDD)

  8. II- Por que Ambientes Altamente Distribuídos?(5) • Necessidade de ambientes altamente distribuídos • Integração de sistemas legados • Os velhos pacotes devem co-existir com os novos (modernos) pacotes • Novas aplicações • Muitas aplicações (emergentes) estão se tornando imperativas, e são pesadamente dependentes de tecnologias de BDD • “E-commerce” • Gerência de “workflow” • “Computer supported collaborative work” (“Groupware”) • Teleconferência

  9. II- Por que Ambientes Altamente Distribuídos?(6) • Necessidade de ambientes altamente distribuídos • Imposição do Mercado • Empresas estão sendo forçadas a reorganizar seus negócios para se manter competitivas • Serviços “on-line”

  10. III- Processamento ‘Clássico’ de Consultas Distribuídas: Hipóteses Assumidas • Usuários e programadores de aplicação submetem suas consultas usando uma linguagem declarativa como SQL ou OQL (“Object Query Language”) OK! • A meta é processar tais consultas tão eficientemente quanto possível • Minimizar tempos de resposta / “query throughput” • Usuários não sabem onde e como os dados estão armazenados OK! • Visão centralizada do BDD

  11. III- Processamento ... (2): Hipóteses Assumidas (2) • Os dados são estruturados Restrição • BDs relacionais ou OO • O hardware dos nós do BDD é mono-processador Restrição • Outra maneira de dizer é que sistemas de banco de dados paralelo (“parallel database systems”) são ignorados • O número de BDs é pequeno Restrição

  12. III- Processamento de Consultas Distribuídas (3) • Arquitetura de um Processador de Consultas • Otimizador de Consultas • Enumeração de Planos • Modelo Clássico de Custo para Planos

  13. III- Processamento de Consultas Distribuídas (4): Arquitetura de um Processador de Consultas Query Parser Result Base Data Internal repr. Query Rewrite Query Execution Engine Internal repr. Query Optimizer Execution plan Catalog (Meta Data) Code Generation Plan

  14. III- Processamento de Consultas Distribuídas (5): Arquitetura de um Processador de Consultas (2) • Query Rewrite • Transforma logicamente uma consulta • Eliminação de predicados redundantes • Simplificação de expressões • Transformação de consultas com sub-consultas em consultas ‘planas’ • BDD: seleciona os fragmentos (“partitions”) de uma tabela que devem ser considerados para responder à consulta

  15. III- Processamento de Consultas Distribuídas (6): Arquitetura de um Processador de Consultas (3) • Query Optimizer • Promove otimizações que dependem do estado físico do sistema • “Access Paths” • Que índices usar • Que métodos (por exemplo, “hashing” ou “sorting”) usar para as operações “joins”, “group-bys” e “order by” • Em que ordem as operações devem ser executadas • Quanta memória alocar para cada operação • BDD: em que nó cada operação deve ser executada • Enumeração de planos alternativos • Escolha do melhor plano usando um modelo de estimativa de custos

  16. III- Processamento ... (7) Arquitetura ... (4): Planos Site 0 NLJ scan temp receive receive send send idxscan(A) scan(B) Site 1 Site 2

  17. III- Processamento ... (8) Arquitetura ... (5): “Query Execution Engine” • Implementações genéricas para cada operador (por exemplo, “send”, “scan”, NLJ) • “Pipelining” de resultados de um operador para outro • Desempenho

  18. III- Processamento ... (9) Arquitetura ... (6): Catálogo • Mantém: • O esquema do BD • BDD: o esquema de fragmentação • Informações físicas • Locação de cópias de fragmentos de tabela • Índices • Estatísticas para estimar o custo de um plano • BDD: onde armazenar o catálogo?

  19. III- Processamento ... (10) Arquitetura ... (7): Catálogo (2) • Armazenamento do catálogo • Em um nó central • Em WANs • Replicação do catálogo em diversos nós • Redução dos custos de comunicação • “Caches” de informações do catálogo em nós da rede

  20. III- Processamento ... (11) Arquitetura ... (8): Catálogo (3) • Sobre o tamanho e a dinamicidade de um catálogo • Catálogos de BDD podem tornar-se muito grandes e ser frequentemente atualizados • Catálogos hierarquizados • Fragmentos de catálogo • Replicação de (fragmentos de) catálogo

  21. III- Processamento de Consultas Distribuídas (12): ‘Otimizador’ de Consultas Input: SPJ query q on relations R1, ...,Rn Output: A query plan for q 1: fori = 1 to n do{ 2: optPlan({Ri}) = accessPlans(Ri) 3: prunePlans(optPlan({Ri}) 4: } 5: fori = 2 to n do{ 6: forallS {R1, ...,Rn} such thatS = ido{ 7: optPlan(S) =  8: for allO  Sdo { 9: optPlan(S) = optPlan(S)  joinPlans(optPlan(O), 10: optPlan(S-O)) 11: prunePlans(optPlan(S)) 12: } 13: } 14:} 15: return optPlan({R1, ...,Rn}) Algoritmo Dynamic Programming

  22. III- Processamento ... (13) ‘Otimizador’ de Consultas (2) • A lógica do algoritmo • Construir (sub-)planos mais complexos de (sub-)planos mais simples • Primeiro passo • Planos de acesso para toda tabela envolvida na consulta: linhas 1 a 4 • Exemplo: tabela A replicada nos nós S1 e S2 • Planos de acesso alternativos • scan(A, S1) e scan(A,S2) • Um dos dois planos é descartado, em princípio (modelo de custos)

  23. III- Processamento ... (14) ‘Otimizador’ de Consultas (3) • Sobre o descarte de planos (“prunePlans”) • BDD: nem scan(A, S1) e nem scan(A, S2) podem ser imediatamente descartados • Mesmo se scan(A, S1) for mais barato que scan(A, S2), scan(A, S2) ainda poderia ser escolhido se os resultados da consulta devessem ser apresentados em S2 (ou o que importa é o custo global da consulta)

  24. III- Processamento ... (15) ‘Otimizador’ de Consultas (4) • Segundo passo • Enumeração de “n-way join plans” (linhas 5 a 14) • Para entender o passo • Tabelas A (optPlan(A)) e B (optPlan(B)) • Junção de A e B i = 2 For all S  {A, B}, such that S = 2 For all O  S -- {A} e {B} optPlan({A, B}) = joinPlans(optPlan(A), optPlan(B)) optPlan({A, B}) = joinPlans(optPlan(B), optPlan(A)) • O melhor de “joinPlans” é escolhido

  25. III- Processamento ... (16) ‘Otimizador’ de Consultas (5) • Avaliação do algoritmo • Vantagens • Produz os melhores planos possíveis se o modelo de custo for suficientemente exato • Desvantagens • Não tem escala: complexidade exponencial • BDD: proibitivo para muitas consultas • Uma extensão do algoritmo Dynamic Programming para BDD é tema de uma das aulas

  26. III- Processamento ... (17) ‘Otimizador’ de Consultas (6): O Modelo Clássico de Custos • Composição do custo de um operador • CPU • Disco • “Seek” • “Latency” • “Transfer” • BDD: custos de comunicação • Custos por byte transferido • Custos de CPU: “to pack and unpack messages” • O custo pode ser pesado a fim de modelar o impacto de máquinas lentas e rápidas, e de “links” de comunicação • É mais caro transmitir dados de Passau (Alemanha) para Washington (EUA) do que de Passau para Munich (Alemanha)

  27. III- Processamento ... (18) ‘Otimizador’ de Consultas (7): O Modelo Clássico de Custos (2) • Critérios de avaliação de custos • “Minimum Resource Consumption” • Otimiza o “ overall throughput” do sistema • “Minimum Response Time” • O “throughput” pode baixar, mas as consultas processadas têm tempos de resposta otimizados

  28. III- Processamento ... (19) ‘Otimizador’ de Consultas (8): O Modelo Clássico de Custos (3) Site 0 join Site 0 receive receive join Site 1 Site 2 join join send send join join A B C D Minimum Resource Consumption A B C D Minimum Response Time

  29. III- Processamento ... (20) ‘Otimizador’ de Consultas (9): O Modelo Clássico de Custos (4) • Avaliação do Modelo de Custos • Somente funciona bem se poucos operadores rodam em paralelo

  30. III- Processamento ... (21) ‘Otimizador’ de Consultas (10): Técnicas de Junção e Transferência • Transferência • Junção

  31. III- Processamento ... (22) ‘Otimizador’ de Consultas (13): Transferência • “Row Blocking” • “Optimization of Multicasts” • Redes organizadas em um modo hierárquico • Exemplo: se quero mandar dados de Washington para Munich e para Dresden então • Washington  Munich • Munich  Dresden

  32. III- Processamento ... (23) ‘Otimizador’ de Consultas (14): Métodos de Junção • “Multithread Query Execution” Site 0 union receive receive receive send send send Scan(A1) Scan(A2) Scan(A3) Site 1 Site 2 Site 3

  33. III- Processamento ... (24) ‘Otimizador’ de Consultas (15): Métodos de Junção (2) • “Join with Horizontally Partitioned Data” • A = A1 A2 • A  B = (A1 A2)  B = (A1 B)  (A2 B) • “Semijoins” • A (nó 1) e B (nó 2), com transferência de A para B • A  B = A  (B  (A)),  (“semijoin”)

  34. III- Processamento ... (25) ‘Otimizador’ de Consultas (16): Outros Métodos de Junção (3) • “Double-Pipelined Hash Joins” • “Pointer-Based Joins and Distributed Object Assembly” • “Top N and Bottom N Queries”

  35. IV- Sistemas de Banco de Dados Cliente-Servidor • Arquiteturas • “Peer-to-Peer” • Todo nó pode atuar como um servidor ou como cliente • Cliente-Servidor Stricto Sensu • Cada nó tem um papel fixo • Servidor (“data source”) • Cliente (“query source”) • “Middleware” ou Multi-camadas • Nós organizados de modo hierárquico • Cada nó de uma camada intermediária exerce ao mesmo tempo os papéis de servidor e cliente

  36. IV- Sistemas de Banco de Dados Cliente-Servidor (2) • A Lógica das Arquiteturas Cliente-Servidor • Os BDs são persistentemente armazenados em máquinas servidoras, enquanto as consultas aos BDs são iniciadas em máquinas clientes • Perguntas • Onde processar uma consulta? No cliente? No servidor? • Política de “caching” na máquina cliente? • Como escolher os servidores se uma mesma cópia encontra-se replicada em vários servidores? • Como escolher os servidores (locais) e as ordens das operações se os dados estão distribuídos em vários servidores?

  37. IV- Sistemas de Banco de Dados Cliente-Servidor (3) • “Query Shipping” • Usado nos SGBDs relacionais comerciais client query server result join scan scan A B

  38. IV- Sistemas de Banco de Dados Cliente-Servidor (4): “Query Shipping” (2) • Sistemas Multi-camadas • Um servidor intermediário realiza a junção de tabelas armazenadas em diferentes servidores • “Gateways” entre os servidores de modo que a junção pode ser realizada em um dos servidores • As junções podem também ser distribuídas entre vários servidores

  39. IV- Sistemas de Banco de Dados Cliente-Servidor (5): “Data Shipping” • O Contrário de “Query Shipping” • Usado em SGBDs OO client join scan scan A B “cache” server A B

  40. IV- Sistemas de Banco de Dados Cliente-Servidor (6): “Data Shipping” (2) • Política de “Caching” • Páginas de tabelas e índices • Granulosidade • Páginas • Blocos de tuplas de 4K ou 8K

  41. IV- Sistemas de Banco de Dados Cliente-Servidor (7): “Hybrid Shipping” • Flexibilidade de processar operadores de consulta tanto em máquinas servidoras quanto máquinas clientes • “Caching” de dados por clientes • Usado em produtos como o SGBDOR UniSQL

  42. IV- Sistemas de Banco de Dados Cliente-Servidor (8): “Hybrid Shipping” (2) client join scan A server scan A B

  43. IV- Sistemas de Banco de Dados Cliente-Servidor (9): Discussão • Uma obviedade • “Query shipping” é recomendável se as máquinas servidoras são poderosas e as máquinas clientes são um tanto lentas • “Query shipping” e escala • Se houver muitos clientes simultaneamente, as máquinas servidoras passam a ser eventuais gargalos

  44. IV- Sistemas de Banco de Dados Cliente-Servidor (10): Discussão (2) • “Data shipping” e escala: em princípio, um casamento perfeito. Mas • Pode ser a causa de gargalos de comunicação • Má política de “caching”: grande quantidade de dados não filtrados enviados aos clientes • “Hybrid shipping”: em muitas situações, podem exibir melhor desempenho que “data” e “query shipping”. Mas • O processo de otimização das consultas é significativamente mais complexo

  45. IV- Sistemas de Banco de Dados Cliente-Servidor (11): Discussão (3) • Duas heurísticas (frutos da experiência) • Se a rede for rápida e se dados estiverem “cached” nos discos do cliente, pode ser melhor ler os mesmos dos discos do servidor • Se a rede for rápida e se os dados estiverem “cached” na memória do cliente, pode ser melhor transferir resultados parciais da consulta para o servidor, e completar a consulta no servidor • Conclusão: o conhecimento adquirido não poupa o ‘otimizador’ de consultas de ser um software extremamente complexo

  46. IV- Sistemas de Banco de Dados Cliente-Servidor (12): ‘Otimizadores’ de Consulta • Seleção de nó

  47. IV- Sistemas de Banco de Dados Cliente-Servidor (13) ‘Otimizadores’ de Consulta (2): Seleção (2) • Operadores binários: “join”, ... • Operadores unários: “sort”, “group-by”, ... • “Client”: nó onde a consulta é lançada • “Consumer”: o mesmo servidor que processa (consome) a saída do operador • “Producer”: o mesmo servidor que processa (produz) a entrada do operador • “Server (Scan)”: um servidor que armazena uma cópia dos dados a serem varridos • “Server (Update)”: todos os servidores que armazenam cópias dos dados • Todas as ‘anotações de nós’ são lógicas

  48. IV- Sistemas de Banco de Dados Cliente-Servidor (14) ‘Otimizadores’ de Consulta (3): Otimização em Dois Passos • Passo 1 • Em tempo de compilação, gerar um plano que especifica a ordem das junções, e os caminhos de acesso • Passo 2 • Antes que uma consulta seja executada, selecionar os nós para determinar onde os operadores serão processados

  49. IV- Sistemas de Banco de Dados Cliente-Servidor (15) ‘Otimizadores’ de Consulta (4): Otimização em Dois Passos (2) • Exemplo • Tabelas A e D em um servidor • Tabelas B e C em um outro servidor Primeiro passo: display join join join A B C D

  50. IV- Sistemas de Banco de Dados Cliente-Servidor (16) ‘Otimizadores’ de Consulta (5): Otimização em Dois Passos (3) Segundo passo: display join join join A B C D Movimento de dados

More Related