Em 7 de dezembro de 2012 14:34, Matheus de Oliveira < [email protected]> escreveu:
> 2012/12/7 Joel Landim Mourão <[email protected]> > >> Boa tarde amigos, >> >> Andei lendo sobre o assunto depois de ter participado do PGDAY-SP, mas >> alguns documentos dizem que não é recomendável que o particionamento não >> traga muitos particionamentos, >> > > Depende. Não é recomendado muitas partições, 100 seria um limite (não > exato), agora, quanto à número mínimo de partições não vejo nenhuma > restrição. > > >> eu consigo particionar em meses, mas meus clientes costumam manter os >> dados por mais de dois anos, ainda é aceitável que eu tenha este tipo de >> particionamento? >> >> > Acredito que dependerá mais da quantidade de informações que tem > armazenada do que no tempo em que elas permanecem lá. É claro que fazer > expurgo de partições inteiras é bem mais rápido, é esse o caso? > > > >> Outra questão, todos os realtórios gerados são baseado apenas em dia, >> nunca em intervalo que intercale um dia com o outro, caso isso aconteça a >> apresentação sera separada em dia da mesma forma. >> >> > De qualquer forma, sempre que exibe um dia você iria em uma só partição, e > não precisaria buscar em várias. Você poderia inclusive particionar por ano > ou por semestre (ou outro padrão, como intervalos de ID), diminuindo a > quantidade de partições. Não precisa ser exatamente dia ou mês. > > > >> Existem outros relatórios que são "materializados" em outras tabelas, mas >> tudo seguindo o padrão de dias. >> >> Eu tenho condições de ajustar a minha aplicação para que em vez de ter >> uma tabela "mãe", eu consulte sempre as tabelas particionadas. >> >> > Para o particionamento do PostgreSQL, na maioria dos casos, não precisa > mudar nada na aplicação, a não ser que não use a chave da partição nas > consultas. > Como se trata de uma aplicação distribuida eu terei de moldar o sistema para que ele seja capaz de criar as proprias partições e toda sua estrutura, pois não há como ter uma manutenção a cada cliente a cada mês, por isso a mudança no comportamento do sistema talvez seja mais interessante apesar de mais arriscado. > > > >> Olhando este cenário, é um caminho aceitável e ou até recomendável para >> minha aplicação, considerando que esta tabela que será particionada já >> chegou a ter 180GB em 2 anos em alguns clientes, e é importante dizer, a >> app e o banco estão no mesmo servidor por não ser de nivel critico ou de >> muitas conexões, até hoje não mais que 200 conexões (localhost) simultaneas >> em nossos maiores clientes. >> >> > Cara, como já disse, vai depender da quantidade de registros dessa tabela > (do tamanho deles também) e o padrão/modelo de acesso, em muitos casos > 180GB não é considerado assim tão grande. > > Primeiro pergunte-se o porquê de você estar buscando o particionamento. > Está enfrentando problemas de performance? É para agilizar o expurgo de > dados? Muitos "buracos" na tabela? > Sim o objetivo é a performance pois existem alguns relatórios que ficam extremamente lentos mas quando isolo um numero menor de registros isso já me da um resultado aceitável e o expurgo de periodos sempre basados em mêses. > > Atenciosamente, > -- > Matheus de Oliveira > Analista de Banco de Dados PostgreSQL > Dextra Sistemas - MPS.Br nível F! > www.dextra.com.br/postgres > > > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > -- Joel Landim Mourão
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
