SlideShare uma empresa Scribd logo

Postgres Big data

•
•
Fabio Telles Rodriguez
Fabio Telles Rodriguez

trabalhando com bases além do 1TB no PostgreSQL. Palestra realizada junto com o Fabrízio de Royes Mello no PGBR2013

Apresentações relacionadas

Aumente a performance de seu site de maneira disciplinada
Aumente a performance de seu site de maneira disciplinadaAumente a performance de seu site de maneira disciplinada
Aumente a performance de seu site de maneira disciplinada
 
PostgreSQL Tuning: O elefante mais rápido que um leopardo
PostgreSQL Tuning: O elefante mais rápido que um leopardoPostgreSQL Tuning: O elefante mais rápido que um leopardo
PostgreSQL Tuning: O elefante mais rápido que um leopardo
 
Tunning PostgreSQL em modo OGRO - 13º Latinoware
Tunning PostgreSQL em modo OGRO - 13º LatinowareTunning PostgreSQL em modo OGRO - 13º Latinoware
Tunning PostgreSQL em modo OGRO - 13º Latinoware
 
1 de 27
Baixar para ler offline
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
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
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
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
Sobre o que estamos falando? Figura : Metrˆo - SP / Esta¸c˜ao S´e
Sobre o que N˜AO estamos falando? Map/Reduce Hadoop e tecnologias similares Camada de aplica¸c˜ao Cluster e Replica¸c˜ao DW
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.
Mantra Em Big Data n˜ao existe solu¸c˜ao ´otima, boa ou regular, existe a ”menos pior”!!
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
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.
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)
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
Velocidade de I/O Figura : Trem em Mulan - Paquist˜ao
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!!!
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;
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!)
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”
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)
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
Outros recursos ´Indices parciais ´Indices funcionais Vis˜oes materializadas Foreign Data Wrappers Pool de Conex˜oes (pgbouncer) Memcache Um exemplo pr´atico!!
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
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
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.
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
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
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!!!
Perguntas ? F´abio Telles Rodriguez (telles@timbira.com.br) Fabr´ızio de Royes Mello (fabrizio@timbira.com.br) http://www.timbira.com.br

Mais conteúdo relacionado

Postgres Big data

  • 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