Em 2 de agosto de 2012 13:55, Flavio Henrique Araque Gurgel <[email protected]> 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 [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
