rumo a processamento de consultas em ambientes altamente distribuídos

Rumo a Rumo a Processamento Processamento de Consultas em de Consultas em

Ambientes Ambientes Altamente Altamente

DistribuídosDistribuídosDisciplina: Banco de DadosDisciplina: Banco de Dados

Pós-Graduação em Pós-Graduação em Informática (UFCG)Informática (UFCG)

ÍndiceÍndiceI- Objetivos da ApresentaçãoII- Por que Ambientes Altamente

Distribuídos?III- Processamento de Consultas DistribuídasIV- Processamento de Consultas com

Sistemas de Banco de Dados Cliente-Servidor

V- Sistemas de Bancos de Dados Heterogêneos

VI- Agenda de Pesquisa

I- ObjetivosI- 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

II- Por que Ambientes II- Por que Ambientes Altamente Distribuídos?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

II- Por que Ambientes II- Por que Ambientes Altamente Distribuídos?(2)Altamente Distribuídos?(2)• Sistemas legados devem sobreviver

– Convivência com outros (modernos) sistemas em um ambiente altamente distribuído

II- Por que Ambientes II- Por que Ambientes Altamente Distribuídos?(3)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

II- Por que Ambientes II- Por que Ambientes Altamente Distribuídos?(4)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)

II- Por que Ambientes II- Por que Ambientes Altamente Distribuídos?(5)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

II- Por que Ambientes II- Por que Ambientes Altamente Distribuídos?(6)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”

III- Processamento ‘Clássico’ de III- Processamento ‘Clássico’ de Consultas Distribuídas: Hipóteses Consultas Distribuídas: Hipóteses Assumidas 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

