como lidar com cargas de trabalho mistas - postgresql

PGBR 2013

Como lidar com cargas de trabalho mistasFlavio Gurgel

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

OLTP

● Transações rápidas

● Volume alto

● Poucas linhas de cada vez

● Maioria escrita

● INSERT, UPDATE, DELETE

● Operacional

4

OLAP

● Transações lentas

● Volume menor

● Muitas linhas

● Maioria leitura

● SELECTs complexos

● Analítico

5

WEB

● Saída do preto e branco

● Adaptação para o mundo Internet

● Intermediário entre OLTP e OLAP

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

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

Web em PostgreSQL

Algo entre os dois anteriores

9

A loucura

Os três modelos anteriores...

...no mesmo banco de dados!

Tudo bem grande.

Lembrete: tem que ser rápido, CLARO.

10

Como

COMO

COMO ?

COMO ???

11

Já ia me esquecendo

Tem uma pitada de linguagem procedural também.

12

Assim

Sistema Transacional

Rápido

ETLBanco de dados

em RAM

Sistema Webdo Recente

Usuários

Alertas

Sistema OLAPdo Histórico

SistemaAlerta

Tabelas epl/PgSQL

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

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

1. Usar esquemas

EsquemaOLTP

EsquemaOLAP

EsquemaWEB

PL/pgSQL PL/pgSQL

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

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

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

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

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

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

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

Conclusão

● Existe trabalho também embaixo do capô

● Discos

● Sistema de arquivos

● Hardware bem comprado e montado

● Demais dicas PostgreSQL

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