[firebase-br] 1.500 bancos FB ao mesmo tempo c/10 usuários via web

[Kelver Merlotti]

Em minha opinião o banco deve ser único, com IDs das empresas pra
filtrar as informações, pois se fizer tanto banco assim separado, a
manutenção (atualizações e backups) destes vai lhe custar muito caro!

Já com relação ao acesso a dados, acho que o ideal seria fazer em
multi-camadas, o que reduziria drasticamente o número de conexões
diretas ao banco, pois você pode ter, por exemplo, 5 servidores de
aplicação acessando o banco, ou seja, apenas 5 conexões ao Firibird, e
pode ter N conexões em cada um destes 5 servidores...  Outra
alternativa seria utilizar alguma boa tecnologia que forneça um pool
de conexões, como a do Asp.Net, por exemplo.

De qualquer forma, não se deve pensar em economia nos "hardwares"
envolvidos neste caso.. será necessário algumas centenas de mil reais
pra investimento, ou então, realmente contratar um bom IDC, como disse
o Eduardo.

Abraços!

2008/8/25 Rafael Christofoli <rafael.barros em twins.inf.br>:
> O melhor seria um banco somente separados por um ID de empresa, vai ter um
> rendimento muito maior, uma idéia seria cada cliente tivesse um banco local
> que atualizasse em certos horarios do dia o
> principal, temos um exemplo em nossa empresa em que cada filial tem seu
> banco local que de hora em hora gera pacotes para o ftp, que são acessados
> por uma aplicação que le esses pacotes e atualiza o banco principal
>
> --------------------------------------------------
> From: "Armando Boza Gonçalves" <armando.boza em gmail.com>
> Sent: Monday, August 25, 2008 8:30 AM
> To: "FireBase" <lista em firebase.com.br>
> Subject: Re: [firebase-br] 1.500 bancos FB ao mesmo tempo c/10 usuários via
> web
>
>> Apoiado, multi-empresa.
>>
>> Armando Boza
>>
>> Eduardo Bahiense escreveu:
>>> Olá Arlei
>>>
>>> Com esse volume, com certeza, a melhor abordagem é um banco multi
>>> empresas.
>>>
>>> Quanto às rescisões, não vejo limitação, você pode desenvolver um script
>>> de extração do metadata pelo ID da empresa.
>>>
>>> Quanto aos datacenters da vida, certamente, é o melhor que você pode
>>> fazer. Prover ambiente seguro e estável, no mesmo nível que um IDC pode
>>> te oferecer, 24x7, é muito mais caro que alugar um.
>>>
>>> Hoje temos um sistema rodando desta forma, com 7500 usuários, utilizando
>>> apenas dois fdbs de 3GB e o FB dá show! Não creio que você tenha que
>>> "apelar" para nada.
>>>
>>> Agora, 1500 arquivos vão te dar diversos gargalos, principalmente com
>>> acesso à disco e memória, sem falar em fazer bkps de 1500 bancos
>>> diariamente e também eventuais atualizações de ddl/dml. Tudo isso vai
>>> acabar te forçando a escalonar por máquinas, 1 servidor para cada 100
>>> bancos, pelo menos, o que lhe causará um custo em datacenter muito
>>> grande, e um esforço de manutenção enorme, mesmo com oracle e outros.
>>>
>>> Acredito que você deva estar partindo para um arquitetura em camadas com
>>> pool de conexões. Não vejo como suportar um ambiente desses em uma
>>> aboradagem cliente/servidor.
>>>
>>> Um cuidado que vocês devem tomar é na construção das queries, tudo tem
>>> que estar bem otimizado. Basta uma query mal escrita comendo 90% de CPU,
>>> para teus 1500 clientes ficarem fora do ar, independente do número de
>>> bancos que você utilize.
>>>
>>> É uma empreitada desafiadora! Boa sorte!
>>>
>>>
>>> Eduardo
>>>
>>>
>>> Arlei Ferreira Farnetani Junior escreveu:
>>>
>>>> Pessoal, estou finalizando um projeto onde teremos 1.500 empresas,
>>>> sendo cada empresa com mais ou menos de 5 a 10 usuários na média.
>>>>
>>>> Precisaremos separar cada empresa por um banco (.fdb). Pelo menos
>>>> esta é a idéia que definimos ser mais segura e rápida. Cada cliente
>>>> tem a sua base independente.
>>>>
>>>> Me digam uma coisa, este sistema será via Web.
>>>>
>>>> Vocês sabem me dizer se num servidor único eu conseguiria jogar
>>>> esta qtde de Banco de Dados com esta qtde de usuários acessando
>>>> o mesmo ou teria que partilhar recursos neste caso?
>>>>
>>>> Qual seria a configuração mais recomendada? Ou vcs acham que
>>>> eu deva partir direto para os datacenters da vida?
>>>>
>>>> Alguém pode me recomendar algum?
>>>>
>>>> Seria melhor eu ter apenas um banco de dados e definir a empresa
>>>> usuária por uma tabela ou até mesmo por segurança e desempenho
>>>> seria interessante eu ter pra cada empresa um banco de dados (.fdb)?
>>>>
>>>> O grande lance é que caso o cliente desista do contrato, temos que
>>>> garantir que seu banco de dados seja devolvido.
>>>>
>>>> Vocês acham que o Firebird aguenta o batente ou terei que partir
>>>> pra um Mysql, PostgresSql ou Oracle?
>>>>
>>>>
>>>> ______________________________________________
>>>> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
>>>> Para saber como gerenciar/excluir seu cadastro na lista, use:
>>>> http://www.firebase.com.br/fb/artigo.php?id=1107
>>>> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>>>>
>>>>
>>>
>>>
>>> ______________________________________________
>>> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
>>> Para saber como gerenciar/excluir seu cadastro na lista, use:
>>> http://www.firebase.com.br/fb/artigo.php?id=1107
>>> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>>>
>>>
>>
>>
>> ______________________________________________
>> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
>> Para saber como gerenciar/excluir seu cadastro na lista, use:
>> http://www.firebase.com.br/fb/artigo.php?id=1107
>> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>
>
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use: http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>



-- 
Kelver Merlotti
Coordenador Editorial do Portal www.ActiveDelphi.com.br
Contato: kelver em activedelphi.com.br
Google: kmerlotti em gmail.com
Msn: kmerlotti em hotmail.com