Bancos de Dados
Autônomos
José Augusto Oliveira – Guga
[email protected]
Karolyne Maria Alves de Oliveira
[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 autoconfigurar 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)
Compatibilidade com
diversos sistemas
Auto-conhecimento
Auto-configuração
Auto-correção
Otimização contínua
DBA
Monitoração de segurança
Adaptar-se a coexistência
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
Compatibilidade com
diversos sistemas
Auto-conhecimento
Auto-configuração
Auto-correção
Otimização contínua
DBA
Monitoração de segurança
Adaptar-se a coexistência
Estudo de Caso

Comércio Eletrônico
Comércio Eletrônico
B2B
B2C
Aplicações Internas
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 QoS
3. Implementar o mecanismo em um banco
comercial
4. Realizar experiências com variação de cargas
de trabalho características de aplicações de
comércio eletrônico
5. Observar os valores obtidos em itens
determinantes de QoS
6. 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

Metas de
Quartermaster
performance
Interface
Planner
periodicamente
Controlador
Analisador
Monitor
Regras de Descrição
Metas de Performance
Log de Eventos
Recursos do
Banco
Estudo de Caso

Metas de
Realocação de Memória
Planner
performance
ARD
IA < 1 !!!
Regras de Descrição
Analisador
Controlador
Metas de Performance
Log de Eventos
Monitor
Buffer Pools
...
Gerentes de I/O
Buffer cleaners
DB2
índice cliente
item
depósito
Tamanho configurado
Substituição de página local ao BP
Estudo de Caso

Metas de
Monitor
– API de monitoração do DB2
performance
• Para cada buffer pool
– Número de leituras lógicas
– Número de leituras físicas
Regras de Descrição
Metas de Performance
Monitor
Recursos do
Banco
Log de Eventos
Estudo de Caso

Metas de
Analisador
– IA = Tempo de resposta meta
Tempo de resposta real
performance
IA < 1 !!!
periodicamente
Analisador
Monitor
Recursos do
Banco
Regras de Descrição
Metas de Performance
Log de Eventos
Estudo de Caso

Planner
ARD
Planner
Analisador
Monitor
Recursos do
Banco
Estudo de Caso

Algoritmo de relocação - ARD
– Algoritmo guloso
– Iterativo
– A cada iteração
β
...
Buffer Pools
• 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
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 buffer
3. 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
Equação de Belady para
b
taxa de acerto
H(M) = 1 - a x M
a = 1 – H(M1)
eb x ln(M1)

b = ln(1 – H(M2)) – ln(1-H(M1))
lnM2 – lnM1
Onde :
H(M) – taxa de acerto para o tamanho M de buffer pool
M – Tamanho do buffer pool
a e b - constantes
Estudo de Caso



2 – Encontrar o custo de leitura
ri = (1 – Hi) x ( 1 + (1- p(Mi)) x d )
Clique aqui para demonstração...
Onde :
Hi – taxa de acerto no buffer i
d – proporção de páginas sujas no buffer i de tamanho Mi
p(Mi) – Proporção de “páginas sujas” limpas pelos I/Ocleaners

Tempo de Resposta
todos os objetos de T em um buffer
Ci = ∑∑Li(0) x rj
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
–Mudança de QoS faz comportamento de alocação de buffers mudar
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
 Novos requisitos de QoS foram atendidos!
 As metas das outras classes permanecem “melhor-esforço”
Estudo de Caso – Experimento 2
Classes 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
Novo Pedido
2.27
1.10
Entrega
2.45
1.02
Estado Posterior
Experimento 2 – Detalhes
 Requisitos de QoS foram atendidos!
(500, 23000, 76500)
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
ser produzida
Ciência a
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