Postgres Big data

Postgres Big Datatrabalhando com bases alem do 1TB no PostgreSQL

Fabio Telles Rodriguez e Fabrızio de Royes Mello

Timbira - A empresa brasileira de PostgreSQL

16 de agosto de 2013

Apresentacao

Fabio Telles Rodrigues

I DBA Oracle e PostgreSQL +10 anos

I Colaborador Comunidade Brasileira de PostgreSQL

I Blog: http://savepoint.blog.br

I @telles

Fabrızio de Royes Mello

I DBA PostgreSQL +10 anos

I Colaborador Comunidade Brasileira de PostgreSQL

I Colaborador PostgreSQL Global Development Group

I Blog: http://fabriziomello.blogspot.com

I @fabriziomello

Timbira

I http://www.timbira.com.br

I A empresa Brasileira de PostgreSQL

I Consultoria / Desenvolvimento

I Planos de Suporte

I Parcerias com Empresas Desenvolvedoras de Software

I Treinamentos In-Company e On-Line

I Correcao de bugs no PostgreSQL garantida em contrato

Sobre esta apresentacao

I esta apresentacao esta disponıvel em:http://www.timbira.com.br/material

I esta apresentacao esta sob licenca Creative CommonsAtribuicao 3.0 Brasil :http://creativecommons.org/licenses/by/3.0/br

Sobre o que estamos falando?

Figura : Metro - SP / Estacao Se

Sobre o que NAO estamos falando?

I Map/Reduce

I Hadoop e tecnologias similares

I Camada de aplicacao

I Cluster e Replicacao

I DW

Sobre o que estamos falando?

Big Data:

I E uma buzzword que serve para vender: hardware, licencas,cursos, livros, etc...

I Bases com mais de 1TB;

I Tabelas e/ou ındices com mais de 100GB;

I Consultas com bilhoes de registros envolvidos;

I Crescimento de varios GBs por dia;

I Relatorios e cargas em lote com janelas inviaveis.

Mantra

Em Big Data nao existe solucaootima, boa ou regular, existe a”menos pior”!!

Espaco em Disco

Imagine uma base de 1TB

I 20% crescimento ao ano = 1,75TB em 3 anos

I Espaco para backup = 3,5TB

I 250GB de archive = 3,75TB

I 500GB de area de manobra = 4,25TB

I 20% de margem de seguranca = 5,1TB

I RAID 1 = 10,2TB

Tablespaces

I Dividir os objetos e particoes em diferentes discos RAIDs,LUNs, etc;

I Dados menos acessados podem ficar em discos maiores e maislentos;

I Dados mais acessados podem ficar em discos mais rapidoscomo SSDs;

I Dados temporarios ou que possam ser reconstruıdos podemficar em particoes com otimizacao mais agressiva;

I Ajustes no otimizador de consultas do Postgres podem serfeitas individualmente para cada tablespace.

RAID

I RAID 10 para os dados (seguranca + velocidade leitura eescrita)

I RAID 5 para dados historicos (velocidade leitura)

I RAID 0 para dados temporarios (velocidade de leitura eescrita)

Velocidade de E/S em disco

I Utilizar sempre discos confiaveis como SAS e Fibre Channel

I O aumento na velocidade dos discos nao acompanha a CPU

I Uma unica consulta pode envolver a centenas de GBs

I Gravar em disco com concorrencia e lento em complexo

I Conseguir discos com um alto IOPS custa realmente caro

Velocidade de I/O

Figura : Trem em Mulan - Paquistao

Particionamento de tabelas

I Dividir grandes tabelas e ındices em tabelas menores;

I Diminui consideravelmente o I/O quando voce so precisa dosdados numa particao;

I Mecanismo de particionamento ainda e pouco refinado noPostgreSQL e possui muitas restricoes;

I A modelagem das tabelas particionadas funcionam melhorcom PKs compostas;

I As consultas precisam utilizar clausulas que batem com oparticionamento na clausula WHERE;

I Exigem muitos testes e ajustes para funcionar bem.

I Veja palestra ”Chain Saw Massacre”amanha!!!

E a modelagem?

I Utilizar conceito de ”chave mestre”!!

I Bancos VARCHAR

