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