[SP-pm] DBIx::Class

Alceu Rodrigues de Freitas Junior glasswalk3r at yahoo.com.br
Mon Sep 16 15:18:46 PDT 2013


Em 16-09-2013 15:51, Eden Cardim escreveu:
>>>>>> "Alceu" == Alceu R de Freitas <glasswalk3r at yahoo.com.br> writes:
>
>      Alceu> Quem precisa reler com mais atenção é você: se você critica
>      Alceu> que usar stored procedures é uma otimização prematura e
>      Alceu> depois muda de ideia... bem, decida-se.
>
> Ok, vamos pro "be-a-bá", olha o aviãzinho! Seguinte:

Eden,

Primeiramente, você devia parar de usar cuecas apertadas: as pessoas vão 
gostar mais de você.

Eu conheço o Solli (na medida do que é possível conhecer por participar 
em eventos sociais comuns) então acho que ele já fez todo o racional que 
você colocou aqui antes de postar para a lista. Vamos em frente agora...

> 1 - Usar SPs como implementação inicial de uma funcionalidade de
> cadastro é uma otimização prematura. Os motivos são:
> 1.1 - SPs raramente são portáveis entre implementações de backend.
> 1.2 - SPs aumentam a quantidade de trabalho envolvido no deploy
> do banco de dados.
> 1.3 - SPs significam mais partes móveis, o que significa que mais
> pontos de integração precisam ser testados.
> 1.4 - SPs podem sim ser mais lentas do que select+insert porque a
> depender do caso, você precisa preservar locks durante a SP inteira e
> o backend não tem como otimizar pra você, então é melhor que você seja
> *muito bom* se for seguir esse caminho.

Concordo com todos os pontos, exceto o 1.4: DBI e DBIx::Class vão estar 
sujeitos ao mesmo problema. Eu não manjo muito de stored procedures em 
outros bancos, mas no Oracle consigo ter controle granular de transação, 
então não vejo este problema que você levanta.

> Bom, agora que revisamos o *básico*, vamos pra segunda parte:

Que bom que você se deu ao trabalho de ajudar os monges mais novos! É 
muito chato quando você escreve respostas achando que todos devem 
concordar com você sem um racional!

"In God we thrust: all others must bring data".

> 2 - *se* (repito: *se*, condicional, ramificação) for constatado que
> uma SP for de fato necessária como otimização (e repito, sãos raros os
> casos) somente aí você sobrecarrega as partes relevantes das classes
> envolvidas e chama a tua SP lindamente otimizada, mas só no ponto em
> que estiver lento, não precisa arrancar o DBIx::Class inteiro.

Eu não me lembro de ter dito para arrancar o DBIx::Class inteiro... onde 
foi que eu escrevi isto mesmo?

> Bom, se não houvesse um motivo simples pra ignorar essa recomendação,
> eu explicaria as outras desvantagens. O motivo simples é que um cache
> como o memcached não é necessário pelo fato de que qualquer kernel
> lançado a partir da década de 90 faz page caching pra você e faz de
> uma forma muito mais eficiente que o memcached faria. O kernel pode
> fazer isso porque ele tem acesso transacional a todos os pontos de
> entrada e saída de dados do sistema. O memcached não tem.

Cache != Memcached

Eu sei que todo mundo gosta do Memcached e acha bonito (eu incluso) mas 
para ter/usar cache existem N estratégias disponíveis...

> Novamente, um banco de dados pode fazer isso *internamente* porque ele
> tem acesso transacional a todos os dados do banco, o memcached não
> tem. E sim, os dados de um cache qualquer são *todos* transientes
> porque a hierarquia de memória proíbe que *todos* os dados sejam
> armazenados no cache: o custo é proibitivo. Logo, se a demanda
> imediatata do sistema é por um volume de dados que ocupe todo o cache
> disponível e que não sejam as siglas de UF, essas siglas vão
> desaparecer do cache até que sejam requisitadas novamente.

Não entendi muito bem, mas acho que não quero perguntar mais...

> O problema é que se você tem um banco de dados que precisa ser
> otimizado via cache externo, é bem provável que os registros de
> cadastro não caibam todos na memória. O memcached não pode fazer isso
> porque ele não tem acesso transacional (repetindo pra garantir que
> leram dessa vez).

Você deve ter razão... ou não! Versões mais recentes do MySQL já te dão 
opção de instalar ele junto com o Memcached. Deve ser para evitar 
acessar o banco de dados em situações como UF.

> Falácia do espantalho? Isso é um cenário completamente diferente do
> que está sendo discutido. A questão é que a *chave* ser única não te
> salva de ter que fazer uma consulta antes de tentar inserir uma
> duplicata. E nesse discussão específica, essa chave não é composta: é
> o email.

Não, eu não lembrava mesmo do e-mail original do Solli. Fiquei com 
preguiça de procurar também. Mas realmente não te salva de fazer a 
consulta, exceto claro, se você capturar a exceção que o banco vai gerar 
quando tentar inserir o e-mail de novo.

> Você está ignorando os contra-pontos que já foram expostos na thread
> antes, vou sintetizar aqui pra você (e pela última vez):

Não, eu não ignorei e comentei todos na medida do possível. A diferença 
é que eu não uso cuecas apertadas.

> Consultar antes do insert:
>
> 1 - é trivial

É mesmo!

> 2 - é rápido (tanto a implementação quanto a execução, assumindo o uso
> de um banco de dados razoável)

É rápido... comparado ao que? A capturar uma exceção?

> 3 - é portável

Se eu usar ANSI SQL. E se o banco que decidir usar suportar o ANSI SQL 
(acho que todos suportam, mas enfim).

> 4 - é simples de ler (select email from tabela where email = 'foo at bar.com'
> é a primeira coisa que se aprende em qualquer curso vagabundo de SQL)

É mesmo! Inclusive o resultado desta query poderia ser guardado no seu 
cache favorito para evitar ter que ir até o banco de dados, atravessando 
todas as camadas do DBIx::Class até o motor do BD.

> Um mecanismo de excessões:
>
> 1 - Não é tão rápido assim (a resolução da pilha é particularmente
> lenta, em qualquer linguagem)

Tem alguma referência que mostre isto? Eu não tenho a menor ideia mas 
gostaria de entender melhor.

Pensando melhor, deixa para lá. Eu vou no Google mesmo.

> 2 - Não é portável (cada banco de dados tem seus próprios códigos de
> erro)

Realmente.

> 3 - Não é trivial (requer conhecimento específico de todas as engines
> de banco de dados envolvidos e requer um mecanismo de excessões
> bem-planejado e funcional)

Idem.

> Não tem *nada* a favor das excessões nesse caso, exceto pra quem nunca
> programou em nada além de java a vida inteira, aí *talvez* faça sentido.

Isso é um pouco de ranço, não? Exceções é algo que sinto bastante falta 
no Perl simplesmente porque lidar com $@ é meio que um saco.

C# também usa. Python também.

Conclusões sobre esta thread:

1 - É difícil ter desempenho superior sem sacrificar alguma coisa, como 
abstração ao banco de dados. Geralmente uma solução híbrida funciona 
melhor do que tentar procurar pela bala da prata.
2 - Não quero mais saber desta thread. O Solli que "se vire", vou ler a 
thread sobre "o melhor dos melhores do mundo" que está mais divertida.

[]'s
Alceu


More information about the SaoPaulo-pm mailing list