Postgres Big data

  • Published on
    17-Dec-2014

  • View
    873

  • Download
    0

Embed Size (px)

DESCRIPTION

trabalhando com bases alm do 1TB no PostgreSQL. Palestra realizada junto com o Fabrzio de Royes Mello no PGBR2013

Transcript

<ul><li> 1. Postgres Big Data trabalhando com bases alem do 1TB no PostgreSQL Fabio Telles Rodriguez e Fabrzio de Royes Mello Timbira - A empresa brasileira de PostgreSQL 16 de agosto de 2013 </li> <li> 2. Apresentacao Fabio Telles Rodrigues DBA Oracle e PostgreSQL +10 anos Colaborador Comunidade Brasileira de PostgreSQL Blog: http://savepoint.blog.br @telles Fabrzio de Royes Mello DBA PostgreSQL +10 anos Colaborador Comunidade Brasileira de PostgreSQL Colaborador PostgreSQL Global Development Group Blog: http://fabriziomello.blogspot.com @fabriziomello </li> <li> 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 Correcao de bugs no PostgreSQL garantida em contrato </li> <li> 4. Sobre esta apresentacao esta apresentacao esta disponvel em: http://www.timbira.com.br/material esta apresentacao esta sob licenca Creative Commons Atribuicao 3.0 Brasil: http://creativecommons.org/licenses/by/3.0/br </li> <li> 5. Sobre o que estamos falando? Figura : Metro - SP / Estacao Se </li> <li> 6. Sobre o que NAO estamos falando? Map/Reduce Hadoop e tecnologias similares Camada de aplicacao Cluster e Replicacao DW </li> <li> 7. Sobre o que estamos falando? Big Data: E uma buzzword que serve para vender: hardware, licencas, cursos, livros, etc... Bases com mais de 1TB; Tabelas e/ou ndices com mais de 100GB; Consultas com bilhoes de registros envolvidos; Crescimento de varios GBs por dia; Relatorios e cargas em lote com janelas inviaveis. </li> <li> 8. Mantra Em Big Data nao existe solucao otima, boa ou regular, existe a menos pior!! </li> <li> 9. Espaco em Disco Imagine uma base de 1TB 20% crescimento ao ano = 1,75TB em 3 anos Espaco para backup = 3,5TB 250GB de archive = 3,75TB 500GB de area de manobra = 4,25TB 20% de margem de seguranca = 5,1TB RAID 1 = 10,2TB </li> <li> 10. Tablespaces Dividir os objetos e particoes em diferentes discos RAIDs, LUNs, etc; Dados menos acessados podem car em discos maiores e mais lentos; Dados mais acessados podem car em discos mais rapidos como SSDs; Dados temporarios ou que possam ser reconstrudos podem car em particoes com otimizacao mais agressiva; Ajustes no otimizador de consultas do Postgres podem ser feitas individualmente para cada tablespace. </li> <li> 11. RAID RAID 10 para os dados (seguranca + velocidade leitura e escrita) RAID 5 para dados historicos (velocidade leitura) RAID 0 para dados temporarios (velocidade de leitura e escrita) </li> <li> 12. Velocidade de E/S em disco Utilizar sempre discos conaveis como SAS e Fibre Channel O aumento na velocidade dos discos nao acompanha a CPU Uma unica consulta pode envolver a centenas de GBs Gravar em disco com concorrencia e lento em complexo Conseguir discos com um alto IOPS custa realmente caro </li> <li> 13. Velocidade de I/O Figura : Trem em Mulan - Paquistao </li> <li> 14. Particionamento de tabelas Dividir grandes tabelas e ndices em tabelas menores; Diminui consideravelmente o I/O quando voce so precisa dos dados numa particao; Mecanismo de particionamento ainda e pouco renado no PostgreSQL e possui muitas restricoes; A modelagem das tabelas particionadas funcionam melhor com PKs compostas; As consultas precisam utilizar clausulas que batem com o particionamento na clausula WHERE; Exigem muitos testes e ajustes para funcionar bem. Veja palestra Chain Saw Massacreamanha!!! </li> <li> 15. E a modelagem? Utilizar conceito de chave mestre!! Bancos VARCHAR Colunas Espertas (multi-proposito) Restricoes de integridade Chave Natural e Chave Articial Problemas com modelagem ruim nunca aparecem em bases com poucos GBs. Quando a sua base ja possui TBs, os problemas de modelagem se tornam insoluveis; </li> <li> 16. Backup Bases ate alguns GBs: pg dump (backup logico); Bases ate 500GB: pg backup (backup fsico); Bases maiores que 500GB: pg rman (backup fsico incremental) OU snapshot via storage (e caro mas e animal!) </li> <li> 17. Vacuum Nao rodar o VACUUM signica perder espaco em disco e performance, e em casos crticos 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: Nao existe solucao auto-magica </li> <li> 18. Inchacos (bloat) Tabelas e Indices JAMAIS use o VACUUM FULL!! E proibido e ponto nal! (tenta se for macho) CREATE INDEX CONCLURRENTLY REINDEX CONCURRENTLY (9.3) pg repack (fork do pg reorg) </li> <li> 19. Tunning Linux sysctl.conf (shmmax, oomkiller, sem) limits.conf (nproc, nole) PostgreSQL shared buers, temp buers e wal buers checkpoint segments work mem eective cache size Ajuste Planner Cost Constantspor tablespace </li> <li> 20. Outros recursos Indices parciais Indices funcionais Visoes materializadas Foreign Data Wrappers Pool de Conexoes (pgbouncer) Memcache Um exemplo pratico!! </li> <li> 21. Carga de Dados usar COPY ao inves de INSERT Unlogged Tables para dados temporarios desligar autovacuum e ligar depois remover indices antes e criar depois remover constraints antes e criar depois ajustes conguracoes para sessao ou usuario (temp buers, work mem e maintenance work mem) paralelizar a carga </li> <li> 22. Expurgo de Dados Particionamento e DROP TABLE Usar INSERT ao inves 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 </li> <li> 23. Escrevendo SQL Jamais utilize uma funcao em PL para algo que um SQL puro consegue fazer; COMMIT a cada X alteracoes. X &gt; 100 e &lt; 100K; Se uma consulta retorna mais de 100 registros, reveja a regra de negocio; INSERT &gt; INSERT multiplo &gt; PREPARE e EXECUTE &gt; INSERT ... SELECT &gt; COPY Aprenda a usar Sub-Queries, Window Functions e Common Table Expression; Relatorios pesados devem utilizar visoes materializadas. </li> <li> 24. Testes Teste as funcionalidades Teste com volumes de dados o mais realistas possvel Teste com carga de concorrencia o mais realista possvel </li> <li> 25. Monitoramento Monitore o SO, o PostgreSQL, a aplicacao Acompanhar o crescimento dos objetos Gere logs que mostrem a operacao e a duracao de cada acao Gere logs em formatos que possam ser manipulados por ferramentas automatizadas Aprenda a congurar o log do PostgreSQL e o PGBadger Faca coletas periodicas e armazene tudo em um local central Crie baselines e compare sempre com elas </li> <li> 26. Para os DBAs... Durma bem antes de um novo deploy. Tire uns dias de folga; Nao deixe de tomar cerveja com os amigos... Pratique exerccios fsicos regularmente!!! </li> <li> 27. Perguntas ? Fabio Telles Rodriguez (telles@timbira.com.br) Fabrzio de Royes Mello (fabrizio@timbira.com.br) http://www.timbira.com.br </li> </ul>