Já pensou em desenhar essa solução usando trigger de inserção? Para cada nova venda vc atualiza as tabelas de estatísticas, com isso vc pode listar os dados das tabela evitando demasiados joins e ainda ganha em saber o desempenho de cada vendedor/filial diariamente(ou até por minuto). Quando eu trabalhava com voip(~150K registro/ligações) essa foi a solução, mas cada caso é um caso.
2009/12/29 JotaComm <[email protected]> > Olá, > > 2009/12/29 <[email protected]> > >> >> Graaande JP tudo bem??? >> >> Vamos por partes... >> >> Um novo database para mim: >> >> 1.) O mesmo servidor possuindo dois BANCO DE DADOS: >> >> EXEMPLO: >> >> CREATE DATABASE producao >> WITH OWNER = postgres >> ENCODING = 'UTF8' >> CONNECTION LIMIT = -1; >> ALTER DATABASE producao SET work_mem=100MB; >> >> CREATE DATABASE producao2 >> WITH OWNER = postgres >> ENCODING = 'UTF8' >> CONNECTION LIMIT = -1; >> ALTER DATABASE producao SET work_mem=100MB; >> >> >> Acho que pode ser um novo esquema e não necessariamente um novo banco de > dados, pois se você tiver que comunicar os dois bancos você terá que usar um > dblink, enquanto que se você usar esquemas um simples JOIN especificando o > esquema resolve o problema. > > Uma pergunta. Vocês já fizeram um medição para definição do work_mem com > 100MB? Sem uma noção dos processos (consultas) e vendo de longe me parece um > valor bem alto. > > >> 2.) Sim a carga de 50.000 registros será em massa (no caso acima será no >> producao2) porém no producao está a todo o momento incluindo >> informações, em torno de 7.000 registros que neste caso não estarei >> usando em cálculos. >> > > Beleza. > >> >> 3.) A Classificação que mencionei, são cálculos de vendas nos últimos >> 3 meses (aproximadamente 4.500.000 registros), 30 dias (aproximadamente >> 1.500.000 registros), 13800 produtos, das 55 filiais (solicitação de >> amigos consultores..rssss). >> >> 4.) O postgresql é a versão 8.3.5 e a segundo a ultima consultoria (neste >> caso do Banco de Dados) nos informaram o ideal é separar estas ações em >> servidores diferentes pq temos dois "bancos" distintos, um para carga e >> outro para classificação (Consultas, cálculos, classificações). >> > > Eu não tomaria a decisão de separar em 2 servidores sem mais informações. > O procedimento será realizado todos os dias ou será em todo o fim de mês > que os dados serão processados? > > E o arquivo de configuração do postgresql.conf como está? Foi realizada > alguma configuração nele? > >> >> Abraços, >> >> Eder Sousa >> >> >> >> On Tue, 29 Dec 2009 13:56:58 -0200, JotaComm <[email protected]> wrote: >> > Olá, >> > >> > 2009/12/29 <[email protected]> >> > >> >> >> >> Tenho um sistema de Distribuição onde 99% das atividades é inclusão >> >> de >> >> registros que por sua vez está incluido em um database, surgiu a >> >> necessidade de implantar um novo database onde será efetuado a carga de >> >> dados diárias com aproximadamente 50.000 registros dias, porém neste >> >> database será classificado N calculo para administrar o estoque de 55 >> >> filiais. >> >> >> > >> > O que você considera um novo database. É um novo banco de dados >> separado? >> > Ou >> > um novo esquema dentro do banco de dados atual? >> > >> > A carga será em massa, isto é, em determinado horário serão inseridos >> > 50 mil >> > registros ou isso será feito durante o dia todo? >> > >> > Não entendi a última parte: Neste database será classificado N >> cálculo >> > para >> > administrar... >> > >> > >> > >> >> >> >> Até a carga de dados funciona maravilhosamente, porém quando inicia a >> >> execução das classificações o desempenho do servidor cai >> >> drasticamente. >> >> Pergunto: Neste caso é necessário um novo servidor para executar os >> >> cálculos, ao invés de efetuar no mesmo servidor?? >> >> >> > >> > Esta classificação é realizada a todo o momento ou em horários >> > específicos? >> > >> > Como está a configuração do postgresql.conf? >> > >> >> >> >> Só para conhecimento o servidor é um Quadcore com 8GB RAM e 1 Tera de >> >> HD.... >> >> >> >> []s >> >> >> >> Eder Sousa >> >> _______________________________________________ >> >> pgbr-geral mailing list >> >> [email protected] >> >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> >> >> > >> > >> > []s >> _______________________________________________ >> pgbr-geral mailing list >> [email protected] >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> > > > []s > -- > JotaComm > http://jotacomm.wordpress.com > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > -- [ ]'s Shairon Toledo http://www.google.com/profiles/shairon.toledo
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
