32
Bancos de Dados Autônomos José Augusto Oliveira – Guga [email protected] Karolyne Maria Alves de Oliveira [email protected]

Bancos de Dados Autônomos José Augusto Oliveira – Guga [email protected] Karolyne Maria Alves de Oliveira [email protected]

Embed Size (px)

Citation preview

Bancos de Dados Autônomos

José Augusto Oliveira – [email protected]

Karolyne Maria Alves de [email protected]

Roteiro

Computação Autônoma Bancos de Dados Autônomos

– Motivação– Conceito– Características

Estudo de Caso– Comércio Eletrônico

• Gerenciamento Dinâmico de Performance• Quartermaster - uma ferramenta para distribuição automática de carga • Resultados obtidos

Autonomia nos SGBDs atuais Conclusões Referências

Computação Autônoma

Motivação– Sistemas complexos, distribuídos e em

grande escala– Demanda de pessoal de altíssima

qualificação– Alto custo de gerência– Aplicações web críticas, com carga

aleatória

Computação Autônoma

O que é?– Sistemas inteligentes capazes de se auto-

configurar e detectar necessidade de mudanças ao longo do tempo

– Exemplos:• Gerência autônoma de rotas em uma rede• Gerência autônoma de carga em um site • Gerência autônoma de carga em um SGBD

Computação Autônoma

Características– Auto-conhecimento– Auto-configuração por demanda– Otimização contínua– Auto-correção– Monitoração de segurança– Detectar e adaptar-se a coexistência com outros

sistemas– Deve ser aberto– Tudo isso sem intervenção humana

Bancos de Dados Autônomos

Características (Sistemas Autônomos)

Auto-conhecimento Auto-configuração

Otimização contínuaAuto-correção

Monitoração de segurança Adaptar-se a coexistência

Compatibilidade com diversos sistemas

DBA

Bancos de Dados Autônomos Problemas

– Demanda crescente por qualidade de serviço (QoS)– SGBD

• Funcional• Conectado• Disponível• Heterogêneo

– Manutenção constate– Volume exponencial de dados– Era dos serviços eletrônicos

Bancos de Dados Autônomos Estudo de Caso

– Comércio Eletrônico

Auto-conhecimento Auto-configuração

Otimização contínuaAuto-correção

Monitoração de segurança Adaptar-se a coexistência

Compatibilidade com diversos sistemas

DBA

Estudo de Caso

Comércio Eletrônico

B2CB2B

Aplicações Internas

Comércio Eletrônico

Estudo de Caso Aplicações B2C

– Maior volume de aplicações eletrônicas– Sites de venda on-line– Serviços

• Bancos• Órgãos Públicos• Operadoras de telefonia

– QoS $$$• Lentidão• Indisponibilidade• Confiabilidade

Solução Priorizar acesso

Estudo de Caso O Problema

– Sites de comércio eletrônico movimentam transações da ordem de $K/seg.

– Volume de acesso é absolutamente aleatório

– Super estrutura torna serviço caro– Estrutura enxuta causa estrangulamento

eventual– Mudança do volume de acesso é freqüente

e rápida

Estudo de Caso Abordagem

1. Classificar as transações 2. Prover o banco com um mecanismo de monitoramento e reconfiguração sensível ao atendimento de QoS3. Implementar o mecanismo em um banco comercial4. Realizar experiências com variação de cargas de trabalho características de aplicações de comércio eletrônico5. Observar os valores obtidos em itens determinantes de QoS6. Mostrar que os indicadores permanecem constantes mesmo com a mudança aleatória de carga

Estudo de Caso Gerenciando performance

– Como se faz isso atualmente• Controle de admissão• Prioridade definida por parâmetros estáticos• Configurações geralmente demandam interrupção do banco

– Modelo proposto• Gerência de recursos orientada à metas (QoS)• Gerência de recursos do SO para o banco• Sistema no ar

Estudo de Caso Quartermaster

Interface

Analisador

Monitor

Controlador

Metas de

performance

Recursos do

Banco

Regras de Descrição

Metas de Performance

Log de Eventos

periodicamente

Planner

Estudo de Caso Realocação de Memória

Analisador

Monitor

Controlador

Metas de

performance

Regras de Descrição

Metas de Performance

Log de Eventos

DB2. . . Buffer Pools

índice cliente item depósitoTamanho configuradoSubstituição de página local ao BP

Buffer cleaners

Gerentes de I/O

Planner ARD

IA < 1 !!!

Estudo de Caso Monitor

– API de monitoração do DB2• Para cada buffer pool

– Número de leituras lógicas– Número de leituras físicas

Monitor

Metas de

performance

Recursos do

Banco

Regras de Descrição

Metas de Performance

Log de Eventos

Estudo de Caso Analisador

– IA = Tempo de resposta meta Tempo de resposta real

Analisador

Monitor

Metas de

performance

Recursos do

Banco

Regras de Descrição

Metas de Performance

Log de Eventos

IA < 1 !!!periodicamente

Estudo de Caso Planner

Analisador

Monitor

Recursos do

Banco

Planner

ARD

Estudo de Caso Algoritmo de relocação - ARD

– Algoritmo guloso– Iterativo– A cada iteração

• Realoca uma quantidade β de páginas entre buffers– Quem recebe?

» Buffers onde estão os objetos de T que violou QoS– Quem cede?

» Demais buffers• A eleição dos buffers origem (cedem) busca o resultado ótimo para T• Melhor troca possível

– “resultado ótimo” em tempo de resposta– Lógica simples : mais acertos nos buffers => menos acesso a disco

. . . Buffer Pools

β

Estudo de Caso Encontrando a melhor troca

