Le jeudi 04 janvier 2018 à 09:35 -0200, Fábio Telles Rodriguez a
écrit :
> …escalar horizontalmente um banco de dados dá muito mais trabalho do
> que escalar um servidor de aplicação. Se você tiver muitas regras de
> negócio no seu banco de dados, vai concentrar uma parte maior do
> processamento no servidor de banco de dados e menos no servidor de
> aplicação. Quando você acaba de implantar um sistema novo, está tudo
> tranquilo. Quando o tamanho da base e o número de usuários crescer,
> você vai precisar escalar esse banco de dados. E se a sua regra de
> negócio está concentrada no banco de dados, isso vai acontecer bem
> mais cedo do que o normal. O resultado é ter que trabalhar com
> replicação, cluster, particionamento e outras coisas relativamente
> complexas.
>
> Claro que em alguns casos colocar a regra de negócio no banco de
> dados ajuda. Para validações complexas, operações em lote e rotinas
> que exigem uma segurança maior no acesso aos dados, fazer tudo em PL
> dentro do bancos ajuda muito. Muito mesmo. Mas se você exagerar, pode
> ficar com um gargalo de CPU que vai lhe custar muito caro.
Perdoem a ampla citação do Teles, mas é que tenho de lidar com vários
pontos dela.
Vejam que o pressuposto acima é que o gargalo será CPU de PLs
(PL/PgSQL, PL/Python, PL/Java, PL/PSM &c).
Entretanto, quando falei de colocar as regras na base tentei
deixar claro não ser essa a idéia.
O ideal seria ter o máximo de regras de negócio
declarativamente, na forma de restrições de integridade (tipos,
chaves…); se não der declarativamente, na forma de restrições de
verificação (CHECK CONSTRAINT); só em último caso recorrer-se-ia a
procedimentos armazenados, que esses sim carregam uma penalidade de CPU
significativa.
O que costuma acontecer é um modelo de dados acochambrado que
atrapalha o uso de restrições de integridade; o modelo em si é
ineficiente, e os procedimentos armazenados também. Mesmo assim, para
situações normais (escalas razoáveis, boa manutenção), ainda costuma
sair mais eficiente que um servidor de aplicações separado, gerando E/S
adicional com latência, por ter de validar informações na base antes de
efetivá-las. Além de que, estando na forma de restrições de
integridade, não haverá a possibilidade de programas ou usuários
contornarem o servidor de aplicações e introduzindo inconsistências na
base.
Aproveitando, quanto a ter de validar dados na entrada:
geralmente é bem mais econômico para o cliente enviar os dados à base e
lidar com eventuais exceções de restrições de integridade que validar
no cliente, pelos mesmo motivos supracitados, relativos a servidores de
aplicações.
O que realmente pode obrigar uma validação na camada de
apresentação é quando há latência significativa entre ela e a base.
Uma solução interessante era a do finado Dataphor: ele automaticamente
replicava as validações da base (no caso, um SGBD virtual, mas a idéia
era logo ter se tornado um SGBD completo, o que não ocorreu) para a
camada de apresentação, evitando inconsistências entre validações no
cliente e as restrições de integridade na base.
--
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191 gTalk: xmpp:[email protected]
+55 (61) 9302 2691 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
