2015-12-03 14:42 GMT-02:00 Mauricio Tavares <mfx1...@gmail.com>:
>
> Quanto falei "ganbiarra" (note as aspas) não foi para desmerecer os esforços
> da comunidade em criar melhorias para um banco que já fornece muitos
> recursos avançados. (muitos já evidenciados aqui na lista).  Mas foi para
> evidenciar que tais modificações foram implementadas para suprir uma
> necessidade que outros bancos de dados já fornecem nativamente.

Mas então o termo não é esse.  Colocar entre aspas não nos diz
exatamente o que você quis dizer.

E outra: quando o PostgreSQL implementa algo, não vende para casos
inadequados, e oferece alta qualidade.  Só uma comparação: leia o
artigo ‘You don’t need RAC’ (ou algo assim) da Oak table network, e
compare a lista de defeitos (/bugs/) conhecidos do PostgreSQL com a de
outros SGBDs, livres ou proprietários, SQL ou prerrelacionais (‘NoSQL’
&c).


> Uma coisa que me chamou a atenção no postgres XC, foi a versão do Postgres é
> a 9.1. uma versão relativamente antiga visto que já estamos na versão 9.4.
> Ressalto que, confio na versão 9.1.

E se você ler o que a equipe do XC publicou a respeito, ou mesmo
outros projetos com abordagens parecidas, como a do PostGIS (em menor
grau), verás que o atraso é proposital, faz parte do processo.

De novo, é uma necessidade de nicho, e um grande aumento de
complexidade num projeto que hoje tem zero defeitos conhecidos.
Devagar com o andor… que deste lado do paraíso funcional, o santo é de
barro.


> O órgão onde trabalho possui muitos servidores (uns virtuais, outros
> físicos) com bases de dados pequenas. Visando um melhor aproveitamentos dos
> recursos disponíveis na infraestrutura, foi cogitado em montar uma  "Base
> Única de Dados", e agrupar todas estas pequenas bases de dados nesta base
> única.  Inicialmente seriam entre 3 a 5 nós de servidores. É por isto a
> necessidade do multi-master.

Multimestre (BD distribuído) me parece uma solução completamente
equivocada, pelo menos tomando por base essa descrição para lá de
sucinta.

Vejamos.  Hoje são bases distintas.  Por que unificá-las implicaria em
ter vários mestres?  Por que não poderia ser de um a cinco mestres com
quantas réplicas forem necessárias?  Porque não podem ser até cinco
bases se comunicando entre si?

Veja que o uso de réplicas tem dois benefícios: além de alta
disponibilidade e recuperação, também podem receber muitas consultas
para aliviar os servidores principais.


> Bem, o cenário é este.... E evidentemente estou aberto a sugestões  de uma
> arquitetura diferente a multi-master. Entretanto, precisarei de apoio dos
> Srs. para ter argumentos técnicos para discutir dais propostas com a equipe
> de infra, visto que é ela que está batendo o pé em ter tal ambiente
> multi-serve.

O principal argumento é a falta de necessidade.  Pelo menos em sua
mensagem, não encontrei argumentos demonstrando a necessidade de BD
distribuída, muito menos demonstração da consideração (e descarte) de
alternativas.


-- 
skype:leandro.gfc.dutra?chat      Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191              gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691        ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a