I Colunas Espertas (multi-proposito)

I Restricoes de integridade

I Chave Natural e Chave Artificial

I Problemas com modelagem ruim nunca aparecem em basescom poucos GBs.

I Quando a sua base ja possui TBs, os problemas demodelagem se tornam insoluveis;

Backup

I Bases ate alguns GBs: pg dump (backup logico);

I Bases ate 500GB: pg backup (backup fısico);

I Bases maiores que 500GB: pg rman (backup fısicoincremental) OU snapshot via storage (e caro mas e animal!)

Vacuum

I Nao rodar o VACUUM significa perder espaco em disco eperformance, e em casos crıticos o XID wraparound

I Deixar o VACUUM rodar o tempo todo degrada aperformance (ajuste qtd de workers, cost delay, naptime, etc);

I Desligar o AUTO VACUUM para cargas em lote;

I Ajustar individualmente o VACUUM em todas tabelasgrandes.

I Lembre-se: ”Nao existe solucao auto-magica”

Inchacos (bloat) Tabelas e Indices

I JAMAIS use o VACUUM FULL!! E proibido e ponto final!(tenta se for macho)

I CREATE INDEX CONCLURRENTLY

I REINDEX CONCURRENTLY (9.3)

I pg repack (fork do pg reorg)

Tunning

Linux

I sysctl.conf (shmmax, oomkiller, sem)

I limits.conf (nproc, nofile)

PostgreSQL

I shared buffers, temp buffers e wal buffers

I checkpoint segments

I work mem

I effective cache size

I Ajuste ”Planner Cost Constants”por tablespace

Outros recursos

I Indices parciais

I Indices funcionais

I Visoes materializadas

I Foreign Data Wrappers

I Pool de Conexoes (pgbouncer)

I Memcache

I Um exemplo pratico!!

Carga de Dados

I usar COPY ao inves de INSERT

I Unlogged Tables para dados temporarios

I desligar autovacuum e ligar depois

I remover indices antes e criar depois

I remover constraints antes e criar depois

I ajustes configuracoes para sessao ou usuario (temp buffers,work mem e maintenance work mem)

I paralelizar a carga

Expurgo de Dados

Particionamento e DROP TABLE

Usar INSERT ao inves de DELETE

I CREATE TABLE temp (LIKE original) WITH(autovacuum enabled = false)

I INSERT INTO temp AS SELECT ... WHERE ...

I DROP TABLE original CASCADE

I ALTER TABLE temp RENAME TO original

I CREATE INDEX ...

I ALTER TABLE ... ADD CONSTRAINT ...

I CREATE TRIGGER ... (se houver)

I ANALYZE original

Desligar autovacuum

Escrevendo SQL

I Jamais utilize uma funcao em PL para algo que um SQL puroconsegue fazer;

I COMMIT a cada X alteracoes. X > 100 e < 100K;

I Se uma consulta retorna mais de 100 registros, reveja a regrade negocio;

I INSERT > INSERT multiplo > PREPARE e EXECUTE >INSERT ... SELECT > COPY

I Aprenda a usar Sub-Queries, Window Functions e CommonTable Expression;

I Relatorios pesados devem utilizar visoes materializadas.

Testes

I Teste as funcionalidades

I Teste com volumes de dados o mais realistas possıvel

I Teste com carga de concorrencia o mais realista possıvel

Monitoramento

I Monitore o SO, o PostgreSQL, a aplicacao

I Acompanhar o crescimento dos objetos

I Gere logs que mostrem a operacao e a duracao de cada acao

I Gere logs em formatos que possam ser manipulados porferramentas automatizadas

I Aprenda a configurar o log do PostgreSQL e o PGBadger

I Faca coletas periodicas e armazene tudo em um local central

I Crie baselines e compare sempre com elas

Para os DBAs...

I Durma bem antes de um novo deploy. Tire uns dias de folga;

I Nao deixe de tomar cerveja com os amigos...

I Pratique exercıcios fısicos regularmente!!!

Perguntas

?Fabio Telles Rodriguez (telles@timbira.com.br)

Fabrızio de Royes Mello (fabrizio@timbira.com.br)http://www.timbira.com.br