Esta thread está ficando agradavelmente construtiva! >> 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…
E olha que, neste caso, nem estou falando d*o* case do milênio :) Nele o banco de dados é praticamente um "saco de dados". > 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. Esse sistema que estou falando foi feito em C, tudo CGI, não tem ORM e praticamente funciona assim: Aplicação em C: oi usuário, o que você quer fazer agora? Usuário: quero cadastrar uma pessoa. Aplicação em C: taqui o formulário pra você preencher. É só clicar o botão Ok no final, tá? Usuário preenche os dados e clica no Ok. Aplicação: ok usuário! vou mandar seus dados pro SGBD. Aplicação: SGBD, por favor, aqui estão os dados do cadastro: "SELECT cadastra_formulario(dados, dados, dados, dados,.... muitos dados,...);" E o SGBD: Cata os dados, valida input, trata strings, verifica consistência em todas as tabelas relacionadas, insere cada pedaço do formulário em 10 tabelas diferentes, atualiza a tabela de histórico, computa sequências, atualiza índices, checa as restrições locais e estrangeiras e "comita tudo. SGBD: Aplicação, "COMMIT". Aplicação: Obrigado SGBD. Usuário, Ok! Usuário esquece a tela aberta, ainda por cima. Agora imagina que: - o modelo de dados é bem elaborado, acadêmico _mesmo_; - usa-se pl/pgsql puro, sem outros wrappers para outras linguagens; - os índices são extremamente enxutos e _todos_ foram verificados junto às consultas. Aí a aplicação, tadinha, ela sofre tanto... deram três servidores parrudos só pra ela. O SGBD, ah, esse desgraçado! Tá comendo uma máquina inteira sozinho, humpf! Agora no duro: se a parte toda de validação de input e tratamento de strings fosse na aplicação, a aplicação abrisse uma transação com o banco e resolvesse sua vida, o processamento de cada passo no pl/pgsql poderia muito bem ser dela, distribuindo bem melhor a carga entre seus três servidores. > 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 Olha, neste caso eu tive acesso a tudo. Cada tabela, índice e procedure. Tudo muito bem escrito, juro, acadêmico. > 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. Vamos então nomear melhor os bois: a regra tem que estar no SGBD sim, ok. Restrições, regras e etc. Mas o processamento das informações _antes_ de chegar no SGBD, isso não deveria estar com ele. E, neste caso, está. >> 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. Note que o gargalo nesta aplicação que estou citando *não* é disco. O throughput nem é tão alto assim, a quantidade de WAL que é gerada lá é menos da metade do que o tal "case do milênio", tá tudo monitorado e o storage tá... coçando. Consegui bom ganho limitando bem o uso de conexões ao PostgreSQL com um pool usando o pgbouncer muito bem configurado. >> 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. O agora Microsoft Skype tem um excelente caso de sucesso justamente separando tudo: chamada remota de função com o plproxy é um sucesso. E, juro, mandei estudo disso para o cliente. Era só modificar 70 funções em pl/pgsql e a aplicação toda, mas ia ficar "da hora". O custo foi proibitivo e ameaçaram trocar pelo RAC se fossem gastar a grana toda :P > 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? Como falei acima, tô contigo na questão regra de negócio. O problema é o processamento do negócio. IMHO, deve estar fora do SGBD. > 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 PostgreSQL é a melhor implementação da ISO, reconhecido e utilizado academicamente por isso. E olha que a comunidade não tem dinheiro pra ficar comprando norma. Aliás, norma, do jeito como é no nosso mundo, na minha opinião, é só um jeito de ganhar dinheiro com patent war. > 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. Existem sim. Os integrantes dessas equipes se chamam nerds. E eles estão em alta no mercado de trabalho e até na vida afetiva. Claro que tem que ter um balanço: nerdice versus praticidade. Não acho que o mundo deva ser 100% nerd pra fazer as coisas em TI. Ninguém ganharia dinheiro. Eu proponho um balanço: bem feito na medida, tem que ser bem feito mas tem que ser prático ou não vai pra frente. > 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. Vou te contar algo que vai te deixar bem chateado. A maioria das aplicações Java EE usando Hibernate, normalmente, são independentes de SGBD. Tendo o driver JDBC correto, elas falam o "dialeto" adequado. Mas aí cai na discussão do ORM de novo e tal... Então, onde é que estamos errando: o Hibernate é tão ruim assim? Ou será que as implementações de bancos de dados é que são completamente confusas? Ou as duas alternativas? Porque é tão difícil levar para o mundo dos objetos o modelo relacional ou o modelo objeto-relacional do PostgreSQL? > Será que é muita ingenuidade minha achar que linguagem procedural costuma ser > antítese de escalabilidade? SQL é declarativo, em primeiro lugar, em que pese Não chega a ser uma antítese, mas é um dificultador enorme. Como tudo pode ser reescrito, então, é possível, com muito esforço e dinheiro, fazer uma aplicação escalar. E aqui a Oracle e IBM tem posto muito muito dinheiro, que a comunidade PostgreSQL está esforçada em atingir com os recursos que tem. > 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… Esta discussão dá uma bela palestra! Sim, e é aí que alguns de nós tem sobrevivido com consultoria: entendendo o contexto, conjunto da obra. > Pega que é tua, Rangel. Destrói aí. Aguardo sequência sua! []s Flavio _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
