O documento aborda estratégias para gerenciar cargas de trabalho mistas em PostgreSQL, abordando as diferenças entre OLTP, OLAP e sistemas web. Destaca a importância de ajustes de configuração, uso de tablespaces e funções eficientes para otimizar desempenho. O texto também menciona a aplicação em setores que requerem detecção em tempo real e análise, como trânsito e finanças.

1. PGBR 2013
Como lidar com cargas de trabalho mistas
Flavio Gurgel

2. 2
Flavio Gurgel
● Engenheiro eletricista - UFPR
● Líder de projetos especiais – 4Linux
● EnterpriseDB Certified Postgres Plus Associate
● Experiência:
● 18 anos - DBA
● 14 anos - PostgreSQL
● 4 anos – Comunidade brasileira PostgreSQL

3. 3
OLTP
● Transações rápidas
● Volume alto
● Poucas linhas de cada vez
● Maioria escrita
● INSERT, UPDATE, DELETE
● Operacional

4. 4
OLAP
● Transações lentas
● Volume menor
● Muitas linhas
● Maioria leitura
● SELECTs complexos
● Analítico

5. 5
WEB
● Saída do preto e branco
● Adaptação para o mundo Internet
● Intermediário entre OLTP e OLAP

6. 6
OLTP em PostgreSQL
● Priorizar escrita
● pg_xlog separado em discos rápidos
● shared_buffers mais alto
● work_mem mais baixo
● Poucas conexões
● Tuning dos parâmetros WAL
● Tuning do autovacuum
● Índices na dose certa
● Tablespaces onde necessário

7. 7
OLAP em PostgreSQL
● Priorizar leitura
● Algumas tabelas em tablespaces próprias
● Tablespaces em discos rápidos
● work_mem mais alto
● shared_buffers mais baixo
● Tuning dos parâmetros de custo
● Menos conexões ainda
● Maior abundância de índices

8. 8
Web em PostgreSQL
Algo entre os dois anteriores

9. 9
A loucura
Os três modelos anteriores...
...no mesmo banco de dados!
Tudo bem grande.
Lembrete: tem que ser rápido, CLARO.

10. 10
Como
COMO
COMO ?
COMO ???

11. 11
Já ia me esquecendo
Tem uma pitada de linguagem procedural também.

12. 12
Assim
Sistema
Transacional
Rápido
ETL
Banco de dados
em RAM
Sistema Web
do Recente
Usuários
Alertas
Sistema OLAP
do Histórico
Sistema
Alerta
Tabelas e
pl/PgSQL

13. 13
O que faz essa joça?
● Coleta os dados OLTP
● Faz um data mining dedicado:
● Detecta padrões em tempo real (Alertas)
● Permite análise manual do que foi alertado (Web)
● Permite análise refinada, posterior, cruzamentos e
relatórios (Histórico, OLAP)

14. 14
Quem usa isso?
● Quem precisa de detecção em tempo real, alerta e análise, exemplos:
● Trânsito – Detecção de gargalos
● Meteorologia – Prevenção de fenômenos
● Bancos - Prevenção à fraude
● Bolsa de valores – Ativação de circuit-breaker
● Energia – Preparação para picos de consumo
● Telefonia – Prevenção à clonagem

15. 15
1. Usar esquemas
Esquema
OLTP
Esquema
OLAP
Esquema
WEB
PL/pgSQL PL/pgSQL

16. 16
2. Muita memória
● Usar shared_buffers de OLTP
● Usar usuários separados para cada coisa
● OLTP, WEB e OLAP
● ETL
● Se possível segmentar mais
● work_mem individual

17. 17
3. Tablespaces
● Testar, testar
● Medir pg_statio_user_tables
● Verificar heap_blks_read e heap_blks_hit
● Medir pg_statio_user_indexes
● Verificar idx_blks_read e idx_blks_hit
● Separar quem usa mais

18. 18
3. Tablespaces
● select relname, heap_blks_read + heap_blks_hit as heap_usage from
pg_statio_user_tables order by 2 desc;
● relname | heap_usage
● --------------------+------------
● tabela1 | 6020
● tabela2 | 932
● tabela3 | 5
● tabela4 | 1
Tablespace 1
Tablespace 2

19. 19
4. Funções
● Simples e diretas
● Abusar - INSERT INTO foo SELECT...
● Cautela - tabelas temporárias
● Evitar – loops
● Preferir SELECTs complicados ao invés de loops

20. 20
5. Testar muito
● Ter sempre dados de teste bons
● Próximos da realidade
● Em grande volume
● Testar cada função individualmente
● Testar cada consulta individualmente
● Otimizar uma coisa de cada vez
● NUNCA ASSUMIR POR ACHISMO!

21. 21
6. Já em produção
● O log é meu melhor amigo
● PgBadger meu fiel escudeiro
● Escolha o pior e otimize primeiro
● Fazer uma otimização de cada vez
● Sempre verificar o impacto no resto
● NUNCA ASSUMIR POR ACHISMO!

22. 22
Importante
● Entender estatísticas do PostgreSQL
● pg_stat_*
● pg_statio_*
● Entender resultados do PgBagder
● Não existe mágica
● Não é para principiantes (sozinhos)
● Que são sempre bem vindos para contribuir e aprender juntos

23. 23
Conclusão
● Existe trabalho também embaixo do capô
● Discos
● Sistema de arquivos
● Hardware bem comprado e montado
● Demais dicas PostgreSQL

24. 24
Obrigado!
● Flavio Henrique Araque Gurgel
● flavio@4linux.com.br
● O nome mais forte em integração Open Source no Brasil
● O maior case Open Source em missão crítica: Caixa Econômica Federal
● Mais de 50.000 alunos treinados
● Mais de 10 anos apenas com Open Source
● Equipe multidisciplinar: analistas de negócios, programadores, arquitetos, sysadmins e
gerentes de projetos.
● Quando pega um desafio, sai do outro lado
● Parceira Red Hat, Zend, Puppetlabs, EnterpriseDB
● Orientada a padrões abertos e melhores práticas