1. Postgres Big Data
trabalhando com bases al´em do 1TB no PostgreSQL
F´abio Telles Rodriguez e Fabr´ızio de Royes Mello
Timbira - A empresa brasileira de PostgreSQL
16 de agosto de 2013

2. Apresenta¸c˜ao
F´abio Telles Rodrigues
DBA Oracle e PostgreSQL +10 anos
Colaborador Comunidade Brasileira de PostgreSQL
Blog: http://savepoint.blog.br
@telles
Fabr´ızio de Royes Mello
DBA PostgreSQL +10 anos
Colaborador Comunidade Brasileira de PostgreSQL
Colaborador PostgreSQL Global Development Group
Blog: http://fabriziomello.blogspot.com
@fabriziomello

3. Timbira
http://www.timbira.com.br
A empresa Brasileira de PostgreSQL
Consultoria / Desenvolvimento
Planos de Suporte
Parcerias com Empresas Desenvolvedoras de Software
Treinamentos In-Company e On-Line
Corre¸c˜ao de bugs no PostgreSQL garantida em contrato

4. Sobre esta apresenta¸c˜ao
esta apresenta¸c˜ao est´a dispon´ıvel em:
http://www.timbira.com.br/material
esta apresenta¸c˜ao est´a sob licen¸ca Creative Commons
Atribui¸c˜ao 3.0 Brasil:
http://creativecommons.org/licenses/by/3.0/br

5. Sobre o que estamos falando?
Figura : Metrˆo - SP / Esta¸c˜ao S´e

6. Sobre o que N˜AO estamos falando?
Map/Reduce
Hadoop e tecnologias similares
Camada de aplica¸c˜ao
Cluster e Replica¸c˜ao
DW

7. Sobre o que estamos falando?
Big Data:
´E uma buzzword que serve para vender: hardware, licen¸cas,
cursos, livros, etc...
Bases com mais de 1TB;
Tabelas e/ou ´ındices com mais de 100GB;
Consultas com bilh˜oes de registros envolvidos;
Crescimento de v´arios GBs por dia;
Relat´orios e cargas em lote com janelas invi´aveis.

8. Mantra
Em Big Data n˜ao existe solu¸c˜ao
´otima, boa ou regular, existe a
”menos pior”!!

9. Espa¸co em Disco
Imagine uma base de 1TB
20% crescimento ao ano = 1,75TB em 3 anos
Espa¸co para backup = 3,5TB
250GB de archive = 3,75TB
500GB de ´area de manobra = 4,25TB
20% de margem de seguran¸ca = 5,1TB
RAID 1 = 10,2TB

10. Tablespaces
Dividir os objetos e parti¸c˜oes em diferentes discos RAIDs,
LUNs, etc;
Dados menos acessados podem ficar em discos maiores e mais
lentos;
Dados mais acessados podem ficar em discos mais r´apidos
como SSDs;
Dados tempor´arios ou que possam ser reconstru´ıdos podem
ficar em parti¸c˜oes com otimiza¸c˜ao mais agressiva;
Ajustes no otimizador de consultas do Postgres podem ser
feitas individualmente para cada tablespace.

11. RAID
RAID 10 para os dados (seguran¸ca + velocidade leitura e
escrita)
RAID 5 para dados hist´oricos (velocidade leitura)
RAID 0 para dados tempor´arios (velocidade de leitura e
escrita)

12. Velocidade de E/S em disco
Utilizar sempre discos confi´aveis como SAS e Fibre Channel
O aumento na velocidade dos discos n˜ao acompanha a CPU
Uma ´unica consulta pode envolver a centenas de GBs
Gravar em disco com concorrˆencia ´e lento em complexo
Conseguir discos com um alto IOPS custa realmente caro

13. Velocidade de I/O
Figura : Trem em Mulan - Paquist˜ao

14. Particionamento de tabelas
Dividir grandes tabelas e ´ındices em tabelas menores;
Diminui consideravelmente o I/O quando vocˆe s´o precisa dos
dados numa parti¸c˜ao;
Mecanismo de particionamento ainda ´e pouco refinado no
PostgreSQL e possui muitas restri¸c˜oes;
A modelagem das tabelas particionadas funcionam melhor
com PKs compostas;
As consultas precisam utilizar cl´ausulas que batem com o
particionamento na cl´ausula WHERE;
Exigem muitos testes e ajustes para funcionar bem.
Veja palestra ”Chain Saw Massacre”amanh˜a!!!

