Boa noite, Só agora pude acompanhar essa discussão. Vai aí minha dica. Hoje, onde trabalho, tempo os banco de dados divididos em schemas. Por exemplo. O schema security tem tabelas relacionados com segurança como menus dos usuários, direito de cada módulo para cada usuário. No schema scp temos o sistema de controle de processos. No schema comum, temos tabelas que são utilizados por qualquer sistema ou schema, como por exemplo o cadastro de usuários que acessam o sistema.
Quando você coloca em banco de dados separado, você pode fazer views para fazer select com junções entre tabelas de banco de dados distintos, mas para isso vc tem que compilar e instalar o módulo dblink e utilizá-lo sempre que efetuar consultas com bancos distintos. O schema facilita muito a criação de views e selects de tabelas distribuidas. Quanto ao desempenho, bem, não notei redução de desempenho em nenhum serviço rodando nas 350 estações. Uma dica. O banco de dados depende muito das operações de leitura e escrita. O mais importante no servidor é ter um bom disco e a configuração do postgresql.conf bem afinada. Se você ver que o seu disco está sendo muito utilizado e o servidor está meio lento, você pode dividir as tabelas ou até mesmo os schemas em tablespaces. Isso permite vc colocar tabelas em um segundo disco. Quando você faz isso, o planejador pode trabalhar de forma a dividir o trabalho dos discos. Por exemplo: Você tem os schemas A, B e C. Cada schema tem seu próprio sistema e cada sistema tem em média 100 usuários conectado simultaneamente. Se você colocar em 3 discos e colocar cada schema em um disco, quando o usuário do sistema A, B e C gravarem dados simultâneamente o postgres vai gravar esses dados mais rápido. Isso porque cada transação é uma thread e as threads vão trabalhar em paralelo gravando cada um em um disco ao invés de uma thread esperar os dados do usuário A gravar para começar a gravar os dados do usuário B. Espero que tenha conseguido explicar essa lógica. Qualquer dúvida, poste aqui. Atenciosamente Cleberson Costa Silva. Em 22/08/07, Pablo Sánchez <[EMAIL PROTECTED]> escreveu: > > Em 22/08/07, Jorge Vilela<[EMAIL PROTECTED]> escreveu: > > Quando falei sobre o maior número de conexões me referia ao fato de cada > > cliente se conectar a vários dbs. > > > > E sim, eu li que as tabelas internas ficariam muito grandes, mas se não > é > > assim, então não vejo porque usar várias databases... > > > > Obrigado pessoal, agora me resta saber se essa máquina nova vai aguentar > > todo mundo pendurado somente nela, isso eu descubro daqui uns dias :P > > Quantos usuários simultâneos? Qual o sistema operacional? Te dar uma > dica: utilize FreeBSD no lugar de Linux, ele tem uma feature default > em relação a caching de conexões TCP/IP que utiliza reaproveitamento > de sei lá o que (nem lembro mais) que o deixa muito mais robusto para > muitos usuários simultâneos... e estamos falando na casa dos milhares. > > http://bulk.fefe.de/scalability/ > > Observem o primeiro gráfico, o FreeBSD é o azul. Ao chegar em 3500 > conexões o tempo de resposta cai pela metade. E isso era com o FreeBSD > 5.1. Hoje já estamos no 6.2... > _______________________________________________ > 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
