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
