Le 2011-O-16 19h55, Bruno Silva a écrit :
>
> E seguindo essa premissa vou a outro ponto, que a meu ver é um dos
> grandes pontos para os NoSQL terem uma performance razoável é o fato
> de que ele não permite ao Desenvolvedor/Programador, como direi, fazer
> as consultas da forma que bem entender, todas as chamadas são feitas
> através de API's disponibilizadas pelo próprio MongoDB, o que evita
> consultas mal escritas e força a utilização dos recursos do banco.
Ahn… na verdade, a questão é outra.
Em todos os sistemas prerrelacionais, inclusive os da moda NoSQL atual
— nas últimas três décadas isso já se chamou de modelo hierárquico, de
redes ou de grafos; multivalorado; BDOO e vai por aí afora, cada poucos
anos isso morre e ressuscita com outro nome — não existe o que chamamos
de independência de dados. Ou seja, o modelo lógico e o modelo físico
estão amarrados, porque não existe um modelo conceitual de dados que
independa dos detalhes de implementação.
Isso faz com que o desempenho esteja amarrado à adequação do modelo de
dados físico e da programação à combinação entre aplicação principal e
tecnologia. Mude a tecnologia (em menor grau) ou, principalmente, a
aplicação, e corre-se o risco de ter de mudar o modelo de dados e,
conseqüentemente, a programação.
Já no SQL, apesar de várias limitações arbitrárias em relação ao modelo
relacional, o DBA tem várias possibilidades de ajustar o comportamento
físico e até o modelo físico para se ajustar a novas necessidades, tanto
de mudança tecnológica quanto de mudanças no modelo de dados e no
comportamento do sistema, para tirar o máximo possível em termos de
desempenho sem comprometer a integridade dos dados.
Por exemplo, se muda a escala de dados, as estatísticas coletadas
automaticamente pelo sistema vai fazer com que mudem, automaticamente
também, os planos de execução, que são compilados automaticamente pelo
planejador (vulgo ‘otimizador’). O mesmo acontece quando muda a
tecnologia — por exemplo, a proporção entre o custo de uma busca
seqüencial ou de uma busca aleatória, ou a quantidade de memória — e o
DBA tem apenas de ajustar parâmetros do SGBD ou dos espaços de tabelas
(/tablespaces/).
Já nos sistemas prerrelacionais como os ditos NoSQL, mudou algo? Muda
a programação, quase que inevitavelmente.
> E lembrei que uma vez um DBA Oracle comentava que não adiantava se ter
> um Oracle se você não utilizar os recursos do banco, no caso ele não
> se referia a Archive Logs ou outros, ele falava de Stored's e afins.
Hm… imagino que queiras dizer programação procedural em PL/SQL. Na
verdade, isso depõe contra o Oracle, que tem apenas uma linguagem
proprietária para programar procedimentos armazenados, em vez de
implementar o ISO SQL/PSM. No caso do PostgreSQL, além de termos uma
versão do PL/SQL chamada PL/PgSQL, temos a ISO SQL/PSM e toda uma
variedade de outras linguagens disponíveis.
Outra coisa que depõe contra o Oracle é que várias vezes se usam
procedimentos armazenados e outras técnicas não declarativas, como
/hints/ (dicas dadas pelo programador para forçar um caminho de
execução) para contornar deficiências do SGBD. No PostgreSQL,
procura-se aperfeiçoar o comportamento do planejador e incrementar o
suporte à modelagem, ou seja, à programação declarativa. Ainda faltam
muitas coisas para se aproximar do ideal relacional, e o SQL em si
atrapalha ao violar o modelo, mas é uma abordagem muito mais sã.
> Então se o NoSQL obriga ao desenvolvedor usar os recursos do mesmo,
> ele tende a ter uma performance melhor.
Na verdade, não. Ele tem um desempenho /adequado/, não /melhor/, se e
quando o programador consegue, no projeto, ter uma visão adequada tanto
do comportamento das aplicações quanto da arquitetura do sistema. Isso,
normalmente, só acontece numa reescrita dum sistema que já alcançou os
limites da primeira (ou segunda) implementação, ou seja, por fracassos
anteriores. Geralmente quando se usa MySQL (que não escala sem cirurgia
interna) ou algum SGBD proprietário (que é muito caro para escalar).
A ironia é que, se o sistema começou com PostgreSQL, normalmente não
precisaria reescrever, poder-se-ia simplesmente ir ajustando a
arquitetura, possivelmente usando até tecnologias de implementação
normalmente associadas a sistemas prerrelacionais como os NoSQL, como
por exemplo índices invertidos (GIN e GIST), tipos extendidos pelo
usuário (CREATE TYPE) ou até mapear e reduzir.
Se um sistema não está escalando em SQL, pode até ser por causa de uma
das várias limitações impostas pelo SQL em relação ao modelo relacional
— caso em que poder-se-ia justificar o uso dum modelo prerrelacional —,
mas normalmente é por más decisões arquiteturais, como uso de MySQL ou
de SGBDs proprietários (que custam caro para escalar), falta de uso dos
recursos do sistema (uso indiscriminado de servidores de aplicação e
[ou] ORM, uso de tipos restrito aos predefinidos &c.), ou, o caso mais
comum, modelagem inadequada, por exemplo sem normalização avançada
(vulgo ‘desnormalização’, geralmente precoce), sem declaração de chaves
naturais &c.
--
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191 gTalk: xmpp:[email protected]
+55 (11) 9406 7191 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
