Em 25 de fevereiro de 2010 20:42, Euler Taveira de Oliveira <[email protected]> escreveu: > Pablo Sánchez escreveu: >> Poderia me dizer quais bancos já suportam SQL/MED em nível de >> produção? (experimentos sobre um padrão que já tem 7 anos não contam >> muito). >> > DB2. Mas tem outros SGBDs que já tem algumas coisas como o PostgreSQL.
O do PostgreSQL ainda está com muitas arestas (mandei o texto do próprio manual mais cedo). Legal o DB2, eu ainda não tive a oportunidade de utilizá-lo, e meu tempo de estudo "por diversão" anda meio devagar... >> De qualquer forma, em que SQL/MED se compara a NoSQL? >> > Você leu o que eu disse acima: escalabilidade horizontal. Sim, li, mas o conceito que encontrei não me pareceu similar a escalabilidade, está mais para para uma distribuição horizontal dos dados, que continuam centralizados em um ponto apenas, não é um sistema distribuído, mas um monte de fontes distribuídas. As requisições ainda tem que passar por um único master. Você pode até colocar vários master para cada fonte de dados distinta, mas ainda assim, na hora de cruzar as informações, passa por um master. A proposta de banco NoSQL é justamente trabalhar com cloud computing, e a proposta dos SGDBs disponíveis ainda é trabalhar com um único master e vários slaves para replicação. > E por fonte de dados externa podemos incluir o *PostgreSQL* e qualquer outra > fonte de dados (XML, JSON, CSV, MySQL, DB2, etc) . SQL/MED é um modelo > ambicioso. Sim, é, mas acho que está ocorrendo uma confusão nos conceitos. > Distribuir a carga de uma consulta para múltiplos nós em que até > mesmo esses nós possam ter modelos de dados diferentes. Sim, mas mesmo assim, ainda passam por um master... Para você mesclar as fontes de dados em uma consulta, eles ainda passarão por um único master. O master trás os dados de múltiplas fontes, mas isso não é distribuição de carga por nós. Não é o mesmo conceito. Na verdade, nesse aspecto me parece até pior, porque além de eu ter que solicitar ao master, ele vai solicitar a várias fontes ao mesmo tempo, criar um bottleneck nas interfaces de rede do servidor, pois para que ele possa cruzar as informações ele terá que ter acesso a elas, e gerar a carga ainda na fonte de dados. Um SGDB que precisa consultar outros 3 SGDBs para obter a informação não é um uso inteligente dos recursos disponíveis. Claro, resolve uma série de problemas, como a integração entre fontes de dados distintas, mas o processamento é realizado por todos os nós envolvidos, e só o master está respondendo no final. A idéia com o Cassandra, especificamente, é outra, é justamente não fazer isso. Não há, diretamente, no modelo proposto pelo SQL/MED, um balanceamento de carga, e os dados não estão disponíveis em todos os nós ao mesmo tempo. Essa é a grande diferença do Cassandra. Mesclar fontes de dados é completamente diferente de ter uma mesma fonte de dados distribuída por vários computadores. > Há muita pesquisa em > cima dessas idéias na área de banco de dados hoje. 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. > 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. 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. -- ================================= Pablo Santiago Sánchez Análise e Desenvolvimento de Sistemas Web Zend Certified Engineer #ZEND006757 [email protected] (61) 9975-0883 http://www.sansis.com.br http://www.corephp.com.br "Quidquid latine dictum sit, altum viditur" ================================= _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
