Le mer. 15 févr. 2017 à 16:16, Luiz Carlos L. Nogueira Jr.
<[email protected]> a écrit :
Gostaria que minha aplicação apontasse pra um IP/porta e o Cluster
fizesse um balanceamento de carga e distribuisse entre os servidores
(nós) onde estão os bancos .
Quando os servidores de banco estivessem topados, poderia colocar
mais uma máquina para distribuir melhor o processamento.
Seria uma solução parecida com que a Oracle oferece (RAC)
A aplicação abstrairia de como o banco está (standalone ou vários
nós de banco). o importante pra ela seria um IP/Porta para conexão.
Luís, esse é o problema do fechamento cognitivo precoce.
Trocando em miúdos, você diz o que quer fazer, e explica os porquês
genericamente; não diz exatamente os detalhes de que problemas quer
resolver, e porquê descartou outras alternativas.
Por exemplo, o Oracle RAC é conhecido por causar mais problemas do
que resolve na grande maioria dos casos; casos em que as soluções
verdadeiras estão noutros aspectos do sistema, desde modelagem de
dados até gestão de risco, passando por perfis de execução de
aplicação, análise de planos de execução, planejamento de
capacidade, monitoramento &c.
Infelizmente, a Oracle e vários jornalistas especializados, para não
falar de bloqueiros e pitaqueiros em geral, vendem determinadas
arquiteturas de sistema como panacéias, o que engana muitos usuários
a crerem que basta comprar ou implementar algo, sem jamais entender
requisitos, situações, limitações, funcionamento &c.
Veja também que o RAC não se encaixa perfeitamente em tua
descrição; o RAC trabalha com E/S centralizado, sendo que geralmente
o gargalo é justamente E/S. Ou seja, o RAC não é verdadeiramente
distribuído, no sentido de que não particiona nem replica
informações, mas depende de uma única unidade de armazenamento
centralizada. Em outras palavras, o RAC será útil mais quando o
gargalo for processamento (CPU) ou memória, casos em que geralmente
há soluções mais baratas e mais simples, desde otimização do
modelo e dos programas aplicativos até servidores mais parrudos; e,
sendo mais simples, mais confiáveis.
Na prática, nunca vi uma questão dessas se resolver por lista de
discussões; sempre é algo que se resolve ou por aprendizado e
experiência do usuário, que eventualmente aprende a analisar o
sistema como um todo (desde infraestutura até interface de usuário),
ou mais freqüentemene com consultoria local, em que o prestador de
serviço tem condições de levantar todas as informações
necessárias.
A vantagem do PostgreSQL especificamente, e de sistemas livres em
geral, é termos implementação livre ou pelo menos gratuita de
várias dessas ‘soluções’ comumente propostas, o que permite ao
usuário instalá-las e aprender ‘chutando os pneus‘, o que não é
ideal mas é sempre um aprendizado útil, e por vezes necessário;
nesse sentido, veja se o PosgreSQL XL não é o que você queria.
--
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191 gTalk: xmpp:[email protected]
+55 (61) 9 9302 2691 ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT−3 MSN: msnim:[email protected]
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
