Pablo Sánchez escreveu:
> Em 25 de fevereiro de 2010 20:42, Euler Taveira de Oliveira
> <[email protected]> escreveu:

[corte]

> O do PostgreSQL ainda está com muitas arestas (mandei o texto do
> próprio manual mais cedo).
> 
É verdade. Está na minha lista de afazeres mas a prioridade anda meio baixa.
Talvez se surgir algum cliente interessado...

> Não duvido nada disso. Aliás, pelo que pude ver, realmente é uma
> excelente idéia, resolverá várias questões, até eliminará a
> necessidade de extensões como o DBLink, mas não passa disso: uma
> implementação similar ao DBLink. Continuamos com apenas um master, e a
> carga de processamento não é distribuído, mas multiplicada entre as
> diversas fontes acessadas pelo master.
> 
É claro que o processamento pode ser distribuído. Considere um SGBD com duas
tabelas estrangeiras (aka foreign tables) de um outro nó. Uma junção dessas
duas tabelas irá transferir o processamento para o outro nó. O papel do mestre
será somente acessar o outro nó e depois repassar os dados retornados.

>> Além disso, o que poucos enxergam é que no caso dos nós serem PostgreSQL
>> podemos ter heurísticas no planejador para decidir para onde direcionar as
>> consultas.
> 
É não são todos que enxergam...

> Novamente: SQL/MED não é distribuição dos mesmos dados por diversos
> nós, mas acesso de diversos dados por um único nó. O restante, não
> passa de replicação.
> 
É fato que o SQL/MED proporciona: agregação de dados de fontes distintas (ou
como você prefere dizer, distribuição dos dados em diversas fontes), mas o que
eu estou querendo dizer é que isso de uma certa forma trás consigo uma certa
escalabilidade horizontal.

Eu não quero entrar na discussão de BDs distribuídos aqui mas...

Esse conceito de consistência eventual (como o utilizado nessas soluções
NoSQL) já é antigo e, de certa forma, prega o oposto das propriedades ACID.

É claro que a solução tem o seu mérito (você precisa escalar sem dar muito
valor aos dados armazenados) mas isso já está disponível a um bom tempo em
SGBDs relacionais (vide replicação multi-mestre assíncrona).

Por fim, o grande diferencial dessas soluções NoSQL é com relação ao *modelo*
(não utilizam o modelo relacional).


-- 
  Euler Taveira de Oliveira
  http://www.timbira.com/
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a