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 <[email protected]> >Para: Comunidade PostgreSQL Brasileira <[email protected]> >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 ><[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 > > > _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
