Bom, tentando explicar um pouco o motivo de tanta inserção:
como o Alexandre falou, sobre a previsão de crescimento.. A idéia
desde o começo foi crescer muito mais que estamos atualmente, mas não
foi pensado na consequencia que teriamos nesse banco de dados.
Na verdade não fui eu que modelei, mas já passamos por alguns
problemas e algumas coisas já foram melhoradas porque começou a dar
problema em certo ponto.
Atualmente o problema que surgiu agora, com mais de 1000 usuarios e
11000 filmes é essa inserção na hora do cadastro.
Quanto a esta inserção, que eu concordo que está errada pois quanto
mais cresce o número de filmes e/ou usuários esse problema vai
aumentar ainda mais, era algo necessário na idéia inicial devido a um
cálculo, como eu falei. O que acontece? Cada usuário tem um certo
nível de similariedade com cada outro usuário. Isso é calculado a cada
nota que um usuário dá. Além disso, a cada X notas, as notas sugeridas
pra os filmes que você não assistiu também é calculada.
Para evitar que esses INSERTS sejam feitos na hora do cálculo, fazemos
tudo na hora do cadastro. Há algum tempo isso não era problema,
demorava menos de 1 minuto, mas agora está começando a virar
problema...
Bom, agora acho que dá pra entender melhor o caso e porque da opção dos
INSERTS na hora do cadastro. Faltou uma visão de problemas que isto
ocasionariam no futuro.
Mas enfim, estamos trabalhando em mudar isso já, mas faltam algumas
idéias de quais as melhores opções e quais idéias só vão resolver
momentaneamente e teremos mais prolemas no futuro.
Agradeço as respostas até agora e qualquer outra sugestão/crítica/etc
será muito bem-vinda!
Grato,
Wagner Bonfiglio
2008/7/8 Shander Lyrio <[EMAIL PROTECTED]>:
>
>
> Wagner Bonfiglio escreveu:
>
>> Eu tenho um site sobre filmes, que também é uma reede social. Temos
>> atualmente cerca de 1000 usuários e 11000 filmes.
> >
>> A modelagem, devido a alguns cálculos que são feitos, acabou definindo
>> que cada usuário tenha uma entrada em uma tabela relacionando cada um
>> dos outros usuários, além de uma entrada em outra tabela que relaciona
>> cada usuário com cada filme.
>>
>> Ou seja, quando um usuário é criado, eu tenho que inserir 1000
>> entradas na tabela q liga usuarios com usuarios, e 11000 entradas na
>> tabela que relaciona filmes com usuarios.
>
> Afe Deus, quais cálculos levaram vocês a uma modelagem destas??
>
>> Isso é feito através de uma função em plpgsql disparada por uma
>> trigger no insert da tabela de usuarios.
>
> Nuss.
>
>> O problema pro usuário é ter que esperar esses 12000 inserts
>> acontecerem (atualmante esta demorando 2min, mas a tendencia é
>> continuar crescendo tanto em usuarios como em filmes) durante o
>> cadastro.
>>
>> Já não sei mais o que fazer para melhorar isso, pois tem muitos
>> usuários que não esperam os inserts e fecham a página no meio,
>> causando diversos erros na hora de tentar logar no site...
>
> Que tal refazer a modelagem. Esta forma de fazer está claramente
> equivocada.
>
>> Minhas dúvidas são:
>> - essa prática de inserir todas essas entradas na hora do cadastro é
>> errado ou não tem problema?
>
> É errado, melhor dizendo, não recompendávelem pelo menos 99,99999% dos
> casos.
>
>> - a demora é porque o servidor está muito lento (ou seja, esses 12000
>> inserts deveriam ser mais rapidos)??
>
> A demora é porque a forma de fazer está equivocada. Para que ou porque
> isso tudo?? Poderia explicar melhor para tentarmos ajudar mais
> efetivamente??
>
>> - você chegou aqui entendendo o que eu quis dizer? hahaha não sei se
>> fui muito claro no problema, mas uma coisa interessante de citar é que
>> essas entradas entre todos os clientes e entre os clientes e todos os
>> filmes é importante pois o site calcula notas sugeridas para cada
>> usuário, dependendo dos votos deles e da semelhança dos votos com
>> outros usuários.
>
> Existem formas muito mais simples de se fazer estes cálculos, caso
> contrário o orkut teria um lag de horas ao se cadastrar um novo usuário.
> Vocês precisam repensar esta forma, ou contratar uma consultoria para
> fazê-lo. Mas nada poderá ser feito se vocês não tiverem a clara idéia de
> que isto precisa ser mudado.
>
>> Bom, se precisarem de mais detalhes sobre o caso eu posso comentar
>> mais aqui (não sei se tem problema em passar o site, então achei
>> melhor nem colocar o link). Mas espero que possam me ajudar de
>> qualquer forma, qualquer toque será bem vindo!
>
> Veja, seu problema não é o PostGreSql, é modelagem. A forma de fazer
> não está legal e precisa ser repensada. Acredito que um DBA na equipe
> pudesse auxiliar mais efetivamente.
>
> --
> Shander Lyrio
> _______________________________________________
> 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