15. E a modelagem?
Utilizar conceito de ”chave mestre”!!
Bancos VARCHAR
Colunas Espertas (multi-prop´osito)
Restri¸c˜oes de integridade
Chave Natural e Chave Artificial
Problemas com modelagem ruim nunca aparecem em bases
com poucos GBs.
Quando a sua base j´a possui TBs, os problemas de
modelagem se tornam insol´uveis;

16. Backup
Bases at´e alguns GBs: pg dump (backup l´ogico);
Bases at´e 500GB: pg backup (backup f´ısico);
Bases maiores que 500GB: pg rman (backup f´ısico
incremental) OU snapshot via storage (´e caro mas ´e animal!)

17. Vacuum
N˜ao rodar o VACUUM significa perder espa¸co em disco e
performance, e em casos cr´ıticos o XID wraparound
Deixar o VACUUM rodar o tempo todo degrada a
performance (ajuste qtd de workers, cost delay, naptime, etc);
Desligar o AUTO VACUUM para cargas em lote;
Ajustar individualmente o VACUUM em todas tabelas
grandes.
Lembre-se: ”N˜ao existe solu¸c˜ao auto-m´agica”

18. Incha¸cos (bloat) Tabelas e ´Indices
JAMAIS use o VACUUM FULL!! ´E proibido e ponto final!
(tenta se for macho)
CREATE INDEX CONCLURRENTLY
REINDEX CONCURRENTLY (9.3)
pg repack (fork do pg reorg)

19. Tunning
Linux
sysctl.conf (shmmax, oomkiller, sem)
limits.conf (nproc, nofile)
PostgreSQL
shared buffers, temp buffers e wal buffers
checkpoint segments
work mem
effective cache size
Ajuste ”Planner Cost Constants”por tablespace

20. Outros recursos
´Indices parciais
´Indices funcionais
Vis˜oes materializadas
Foreign Data Wrappers
Pool de Conex˜oes (pgbouncer)
Memcache
Um exemplo pr´atico!!

21. Carga de Dados
usar COPY ao inv´es de INSERT
Unlogged Tables para dados tempor´arios
desligar autovacuum e ligar depois
remover indices antes e criar depois
remover constraints antes e criar depois
ajustes configura¸c˜oes para sess˜ao ou usu´ario (temp buffers,
work mem e maintenance work mem)
paralelizar a carga

22. Expurgo de Dados
Particionamento e DROP TABLE
Usar INSERT ao inv´es de DELETE
CREATE TABLE temp (LIKE original) WITH
(autovacuum enabled = false)
INSERT INTO temp AS SELECT ... WHERE ...
DROP TABLE original CASCADE
ALTER TABLE temp RENAME TO original
CREATE INDEX ...
ALTER TABLE ... ADD CONSTRAINT ...
CREATE TRIGGER ... (se houver)
ANALYZE original
Desligar autovacuum

23. Escrevendo SQL
Jamais utilize uma fun¸c˜ao em PL para algo que um SQL puro
consegue fazer;
COMMIT a cada X altera¸c˜oes. X > 100 e < 100K;
Se uma consulta retorna mais de 100 registros, reveja a regra
de neg´ocio;
INSERT > INSERT multiplo > PREPARE e EXECUTE >
INSERT ... SELECT > COPY
Aprenda a usar Sub-Queries, Window Functions e Common
Table Expression;
Relat´orios pesados devem utilizar vis˜oes materializadas.

24. Testes
Teste as funcionalidades
Teste com volumes de dados o mais realistas poss´ıvel
Teste com carga de concorrˆencia o mais realista poss´ıvel

25. Monitoramento
Monitore o SO, o PostgreSQL, a aplica¸c˜ao
Acompanhar o crescimento dos objetos
Gere logs que mostrem a opera¸c˜ao e a dura¸c˜ao de cada a¸c˜ao
Gere logs em formatos que possam ser manipulados por
ferramentas automatizadas
Aprenda a configurar o log do PostgreSQL e o PGBadger
Fa¸ca coletas peri´odicas e armazene tudo em um local central
Crie baselines e compare sempre com elas

26. Para os DBAs...
Durma bem antes de um novo deploy. Tire uns dias de folga;
N˜ao deixe de tomar cerveja com os amigos...
Pratique exerc´ıcios f´ısicos regularmente!!!

27. Perguntas
?
F´abio Telles Rodriguez (telles@timbira.com.br)
Fabr´ızio de Royes Mello (fabrizio@timbira.com.br)
http://www.timbira.com.br