III- Processamento ... (2): III- Processamento ... (2): Hipóteses Assumidas (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

III- Processamento de Consultas III- Processamento de Consultas Distribuídas (3) Distribuídas (3)

• Arquitetura de um Processador de Consultas

• Otimizador de Consultas– Enumeração de Planos– Modelo Clássico de Custo para Planos

III- Processamento de Consultas Distribuídas III- Processamento de Consultas Distribuídas (4): Arquitetura de um Processador de (4): Arquitetura de um Processador de Consultas Consultas

Parser

QueryRewrite

QueryOptimizer

CodeGeneration

QueryExecution

Engine

Query

Catalog(Meta Data)

Base Data

Internalrepr.

Internalrepr.

Plan

Executionplan

Result

III- Processamento de Consultas Distribuídas III- Processamento de Consultas Distribuídas (5): Arquitetura de um Processador de (5): Arquitetura de um Processador de Consultas (2)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

III- Processamento de Consultas Distribuídas III- Processamento de Consultas Distribuídas (6): Arquitetura de um Processador de (6): Arquitetura de um Processador de Consultas (3)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

III- Processamento ... (7) III- Processamento ... (7) Arquitetura ... (4): Planos Arquitetura ... (4): Planos Site 0

Site 1 Site 2

NLJ

scan

temp

receivereceive

sendsend

idxscan(A) scan(B)

III- Processamento ... (8) Arquitetura ... III- Processamento ... (8) Arquitetura ... (5): “Query (5): “Query ExecutionExecution Engine” Engine”

• Implementações genéricas para cada operador (por exemplo, “send”, “scan”, NLJ)

• “Pipelining” de resultados de um operador para outro– Desempenho

III- Processamento ... (9) III- Processamento ... (9) Arquitetura ... (6): CatálogoArquitetura ... (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?

III- Processamento ... (10) III- Processamento ... (10) Arquitetura ... (7): Catálogo (2)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

III- Processamento ... (11) III- Processamento ... (11) Arquitetura ... (8): Catálogo (3)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

III- Processamento de Consultas III- Processamento de Consultas Distribuídas (12): ‘Otimizador’ de Distribuídas (12): ‘Otimizador’ de Consultas Consultas

Input: SPJ query q on relations R1, ...,Rn

Output: A query plan for q1: for i = 1 to n do {2: optPlan({Ri}) = accessPlans(Ri)3: prunePlans(optPlan({Ri})4: }5: for i = 2 to n do {6: for all S {R1, ...,Rn} such that S = i do {7: optPlan(S) = 8: for all O S do {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

III- Processamento ... (13) III- Processamento ... (13) ‘Otimizador’ de Consultas (2)‘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)

III- Processamento ... (14) III- Processamento ... (14) ‘Otimizador’ de Consultas (3)‘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)

III- Processamento ... (15) III- Processamento ... (15) ‘Otimizador’ de Consultas (4)‘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 = 2For 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

III- Processamento ... (16) III- Processamento ... (16) ‘Otimizador’ de Consultas (5)‘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

III- Processamento ... (17) ‘Otimizador’ III- Processamento ... (17) ‘Otimizador’ de Consultas (6): O Modelo Clássico de de Consultas (6): O Modelo Clássico de CustosCustos

• 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)

III- Processamento ... (18) ‘Otimizador’ III- Processamento ... (18) ‘Otimizador’ de Consultas (7): O Modelo Clássico de de Consultas (7): O Modelo Clássico de Custos (2)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

III- Processamento ... (19) ‘Otimizador’ de Consultas III- Processamento ... (19) ‘Otimizador’ de Consultas (8): O Modelo Clássico de Custos (3) (8): O Modelo Clássico de Custos (3)

Site 0

Site 0

Site 1 Site 2

joinjoin

join

CA B Djoinjoin

join

receivereceive

sendsend

A B C DMinimum Resource Consumption

Minimum Response Time

III- Processamento ... (20) ‘Otimizador’ III- Processamento ... (20) ‘Otimizador’ de Consultas (9): O Modelo Clássico de de Consultas (9): O Modelo Clássico de Custos (4)Custos (4)

• Avaliação do Modelo de Custos– Somente funciona bem se poucos

operadores rodam em paralelo

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

• Transferência• Junção

III- Processamento ... (22) ‘Otimizador’ III- Processamento ... (22) ‘Otimizador’ de Consultas (13): Transferênciade 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

III- Processamento ... (23) ‘Otimizador’ III- Processamento ... (23) ‘Otimizador’ de Consultas (14): Métodos de Junçãode Consultas (14): Métodos de Junção

• “Multithread Query Execution”

receivereceivereceive

union

sendsendsend

Scan(A1) Scan(A2) Scan(A3)

Site 0

Site 1 Site 2 Site 3

III- Processamento ... (24) ‘Otimizador’ III- Processamento ... (24) ‘Otimizador’ de Consultas (15): Métodos de Junção de Consultas (15): Métodos de Junção (2)(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”)

III- Processamento ... (25) ‘Otimizador’ III- Processamento ... (25) ‘Otimizador’ de Consultas (16): Outros Métodos de de Consultas (16): Outros Métodos de Junção (3)Junção (3)

• “Double-Pipelined Hash Joins”• “Pointer-Based Joins and Distributed

Object Assembly”• “Top N and Bottom N Queries”

IV- Sistemas de Banco de IV- Sistemas de Banco de Dados Cliente-ServidorDados 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

IV- Sistemas de Banco de IV- Sistemas de Banco de Dados Cliente-Servidor (2)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?

IV- Sistemas de Banco de IV- Sistemas de Banco de Dados Cliente-Servidor (3)Dados Cliente-Servidor (3)

• “Query Shipping”– Usado nos SGBDs relacionais comerciais

client

server

query

result

A Bscan scan

join

IV- Sistemas de Banco de Dados IV- Sistemas de Banco de Dados Cliente-Servidor (4): “Query Shipping” Cliente-Servidor (4): “Query Shipping” (2)(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

IV- Sistemas de Banco de Dados IV- Sistemas de Banco de Dados Cliente-Servidor (5): “Data Shipping”Cliente-Servidor (5): “Data Shipping”

• O Contrário de “Query Shipping”– Usado em SGBDs OO

client

server

A B

scan scan

join

A B

“cache”

IV- Sistemas de Banco de Dados IV- Sistemas de Banco de Dados Cliente-Servidor (6): “Data Shipping” Cliente-Servidor (6): “Data Shipping” (2)(2)

• Política de “Caching”– Páginas de tabelas e índices– Granulosidade

• Páginas – Blocos de tuplas de 4K ou 8K

IV- Sistemas de Banco de Dados IV- Sistemas de Banco de Dados Cliente-Servidor (7): “Hybrid Shipping” 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

IV- Sistemas de Banco de Dados IV- Sistemas de Banco de Dados Cliente-Servidor (8): “Hybrid Shipping” Cliente-Servidor (8): “Hybrid Shipping” (2)(2)

client

server

A B

scan

scan

join

A

IV- Sistemas de Banco de Dados IV- Sistemas de Banco de Dados Cliente-Servidor (9): DiscussãoCliente-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

IV- Sistemas de Banco de Dados IV- Sistemas de Banco de Dados Cliente-Servidor (10): Discussão (2)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

IV- Sistemas de Banco de Dados IV- Sistemas de Banco de Dados Cliente-Servidor (11): Discussão (3)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

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

ShippingQuery

ShippingHybrid

Shipping

display client client client

update client server client or server

binary operations

consumer (i.e., client)

producer of left or right

input

consumer or producer of left or right

input

unary operations

consumer (i.e., client)

producer consumer or producer

scan client server client or server

IV- Sistemas de Banco de Dados IV- Sistemas de Banco de Dados Cliente-Servidor (13) ‘Otimizadores’ de Cliente-Servidor (13) ‘Otimizadores’ de Consulta (2): Seleção (2)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

IV- Sistemas de Banco de Dados Cliente-IV- Sistemas de Banco de Dados Cliente-Servidor (14) ‘Otimizadores’ de Consulta (3): Servidor (14) ‘Otimizadores’ de Consulta (3): Otimização em Dois PassosOtimizaçã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

IV- Sistemas de Banco de Dados Cliente-IV- Sistemas de Banco de Dados Cliente-Servidor (15) ‘Otimizadores’ de Consulta (4): Servidor (15) ‘Otimizadores’ de Consulta (4): Otimização em Dois Passos (2)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

joinjoin

join

A B C D


Segundo passo:

display

joinjoin

join

A B C D

Movimento de dados


O plano gerado pelo segundo passo não leva em conta os custos de comunicação

Um possível plano ótimo:

display

joinjoin

join

A BCD

V- Sistemas de Bancos de V- Sistemas de Bancos de Dados HeterogêneosDados Heterogêneos• Sinônimos

– BDs federados– Sistema multi-banco de dados (“multidatabase

systems”)• Objetivos

– Facilitar o desenvolvimento de aplicações tendo acesso a diferentes bancos de dados componentes

• BDs de imagens• BDs relacionais• BDs objeto-relacionais• BDs orientados a objeto• BDs com interface Web (“WWW databases”)

V- Sistemas de Bancos de V- Sistemas de Bancos de Dados Heterogêneos (2)Dados Heterogêneos (2)• Desafios

– Encontrar planos de consulta ‘ótimos’ que explorem as capacidades específicas de cada BD componente

• Heterogeneidade estrutural

– Resolver o problema da heterogeneidade semântica

• Em um BD, a moeda é Euro• Em outro BD, a moeda é a Libra

– Cada BD componente tem uma interface específica (API), e pode não ter sido projetado para operar com outros BDs componentes

V- Sistemas de Bancos de V- Sistemas de Bancos de Dados Heterogêneos (3)Dados Heterogêneos (3)

• Uma Arquitetura

ClientClient

Mediator Catalog

Wrapper Wrapper

DatabaseDatabaseDatabase

V- Sistemas de Bancos de Dados V- Sistemas de Bancos de Dados Heterogêneos (4): Arquitetura (2)Heterogêneos (4): Arquitetura (2)• “Mediator”

– Comporta-se como um processador de consultas comum• “parser’• “rewrite”• “query optimization”• Processa algumas das operações da consulta

– Mantém um catálogo• “Global schema”• “External schemata” dos BDs componentes• Estatísticas para a otimização das consultas

– Projetado para ser independente de qualquer BD componente ─ genérico

• Não conhece as APIs específicas• Nada sabe sobre as capacidades locais de otimização de consultas

– Conclusão: um software complexo, com muitas das capacidades de um verdadeiro SGBD

V- Sistemas de Bancos de Dados V- Sistemas de Bancos de Dados Heterogêneos (5): Arquitetura (3)Heterogêneos (5): Arquitetura (3)• “Wrapper” (“Adaptor”)

– Solução para o requisito da independência do “mediator” em relação aos BDs componentes

– Associado, em princípio, com cada BD componente, escondendo-o (“encapsulating it”) do “mediator”

• “Wrapper” de um “WWW database” (por exemplo, amazon.com)

– Recebe do BD páginas html (por exemplo, lista de livros)

– Filtra informação útil (autor, título, preço, etc.) e a formata

– “Row blocking” e “caching” para desempenho e otimização

– Somente alguns tipos de consulta, pré-definidos

V- Sistemas de Bancos de Dados V- Sistemas de Bancos de Dados Heterogêneos (6): Arquitetura (4)Heterogêneos (6): Arquitetura (4)

• “Wrapper” (“Adaptor”)– Pode estar associado com vários BDs

componentes– Um software que pode ser muito

complexo– Felizmente: um “wrapper” pode

funcionar bem para muitos BDs componentes similares, ou com pequenas modificações

V- Sistemas de Bancos de Dados V- Sistemas de Bancos de Dados Heterogêneos (7): Arquitetura (5)Heterogêneos (7): Arquitetura (5)

• Extensibilidade da Arquitetura– “Wrappers” e BDs componentes podem ser

“upgraded”, ou novos “wrappers” / BDs componentes podem ser integrados, tudo isso sem mudar o “mediator” e os “wrappers” existentes

• Flexibilidade da Arquitetura– “Wrappers” e “mediator” podem ser instalados

em qualquer máquina do sistema– “Mediator” pode ser distribuído

• Instâncias cooperativas instaladas em diferentes máquinas

V- Sistemas de Bancos de Dados V- Sistemas de Bancos de Dados Heterogêneos (8): ‘Otimizador’ de Heterogêneos (8): ‘Otimizador’ de ConsultasConsultas

• Deve ser genérico, e capaz de ‘entender’ as capacidades dos BDs componentes

• Descreveremos o enfoque “planning functions”– Lembre-se: o “mediator” não conhece as APIs

(interfaces estilo SQL) dos BDs componentes!– Disponibilizadas pelos “wrappers”– Chamadas pelas funções “accessPlan” e “joinPlan” do

‘otimizador’ de consultas do “mediator”• Construção de subplanos (“wrapper plans”)

• O ‘otimizador’ segue o paradigma “dynamic programming”– Implementado no sistema Garlic, da IBM

V- Sistemas de Bancos de Dados V- Sistemas de Bancos de Dados Heterogêneos (9): ‘Otimizador’ de Heterogêneos (9): ‘Otimizador’ de Consultas (2)Consultas (2)

Mediator

Wrapper

ComponentDB

planningfunction(s) wrapper

plan

subconjuntoresposta

(p.e., “rowBlocking”)

consultaSQL (p.e.)

subconjuntoresposta

otimização departe da consulta

global

consultaglobal


“Planning functions” e “Wrapper Plans”: um Exemplo para um BD componente relacional “Planning functions”

plan_access(T, C, P) = R.scan(T,C,P,ds(T))

T = tabela

C = (conjunto de) colunas P = predicado ds(T) = retorna o ID do SGBD que armazena T


• “Planning functions”

• Subconsulta a um BD componente (desmembramento da consulta global, pelo “mediator”)Select e.name, e.salary, d.budgetFrom Emp e, Dept dWhere e.salary > 5,000 And e.works_in = d.dno

plan_join(S1, S2, P) = R.join(S1, S2, P) S1, S2 = subplans

Condition: S1.Site = S2.Site


• “Wrapper plan”plan_acess(Emp, {salary, works_in, name}

{salary > 5,000}) = R.scan(Emp, {salary, works_in, name}, {salary > 5,000}, D1)

plan_acess(Dept, {dno, budget}, {}) = R.scan(Dept, {dno, budget}, {}, D1)


• “Wrapper plan”R.join(R.scan(Emp, {salary, works_in, name}, {salary > 5,000}, D1),

R.scan(Dept, {dno, budget}, {}, D1),

{Emp.works_in = Dept.dno})

A escolha dos “wrapper plans” obedece a uma lógica de otimização da consulta global, de acordo com o paradigma “dynamic programmnig”


• Partes das consultas globais são processadas no “Mediator”– Integração e apresentação dos resultados– Mesmo operações intermediárias, como seleção e junção


• Exemplo 1– Um “WWW database” componente só seleciona

registros segundo critérios pré-determinados• Livros da editora “John Wiley & Sons”• Seleções adicionais necessárias são feitas pelo

“Mediator”– Autores franceses

• Exemplo 2– A juncão de duas tabelas (nos componentes 1 e

2, respectivamente) é feita no “mediator”


• Avaliação– Vantagens

• Apoiado em tecnologias provadas de BDD (planos de consulta, modelos de custo e “dynamic programming”)

• Flexibilidade da arquitetura proposta– Novos “wrappers” e BDs componentes– “Upgrades” de “wrappers” BDs componentes– “Mediators” distribuídos

• Reuso (ou quase) de “wrappers”

– Problemas• Modelos de custos são, em grande parte, um problema

aberto


• Uma abordagem de modelo de custos: “Learning Curve Approach”– Lembre-se: o “mediator” nada sabe dos BDs

componentes– Estimativa de custos de “wrapper plans”

• Monitoração do sistema, retendo estatísticas– Os últimos 3 planos envolvendo as tabelas A e B

tiveram custos de 10 seg, 20 seg e 30 seg, respectivamente

– Baseado nestas estatísticas, o modelo de custos pode estimar que o próximo plano envolvendo A e B deve custar 13 seg

VI- Agenda de PesquisaVI- Agenda de Pesquisa• Desafios

– Grande número de fontes de dados– Dados e organização de dados muito voláteis– Servidores de dados com pouca capacidade (“thin data

servers”)

• Tópicos de Pesquisa– “Dynamic Data Placement”– “Sensor Database Systems”– “Data Warehouses” Virtuais– Integração de Muitas Fontes de Dados

• “Data Web”– Integração de Muitas Fontes de Metadados

• “Semantic Web”

rumo a processamento de consultas em ambientes altamente distribuídos

Documents