1. Para cada par possível origem-destino• Calcular a taxa de acerto pós troca

– Origem-β páginas x Destino+β

2. Baseando nestes valores, encontrar o custo (tempo) de leitura de um buffer3. Somar todas as leituras que uma transação da classe T faz nos buffers

• Isso significará o tempo médio de leitura para uma transação da classe T (representaremos por C )4. O par de buffers origem-destino que produzir o menor valor de C é a melhor troca

Estudo de Caso 1 – taxa de acerto pós troca

H(M) = 1 - a x Mb

b = ln(1 – H(M2)) – ln(1-H(M1))

lnM2 – lnM1a = 1 – H(M1)

eb x ln(M1)

Equação de Belady para taxa de acerto

Onde :H(M) – taxa de acerto para o tamanho M de buffer poolM – Tamanho do buffer poola e b - constantes

Estudo de Caso 2 – Encontrar o custo de leitura

Clique aqui para demonstração...

Onde :Hi – taxa de acerto no buffer id – proporção de páginas sujas no buffer i de tamanho Mip(Mi) – Proporção de “páginas sujas” limpas pelos I/Ocleaners

ri = (1 – Hi) x ( 1 + (1- p(Mi)) x d )

Tempo de Resposta

Ci = ∑∑Li(0) x rj

todos os objetos de T em um buffer

todos os buffers

Estudo de Caso Experimento 1

– Mudança de QoS faz comportamento de alocação de buffers mudar

Experimento 2– Mudança de carga pode ser absorvida pelo ARD, mantendo QoS constante

Estudo de Caso - Experimento O experimento utilizou três buffer pools

identificados por BP_DATA1, BP_DATA2 e BP_INDEX. – BP_DATA1 – WareHouse, Tabelas de Itens e de

Distritos.– BP_DATA2 – Outras tabelas– BP_INDEX – Todos os Índices

Existe um total de 100000 páginas alocadas pelos buffer pools da seguinte maneira:– BP_DATA1 – 33334 páginas– BP_DATA2 – 33333 páginas– BP_INDEX – 33333 páginas

Estudo de Caso – Experimento 1 Panorama dos resultados

Classes de Transações Estado Anterior Estado Posterior

Novo Pedido 2.52 1.49

Entrega 2.51 1.41

Pagamento 0.30 0.26

Status do Pedido 0.25 0.30

Nível do Estoque 0.11 0.25

Experimento 1 – Média do Tempo de Resposta (seg)

Média do Tempo de Resposta (Segundo)

Índice de Acerto

(BP_DATA1, BP_DATA2, BP_INDEX)

Estado Anterior 2.51 0.60 (33334, 33333, 33333)

Estado Posterior 1.41 1.06 (10334, 53333, 36333)Experimento 1 – Detalhes da Classe Entrega

–Mudança de QoS faz comportamento de alocação de buffers mudar

Novos requisitos de QoS foram atendidos!

As metas das outras classes permanecem “melhor-esforço”

Estudo de Caso – Experimento 2Classes de Transações

Estado Anterior Estado Intermediário Estado Posterior

Tempo de Resposta

% de carga de trabalho

Tempo de Resposta

% de carga de trabalho

Tempo de Resposta

% de carga de trabalho

Novo Pedido 2.47 45 2.87 90 2.27 90

Entrega 2.48 4 3.35 2 2.45 2

Pagamento 0.31 43 0.43 4 0.38 4

Linha de Pedido

0.28 4 0.32 2 0.31 2

Nível do Estoque

0.12 4 0.16 2 0.11 2

Experimento 2 –Tempos de Resposta e Porcentagem de carga de Trabalho

Estudo de Caso – Experimento 2

Estado Classe de Transações

Média do Tempo de Resposta (Segundo)

Índice de Acerto

(BP_DATA1, BP_DATA2, BP_INDEX)

Estado Intermediário

Novo Pedido 2.87 0.87 (5000, 5000, 90000)

Entrega 3.35 0.75

Estado Posterior Novo Pedido 2.27 1.10 (500, 23000, 76500)

Entrega 2.45 1.02

Experimento 2 – Detalhes

Requisitos de QoS foram atendidos!

Autonomia nos SGBDs atuais Otimização Automática

– Ajuste dinâmico de consultas Configuração automática

– Assistentes de instalação e configuração– Muito pouco de automático

Auto-recuperação– Parcial : recupera, mas precisa ser acionado

Auto-Proteção– Mecanismos de auditoria– Criptografia– Controle de acesso

Autonomia nos SGBDs atuais Auto-organização

– Mudanças em tabelas no ar (Oracle)– Reindexação no ar

Auto-inspeção– “Se você não consegue medir, você não sabe”– Ferramentas para estatísticas de performance baseados em data mining.

Autonomia nos SGBDs atuais O que falta?

– Diminuir a dependência de intervenção humana– Adaptação dinâmica– Configuração de parâmetros no ar– Maior capacidade analítica– Estratégia de manutenção inteligente– Interface padrão com outros sistemas– Estratégia de segurança e privacidade mais ambiciosa

Conclusão

É uma extensão proposta para responder o crescimento da complexidade e a necessidade de agilidade.– O DBA é um mortal

Uma proposta foi vista– Experimentos mostraram resultados satisfatórios

Para cada característica de autonomia Ciência a ser produzida

Referências

[Martin, Powley, Li] Managing Database Server Performance to Meet QoS Requirements in Electronic Commerce Systems, 2004

[Elnaffar] Towards Workload-Aware DBMSS: Identifying worload type and predicting its change, tese de doutorado submetida a universidade Kigston, Ontário, Canadá

[Elnaffar, Martin]An intelligent framework to predict shifts in the workload of SGBDSs