Re: [pgbr-geral] Buffer Pool
Eu pretendo dividir e isolar a memória em duas partes, conceito conhecido como Buffer Pool em alguns outros SGBDs. Assim eu evitaria que a modificação dos dados da tabela C recicle o espaço de memória usado pelos registros da tabela A e B, pois nestas estão cadastros que são consultados frequentemente e o tempo de resposta requerido deve ser baixo. Existiria algo próximo a isso? Qual seria a melhor abordagem para que o cache seja mantido e reciclado ao mínimo? No PostgreSQL padrão isso não é possível. Um algoritmo de LRU é utilizado para todo o cache e a estratégia é retirar do cache tudo aquilo que foi utilizado há mais tempo. Você tem poucas opções: 1) Separar suas tabelas em vários clusters (instâncias) PostgreSQL. - vantagem: você pode dimensionar o cache (shared_buffers) para cada um deles; - desvantagem: não haverá integridade referencial entre as tabelas. 2) Fazer um cache grande o suficiente para que todas as tabelas caibam na memória. - vantagem: não vejo muita. - desvantagem: cache muito grande costuma causar piora de desempenho no PostgreSQL, justamente por causa do algoritmo que verifica o que deve ficar e o que deve sair da memória. 3) Desencana disso. Você precisa mesmo se preocupar com esse problema? 100 mil registros novos por dia não representam nada em hardware moderno. E as outras tabelas são estáticas mesmo... 4) Procure outro SGBD que atenda sua necessidade. Mas acho que é radical demais. O que você precisa é desempenho? Já fez testes? O tempo de acesso via índices no PostgreSQL é de microssegundos, o tempo maior é enviar o resultado da consulta via rede. Memória não ajuda tanto assim. 5) Utilize pg_memcache para definir exatamente o que você quer que esteja em memória. []s Flavio Henrique A. Gurgel Consultor e Instrutor 4Linux Tel: +55-11-2125-4747 www.4linux.com.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Buffer Pool
Em 2 de agosto de 2012 13:55, Flavio Henrique Araque Gurgel fla...@4linux.com.br escreveu: Eu pretendo dividir e isolar a memória em duas partes, conceito conhecido como Buffer Pool em alguns outros SGBDs. Assim eu evitaria que a modificação dos dados da tabela C recicle o espaço de memória usado pelos registros da tabela A e B, pois nestas estão cadastros que são consultados frequentemente e o tempo de resposta requerido deve ser baixo. Existiria algo próximo a isso? Qual seria a melhor abordagem para que o cache seja mantido e reciclado ao mínimo? No PostgreSQL padrão isso não é possível. Um algoritmo de LRU é utilizado para todo o cache e a estratégia é retirar do cache tudo aquilo que foi utilizado há mais tempo. Você tem poucas opções: 1) Separar suas tabelas em vários clusters (instâncias) PostgreSQL. - vantagem: você pode dimensionar o cache (shared_buffers) para cada um deles; - desvantagem: não haverá integridade referencial entre as tabelas. Isto não será possível. 2) Fazer um cache grande o suficiente para que todas as tabelas caibam na memória. - vantagem: não vejo muita. - desvantagem: cache muito grande costuma causar piora de desempenho no PostgreSQL, justamente por causa do algoritmo que verifica o que deve ficar e o que deve sair da memória. Apesar de que o custo das memórias RAM hoje tenham caído em relação a alguns anos atrás, poderá haver limitação de hardware. 3) Desencana disso. Você precisa mesmo se preocupar com esse problema? 100 mil registros novos por dia não representam nada em hardware moderno. E as outras tabelas são estáticas mesmo... Pensando a longo prazo, serão próximos de 36 milhões de registros por ano. As consultas realizadas usarão dados buscando datas arbitrárias na tabela C, podendo ciclar em demasia os dados estáticos das demais tabelas. 4) Procure outro SGBD que atenda sua necessidade. Mas acho que é radical demais. O que você precisa é desempenho? Já fez testes? O tempo de acesso via índices no PostgreSQL é de microssegundos, o tempo maior é enviar o resultado da consulta via rede. Memória não ajuda tanto assim. Trocar o SGBD também não é opção, e serão mais de 200 usuários simultâneos em um portal pela Web, mas acessos simultâneos no banco serão no máximo 20 gerenciados por um pool de conexões. Não fiz os testes ainda pois preciso terminar o projeto e já estou antecipando questões do ambiente. Testes eu já fiz em outro SGBD proprietário com estes esquemas de Buffer Pool, e atingi um I/O de quase zero ( 1% em relação aos cache hits) em situações bem próximas a que citei nesta thread. Se houvesse algo parecido, mesmo que no sistema operacional, seria perfeito. 5) Utilize pg_memcache para definir exatamente o que você quer que esteja em memória. Vou pesquisar e estudar a respeito. Talvez seja a solução. Obrigado pelas dicas! -- TIAGO J. ADAMI http://www.adamiworks.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Buffer Pool
Como o seu suposto problema é de I/O, porque não usa hds do tipo ssd. A leitura, em tese, é 30 a 40 vezes mais rápido. Jean Domingues. De: Tiago Adami adam...@gmail.com Para: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br Enviadas: Quinta-feira, 2 de Agosto de 2012 14:20 Assunto: Re: [pgbr-geral] Buffer Pool Em 2 de agosto de 2012 13:55, Flavio Henrique Araque Gurgel fla...@4linux.com.br escreveu: Eu pretendo dividir e isolar a memória em duas partes, conceito conhecido como Buffer Pool em alguns outros SGBDs. Assim eu evitaria que a modificação dos dados da tabela C recicle o espaço de memória usado pelos registros da tabela A e B, pois nestas estão cadastros que são consultados frequentemente e o tempo de resposta requerido deve ser baixo. Existiria algo próximo a isso? Qual seria a melhor abordagem para que o cache seja mantido e reciclado ao mínimo? No PostgreSQL padrão isso não é possível. Um algoritmo de LRU é utilizado para todo o cache e a estratégia é retirar do cache tudo aquilo que foi utilizado há mais tempo. Você tem poucas opções: 1) Separar suas tabelas em vários clusters (instâncias) PostgreSQL. - vantagem: você pode dimensionar o cache (shared_buffers) para cada um deles; - desvantagem: não haverá integridade referencial entre as tabelas. Isto não será possível. 2) Fazer um cache grande o suficiente para que todas as tabelas caibam na memória. - vantagem: não vejo muita. - desvantagem: cache muito grande costuma causar piora de desempenho no PostgreSQL, justamente por causa do algoritmo que verifica o que deve ficar e o que deve sair da memória. Apesar de que o custo das memórias RAM hoje tenham caído em relação a alguns anos atrás, poderá haver limitação de hardware. 3) Desencana disso. Você precisa mesmo se preocupar com esse problema? 100 mil registros novos por dia não representam nada em hardware moderno. E as outras tabelas são estáticas mesmo... Pensando a longo prazo, serão próximos de 36 milhões de registros por ano. As consultas realizadas usarão dados buscando datas arbitrárias na tabela C, podendo ciclar em demasia os dados estáticos das demais tabelas. 4) Procure outro SGBD que atenda sua necessidade. Mas acho que é radical demais. O que você precisa é desempenho? Já fez testes? O tempo de acesso via índices no PostgreSQL é de microssegundos, o tempo maior é enviar o resultado da consulta via rede. Memória não ajuda tanto assim. Trocar o SGBD também não é opção, e serão mais de 200 usuários simultâneos em um portal pela Web, mas acessos simultâneos no banco serão no máximo 20 gerenciados por um pool de conexões. Não fiz os testes ainda pois preciso terminar o projeto e já estou antecipando questões do ambiente. Testes eu já fiz em outro SGBD proprietário com estes esquemas de Buffer Pool, e atingi um I/O de quase zero ( 1% em relação aos cache hits) em situações bem próximas a que citei nesta thread. Se houvesse algo parecido, mesmo que no sistema operacional, seria perfeito. 5) Utilize pg_memcache para definir exatamente o que você quer que esteja em memória. Vou pesquisar e estudar a respeito. Talvez seja a solução. Obrigado pelas dicas! -- TIAGO J. ADAMI http://www.adamiworks.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Buffer Pool
Em 02-08-2012 15:07, Jean Domingues escreveu: Como o seu suposto problema é de I/O, porque não usa hds do tipo ssd. A leitura, em tese, é 30 a 40 vezes mais rápido. Pelo que entendi o problema do colega não existe. Ele está se antecipando apenas. São medos normais, mas só dá pra saber o que acontecerá com todos os componentes do ambiente prontos para uso e testes. Em tempo, quem trabalha com banco de dados não pode ter medo de fazer I/O. Achar que colocar tudo em memória é a solução de todos os problemas da vida é uma barca furadíssima. Claro que *alguns* problemas se resolvem com memória, mas são poucos casos. []s Flavio Henrique A. Gurgel Consultor e Instrutor 4Linux Tel: +55-11-2125-4747 www.4linux.com.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Buffer Pool
Em 2 de agosto de 2012 15:17, Flavio Henrique Araque Gurgel fla...@4linux.com.br escreveu: Em 02-08-2012 15:07, Jean Domingues escreveu: Como o seu suposto problema é de I/O, porque não usa hds do tipo ssd. A leitura, em tese, é 30 a 40 vezes mais rápido. Pelo que entendi o problema do colega não existe. Ele está se antecipando apenas. São medos normais, mas só dá pra saber o que acontecerá com todos os componentes do ambiente prontos para uso e testes. Em tempo, quem trabalha com banco de dados não pode ter medo de fazer I/O. Achar que colocar tudo em memória é a solução de todos os problemas da vida é uma barca furadíssima. Claro que *alguns* problemas se resolvem com memória, mas são poucos casos. Acredito que SSDs ainda não sejam a solução final. Além de caros ainda existem diversas incertezas. Outro dia vi um sistema que contém um tablespace em discos SSDs e tabelas apenas Read Only, bloqueadas para alteração de qualquer tipo no esquema do banco de dados. Somente o administrador faz uma nova carga de dados de tempos em tempos para atualizá-la. E sim, correto, o ambiente ainda não existe, tampouco o esquema está construido ou na fase final de projeto. Entendo seu ponto de vista, e fazer I/O não seria minha preocupação caso não obtesse resultados tão superiores no tempo de resposta de consultas naquele outro SGBD (mais especificamente, IBM DB2 9.7.4) com ganhos de 40% ou mais quando realizando consultas em concorrência. Não estou desmerecendo o PostgreSQL. Não é isso. Talvez o DB2 não seja tão eficiente na criação do plano de acesso ou na busca de dados com seus 3 formatos diferentes de tablespace (SMS, DMS ou DMS AS - não cabe aqui discutí-los), por isso ao colocar tudo em memória a diferença de resultado foi tão gritante. Se eu pudesse realizaria os mesmos testes que fiz na época do DB2 com o PostgreSQL, mas infelizmente não trabalho mais na empresa onde os fiz então fico um tanto impossibilitado. Mas vou arranjar um tempo para simular este ambiente com o DB2 organizado nos buffer pools que citei e com o PostgreSQL, depois coloco aqui os resultados para apreciação de todos. Novamente, obrigado. -- TIAGO J. ADAMI http://www.adamiworks.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Buffer Pool
On 02-08-2012 13:55, Flavio Henrique Araque Gurgel wrote: 2) Fazer um cache grande o suficiente para que todas as tabelas caibam na memória. - vantagem: não vejo muita. - desvantagem: cache muito grande costuma causar piora de desempenho no PostgreSQL, justamente por causa do algoritmo que verifica o que deve ficar e o que deve sair da memória. Você está chamando de cache a cache do PostgreSQL mas não se esqueça que alguns sistemas operacionais fazem cache dos arquivos lidos para aumentar a eficiência das operações. Então, quanto mais memória melhor (se puder caber a quantidade de dados manipulados no dia a dia, seria perfeito). Sendo assim, uma vez lidos os arquivos referentes as tabelas e índices envolvidos, a manipulação desses dados será algumas vezes mais rápida do que se o arquivo estivesse sendo acessado pela primeira vez. O que o Tiago precisa é de um bom sistema de discos. De preferência uma controladora que tenha bastante cache. E se o orçamento permitir, invista em discos SSD. 4) Procure outro SGBD que atenda sua necessidade. Mas acho que é radical demais. O que você precisa é desempenho? Já fez testes? O tempo de acesso via índices no PostgreSQL é de microssegundos, o tempo maior é enviar o resultado da consulta via rede. Memória não ajuda tanto assim. Acho que ele não precisa. ;) O PostgreSQL é extremamente rápido se a aplicação for pensada levando em consideração alguns aspectos da arquitetura do SGBD. Por último, é prudente pensar em um esquema de particionamento para a tabela C. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Buffer Pool
Em 2 de agosto de 2012 16:34, Euler Taveira eu...@timbira.com escreveu: (corte) O que o Tiago precisa é de um bom sistema de discos. De preferência uma controladora que tenha bastante cache. E se o orçamento permitir, invista em discos SSD. Só por desencargo de consciência, alguém tem dicas sobre marcas de controladora e discos SSD? Particularmente, minha vida mudou depois que troquei meu disco de 500 GB comum por um SSD de 115 GB em meu notebook, mas a vida útil que calculei para ele é de cerca de 8 anos com a quantia de gravações que realizo. Para servidores sei que existem discos mais parrudos, e triplamente mais caros que o meu no valor do MB, mas ainda desconheço sua durabilidade e confiabilidade. 4) Procure outro SGBD que atenda sua necessidade. Mas acho que é radical demais. O que você precisa é desempenho? Já fez testes? O tempo de acesso via índices no PostgreSQL é de microssegundos, o tempo maior é enviar o resultado da consulta via rede. Memória não ajuda tanto assim. Acho que ele não precisa. ;) O PostgreSQL é extremamente rápido se a aplicação for pensada levando em consideração alguns aspectos da arquitetura do SGBD. Por último, é prudente pensar em um esquema de particionamento para a tabela C. Sim, e por sinal já estava procurando a thread que menciona o uso de algumas views e triggers para tal, mas não encontrei. Alguém tem o link fácil para ela? -- TIAGO J. ADAMI http://www.adamiworks.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Buffer Pool
Em 2 de agosto de 2012 18:23, Tiago Adami adam...@gmail.com escreveu: [...] Por último, é prudente pensar em um esquema de particionamento para a tabela C. Sim, e por sinal já estava procurando a thread que menciona o uso de algumas views e triggers para tal, mas não encontrei. Alguém tem o link fácil para ela? Infelizmente particionamento de tabelas [1] no PostgreSQL é muito *manual*, mas se implementada adequadamente funciona muito bem. [1] http://www.postgresql.org/docs/current/static/ddl-partitioning.html -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL Blog sobre TI: http://fabriziomello.blogspot.com Perfil Linkedin: http://br.linkedin.com/in/fabriziomello Twitter: http://twitter.com/fabriziomello ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
