[firebase-br] RES: 1.500 bancos FB ao mesmo tempo c/10 usuários via web
Eduardo Jedliczka - TeamFB
jedyfb em gmail.com
Qua Ago 27 11:58:21 -03 2008
Concordo com o meu chará.... Este tipo de decisão não se toma assim.
Já estive nos dois lados da história (um único banco atendendo mais de
150 empresas e 400 bancos individuais) e sei bem quais os problemas
inerentes.
Um único banco simplifica muito a administração (incluindo backup, e
atualizações de metadata) do hardware/ambiente, mas elimina quase
completamente a redundância, e qualquer alteração, por mais simples que
seja irá consumir grandes quantidades de tempo (imagina para
ativar/criar um novo índice). Isto sem falar nos problemas com
lock-manager.
Vários bancos possibilitam uma recuperação mais rápida (problemas só
afetarão apenas uma empresa) e pode-se migrar empresas de um servidor
para outro sem grandes dificuldades, possibilitando pequenos
investimentos para a expansão do ambiente (principalmente se tiver uma
storage) mas corre-se o risco de não conseguir administrar o metadados
de todos os bancos, pois cada um é atualizado individualmente.
Analisar os prós e contras é muito complexo... há muitos fatores, e
sempre há o meio termo (camadas de aplicação descentralizadas e/ou
redundantes, agrupar empresas por ramo de atividade, porte, ou perfil de
movimentação, criando assim poucas bases individualizando empresas
maiores)
diante disto, a melhor forma é realmente contratar uma consultoria. Se
você ainda não tem o software ou está desenvolvendo o software, seria
bom refletir de uma maneira mais ampla (não somente no custo de
implantação ou custo de desenvolvimento, mas no custo de manutenção e
expansão do ambiente)
Sem mais,
Eduardo Jedliczka
Em Seg, 2008-08-25 às 22:37 -0300, Eduardo Bahiense escreveu:
> Arlei
>
> Honestamente, não consigo ver viabilidade em 1500 fdb's.
> Você deve, antes de mais nada idealizar modelos e efetuar testes de
> carga e avaliar todo o tipo de procedimentos futuros, backups,
> atualizações, acessos simultâneos, uso médio de cpu, memória, etre
> outros. Outra coisa qe você vai precisar é de um serviço de login, que
> deve ser de alguma forma, centralizado, para poder te dar a
> possibilidade de escalonamento de recursos (conforme você vai sentindo
> os gargalos, vai abrindo novod servidores, transparentes aos clientes.
>
> Contratar um IDC agora pode te dar uma idéia, mas não é absolutamente
> necessário nesta fase. Um datacenter nada mais é que um micro com
> serviços web instalados e isso pode ser facilmente reproduzido in
> office, até para que você possa dimensionar sua necessidade e contratar
> na medida certa.
>
> É um requisito de base, por isso é importante que você se cerque de
> profissionais competentes para decidir esta arquitetura.
>
> O nível de dúvidas que você demonstra me dá uma leitura que muitos
> outros fatores importantes como normalização de dados, planejamento de
> índices, uso de memória, e até mesmo dimensionar a quantidade de banda
> que você precisará podem estar igualmente vulneráveis.
>
> Contrate uma consultoria. O que você obterá aqui na lista são opiniões
> descomprometidas que poderão te levar a um fracasso monstro. Ajustar ou
> reformular um ambienbte desses em produção, segundo o ministério da
> saúde, não faz bem a saúde e pode causar câncer e impotência.
>
>
> Abraço
>
>
> Eduardo
>
> PS. Eu não estou no ramo de consultoria de Banco de Dados.
>
>
> Arlei Ferreira Farnetani Junior escreveu:
> > Fabiano boa noite.
> >
> > Gostei da sua idéia.
> >
> > No caso desta nossa aplicação os clientes realmente
> > não tem relação nenhuma entre eles e os dados são
> > confidenciais a cada um, por isso o motivo de se ter
> > um banco (.fdb) pra cada cliente e até mesmo por
> > segurança.
> >
> > Alguns colegas disseram ser melhor ter um id numa tabela pra diferenciar,
> > acho mto arriscado isto, pq se perco um banco eu perco todos os clientes!
> > Correto?
> >
> > O grande problema é no lance da manutenção. Este sistema sofrerá
> > modificações
> > do metadata quase que diariamente, pois se trata de um sistema incremental,
> > imagine o trabalho que dará pra atualizar banco a banco via script. Aí
> > estive
> > estudando aqui a possibilidade da checagem do metadata antes de se abrir
> > o programa, caso o banco esteja desatualizado, ele automaticamente constroi
> > os metadatas no momento da inicialização (1o. login). É que pode ter cliente
> > que acesse o sistema diário ou semanal, ai no final da semana quando este
> > for
> > acessar imagine que ele terá mtas atualizações.
> >
> > No caso da conexão, com 1.500 empresas e 10 clientes por empresa na média
> > teremos a possibilidade de 15.000 acessos por vez. Então preciso trabalhar
> > com
> > esta possibilidade, visto que ela pode ocorrer. (qualidade do sistema)
> >
> > No exemplo que vc deu, eu teria:
> >
> > - UMA BASE DE EMPRESAS -> empresas.fdb que teria:
> >
> > Empresa: XXXXX
> > Código: 000001
> > Endereço: 192.168.0.1
> > (ip servidor 01)
> >
> >
> > Empresa: YYYYY
> > Código: 000002
> > Endereço: 192.168.0.2
> > (ip servidor 02)
> >
> > Banco de dados dos clientes:
> > 000001.fdb
> > 000002.fdb
> >
> >
> > - Aí no ato da conexão, o usuário ao conectar, primeiro iria identificar o
> > código
> > da empresa, o seu login e depois a sua senha e assim automaticamente teria o
> > endereço (ip) do servidor através da busca primeiro do endereço do servidor
> > e depois eu direcionaria a busca no banco. Assim eu iria distribuir as
> > cargas
> > de forma manualmente, avaliando através de um medidor o uso de cada empresa
> > nos servidores.
> >
> > - No caso, os pontos críticos seriam mais como será atualizado o metadata do
> > banco.
> >
> > Pessoal, valew pela colaboração aí de todos ok! A minha maior dúvida era
> > se poderia fazer com firebird, e isto pelo que todos responderam posso
> > fazer de olhos fechados.
> >
> > ----- Original Message -----
> > From: "Fabiano Segal" <fabianosegal em gmail.com>
> > To: "'FireBase'" <lista em firebase.com.br>
> > Sent: Monday, August 25, 2008 8:30 AM
> > Subject: [firebase-br] RES: 1.500 bancos FB ao mesmo tempo c/10 usuários via
> > web
> >
> >
> > Prezados.
> >
> > Tive uma situação dessas onde primariamente seccionamos os pontos de
> > gargalo.
> > Situações que você deva levar em consideração:
> >
> > Quantidade de usuários.
> > Quantidade de acessos simultâneos, pois você pode ter 1 milhão de usuários
> > mas somente mil fazerem acesso simultâneo.
> > Tipificação de sua conexão.
> >
> > "engenhando" a coisa o legal seria assim.
> >
> > ==> Os bancos em sua estrutura interna seriam idênticos, pois o software
> > seria o mesmo, certo?
> > ==> Você pode ter um único servidor de entrada, onde nele pelo código do
> > usuário o sistema identificaria onde fica o banco relativo ao usuário. Dessa
> > maneira, você pode seccionar em 4 servidores internos os seus usuários.
> > ==> Após estas medidas tomadas, pela variante de que cada cliente, caso
> > encerre seu contrato, deva ter seu banco de dados devolvido, é simplesmente
> > você ter o script do banco de dados, e via aplicação, você gera um banco de
> > dados tendo como parâmetro universal o código do cliente, transferindo assim
> > todas as informações de que são necessárias a devolução.
> > ==> Após enviar essa informação ao cliente, você limpa o banco original e
> > guarda também em seus arquivos o banco desse cliente para fiz de "resguardo"
> > empresarial.
> >
> > Espero ter ajudado.
> > Caso necessite, pode me enviar emails diretamente ou caso seja de sua
> > preferência também, poste pela lista pois todos tomam conhecimento e podem
> > auxiliar melhor na questão.
> >
> > Realmente não é tão simples a sua solução, mas seccionando-se os gargalos
> > você chegará mais facilmente à solução.
> >
> > Atenciosamente,
> >
> > Fabiano Segal
> > Analista de Sistemas
> > Gerente de CPD
> > INFOSYSTEM Tecnologia em Software
> >
> > -----Mensagem original-----
> > De: lista-bounces em firebase.com.br [mailto:lista-bounces em firebase.com.br] Em
> > nome de Arlei Ferreira Farnetani Junior
> > Enviada em: domingo, 24 de agosto de 2008 23:46
> > Para: FireBase
> > Assunto: [firebase-br] 1.500 bancos FB ao mesmo tempo c/10 usuários via web
> >
> > 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
Mais detalhes sobre a lista de discussão lista