2011/6/29 Flavio Henrique Araque Gurgel <fha...@gmail.com>:
>
> Meus dois centavos nesta discussão vão na direção contrária.
Vou discordar, correndo o risco de parecer ridículo — afinal, tu representas
*o* caso de PostgreSQL do milênio…
> - A idéia é péssima no sentido contrário: a aplicação tem centenas de
> milhares de usuários e funciona em escala nacional. Como toda a regra
> de negócio está no banco, o consumo de CPU é altíssimo, batendo em
> 100% em máquinas bastante parrudas.
Claro que não tenho como questionar, não tenho informações suficientes nem, no
momento, quero ter… mas essa é uma questão interessante. Regras de negócio
causando uso total de processadores no servidor de bases de dados, na minha
experiência e na lógica que chego a alcançar, costuma indicar problemas de
codificação, principalmente por uso de modelos de programação descasados com o
modelo relacional, como o navigacional e o POG: respectivamente, tipicamente
representados pelos clipeiros e pelo Hibernate, claro que nem de longe
exclusiva, embora talvez majoritariamente.
A outra grande causa de uso exagerado de recursos computacionais pelas
regras de negócio costuma ser má modelagem, de novo por falta de entendimento
do modelo relacional. Por exemplo, a famigerada ‘desnormalização’, o uso
indiscriminado de chaves artificiais, a falta de uso dos tipos definidos por
usuário (tipos ‘abstratos’ de dados) &c.
Claro que, muitas vezes, o pobre do DBA, que deveria receber adicional
de insalubridade por ser, na prática, gari de curva de rio, não tem como
garantir nem o modelo, nem a qualidade da programação. Mas creio que vale a
pena mencionar para que não fique parecendo que a ‘culpa’ é da garantia das
regras de negócio no SGBD. Isso deveria ser um requisito conceitual absoluto,
embora nem sempre o SQL facilite e quase nunca a organização tenha competência
(ou as famosas ‘condições objetivas’) para alcançar.
> Quando é necessário aumentar a escala de atendimento, é necessário colocar
> máquina mais poderosa.
Hm, quando armazenamento de massa em memória /flash/ se tornar mais lugar
comum, conquistar nossa confiança, for bem aproveitada por nossos sistemas de
arquivos… quem sabe consigamos implementar os conceitos do saudoso (em parte)
/mainframe/, como as hierarquias de memórias e armazenamento.
> Isso depois de muito tuning e uso de PostgreSQL 9 onde a parte de BI e
> relatórios com consultas mais complicadas são feitas em servidor
> hot-standby.
Até aí, seguindo as regras, né? Morreu o Neves, quem faz diferente é quem tem
de se explicar…
> Para escalar horizontalmente esse ambiente, só há uma forma: modificar
> toda a estrutura do banco quando estiver disponível totalmente a
> implementação de SQL-MED, pra poder fazer com mais facilidade o uso de
> dados remotos e separar fisicamente tabelas por regiões ou estados.
Experiência com Oracle em telecom (operadoras de telefonia fixa & celular):
mesmo uma implementação meia‐boca e mal compreendida, como é a da Oracle, pode
trazer grandes ganhos. No caso, tínhamos as tabelas ditas ‘de referência’ em
pequenos servidores localizados juntos a setores administrativos, de
atendimento ao usuário &c, que salvavam a pele dos programas aplicativos
cliente‐servidor. Está certo que eu, particularmente, não ‘acredito’ nem em
cliente‐servidor nem em nenhum papai‐noel da vida, mas às vezes tem‐se de
fazer malabarismo para impedir que o estrume alcance o proverbial ventilador…
> Se a regra de negócio estivesse na camada de aplicação, seria possível
> dividir dados usando alguma técnica de sharding com mais facilidade e
> menos alterações em código.
Sim, com a tecnologia atual, sim. Pelo pouco que entendo do SQL‐MED, nem ele
chega a implementar de verdade um SGBDDistribuídas. Idealmente, poderíamos
programar, digamos, em SQL/PSM ou PL/Scheme ou o que bem entendêssemos, e
deslocar o código transparentemente entre servidores. Mesmo assim, a minha
expectativa seria de que, freqüentemente, descobriríamos que as regras de
negócio teriam melhor desempenho junto da base, por evitarem latências
decorrentes de mudanças de contexto, transferências de dados pela rede &c.
> Minha dica para novos sistemas é sempre assim:
> - regra de negócio sempre numa camada fora do banco de dados;
> - llinguagens procedurais devem e podem ser utilizadas, mas de forma
> restrita para as funcionalidades de banco de dados (ex.:
> particionamento, regras para suprir restrições, validação de dados não
> possíveis por restrições, etc);
Pois é, mas se considerarmos que todas as regras de negócios devem ser
implementadas como restrições, de preferência declarativas, fica contraditório
ter isso fora da base, não? Ou minha lógica falhou nalgum ponto que não
alcancei?
Sim, claro, o SQL não é relacional, isso impõe restrições e tudo o
mais… mas o PostgreSQL, particularmente, é suficientemente próximo do ISO
SQL:2008, e até do modelo relacional, para o desenvolvimento de um novo
sistema aplicativo por uma equipe competente com requisitos claros, completos
e estáveis ser viável sem grandes gambiarras… claro, se existissem equipes
competentes com requisitos claros, completos e estáveis no mundo real.
> - camada de apresentação separada da camada de aplicação.
Como manda o mítico manual que está no céu, no divino Braço Direito do
Criador… sem ironia.
> Assim suprem-se as técnicas MVC modernas e ganha-se em portabilidade
> (fica mais fácil migrar de SGBD ou misturar SGBDs)
Na minha opinião — e constato, aliviado, que na opinião de pelo menos dois ou
três profiças muito mais inteligentes, experientes e bem informados que eu —
portabilidade total, dado que o SQL não é relacional e é muito mal
implementado no mundo extraelefantíaco, é um mito, cuja busca tipicamente
resulta em sistemas que nem são portáveis, nem corretos, nem manteníveis (eita
palavriña orroroza, alguém tem alguma melhor?), nem escaláveis, nem sequer
portáveis… eu ia dar o exemplo do Propvs μiga, mas aí é chutar cão defunto.
> e escalabilidade (usar linguagem procedural para movimentar dados de forma
> independente da aplicação).
Será que é muita ingenuidade minha achar que linguagem procedural costuma ser
antítese de escalabilidade? SQL é declarativo, em primeiro lugar, em que pese
a conveniência de se ter o SQL/PSM e alternativas para suprir as deficiências
do SQL declarativo… e também acho ‘engraçada’, por assim dizer, essa divisão
entre base, movimentação de dados, e aplicação. Desempenho, disponibilidade,
escalabilidade, responsividade sempre teriam de ser avaliadas no conjunto…
Pega que é tua, Rangel. Destrói aí.
--
Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org
+55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803
sip:leand...@iptel.org 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
