postgres big data
DESCRIPTION
trabalhando com bases além do 1TB no PostgreSQL. Palestra realizada junto com o Fabrízio de Royes Mello no PGBR2013TRANSCRIPT
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 ([email protected])
Fabrızio de Royes Mello ([email protected])http://www.timbira.com.br