BMP vs CMP

Programação Arquitetura
#1

Ok, essa pode parecer super cliche.

Mas eh o seguinte: muita gente fala que eh melhor voce usar BMP que CMP, porque CMP depende da implementacao do AS. Acho esse argumento para la de furado, sem contar que voce deixa de usar a coisa mais legal do EJB, a persistencia realmente transparate (sem .saves() e tal).

Eu acho BMP 10 mil vezes pior. Voces ja fizeram alguns testes? Com BMP, o servidor nao tem garantia que, chamado um getter do seu entity bean, ele nao afetou o estado do seu bean. Isso faz com que uma quantidade ENORME de sqls sejam disparadas no seu banco de dados, e as vezes tudo repeteco:

bean.getName() gera um UPDATE blah SET name=“x”, endereco=“y” WHERE …

ai voce da:
bean.getEndereco() pode gerar um UPDATE blah SET name=“x”, endereco=“y” WHERE … DENOVO e SEM SENTIDO REAL

#2

Paulo, em que container(s) isso aconteceu?

#3

Aqui onte eu trabalho fizemos testes de desempenho e estresse ,e as aplicações usando BMP ( session + model + DAO ) obtiveram melhor desempenho
estamos usando J2EE 1.3 OC4J e Oracle9i

#4

tirando a performance,
poir para carregar um CMP, o container faz apenas uma consulta ao banco de dados

para carregar um BMP, o container faz uma consulta pararetornar as chaves primarias (findBy… ) e uma consulta para carregar cada EJB

só isto ai ja é um overhead do BMP

#5

Já ouvi muito falar que CMP é mais rápido que BMP. Durante a briga de benchmarks entre J2EE e .NET usando a PetStore como aplicação de testes, o uso de BMP foi apontado pelo Marc Fleury como motivo para a baixa performance da PetStore. Já na versão feita pela TheServerSide (uma das mais rápidas) foi usado BMP.
Alguém ai tem um comparativo de performance entre BMP x CMP? Estou interessado principalmente em relação ao Websphere.

#6

Bom galera,

acho que o ponto forte para se usar CMP hoje é sem duvida a velocidade de desenvolvimento, escrever CMP e mapear as tabelas eh sem duvida mais rapido que escrever/testar BMPs.

Agora eh complicado comparar CMP x BMP se vc soh quer uma lista de vos para apresentar na tela, sem duvida BMP eh muito mais rapido (testamos aqui, usando o jboss/Oracle, nao lembro a versao exata), porque o container nao precisa de um monte de controles.

Acho que o melhor dos mundos eh misturar os dois. Usar CMP para TODO desenvolvimento, e onde o CMP falhar como em pesquisas mais requintadas (EJB-QL eh um lixo :wink: ) ou multiplas bases de dados, utilize BMP sem duvida!

Um abraço a todos,

#7

[quote=“claudio”]

Acho que o melhor dos mundos eh misturar os dois. Usar CMP para TODO desenvolvimento, e onde o CMP falhar como em pesquisas mais requintadas (EJB-QL eh um lixo :wink: ) ou multiplas bases de dados, utilize BMP sem duvida!

Um abraço a todos,[/quote]

Mas entao. EJB-QL eh assim e tem um motivo. A ideia de EJB eh voce abstrair toda logica de negocio nele, nao ficar escrevendo Queries gigantescas e que ocultam a logica de negocios. Porque nao tem order by? Porque existe Collections.sort(), etc…

#8

Fala Paulo,

bom, concordo e discordo: :wink:

Eu acho que essa eh uma otima resposta para poder disfacar o quanto o EJB-QL eh pobre! Nao faz o minimo sentido trocar o SQL uma linguagem poderosa e estavel a muito tempo por uma linguagem de fim de semana muito pouco testada! Soh vejo vantagem na velocidade de desenvolvimento, nada mais!

As querys gigantescas existem sim, e vao continuar existindo enquanto os Databases as executarem mmmuuuuiiitttoooo mais rapido do que apps pure java!

A mistura de regras de negocio acontecem ateh mesmo com EJB-QL, mas nao quero acreditar que a falta de recursos seja de proposito para que eu nao cometa erros de design, se for entao para que arquitetos? :smiley:

Levando em consideração a outra ponta, nosso database. Vc sabe que normalmente estão em outras máquinas e etc, agora sejamos sinceros, vc prefere trazer uma lista de produtos como o da Amazon.com e ordena-las usando sort do que usar o order by implementado por alienigenas da Oracle ou da IBM por exemplo? :shock:

Sabe, acho que acontece uma tremenda confusao mesmo, tipo ateh onde ir pelo J2ee e ateh onde tirar recursos do db por exemplo.

Eu tenho uma definição muito clara disso. Na minha opinião se vc esta escrevendo um produto (como eh o meu caso agora) vc deve optar pelo mais independente possivel e mais dentro dos padroes, acredito eu que pensando em j2ee a melhor opcao nao eh (WORA) Write Once Run Anywhere, e sim (DORAFIA) Develop Once Re-implement A Few Interfaces Anywhere, essa história de fazer uma app 100% dentro dos padroes eh uma tremenda bobeira! Vc perde o que poderia ser o diferencial da sua app! Eu acho que vc deve ter uma maneira de isolar da sua app o que eh fora de padrao mas eh util para que caso onde vc for fazer deploy nao suporte vc faca um deploy diferente!

O outro caso são softwares que nao sao produtos, ou seja, vc ja conhece bem o ambiente onde irão rodar, por exemplo a TAM, todo mundo sabe que a TAM eh Oracle, eu sei que estao migrando pra java e tal, mas a ideia eh melhorar a manutencao e nao se desligar da Oracle. Logo se vc precisa comparar localidades e suas proximidades por exemplo o que vc faz?

  1. cria uma esquema baseado em coordenadas xyz para que vc consiga representar qualquer ponto do globo juntamente com um sistema que calcula a curvatura da Terra para saber a distancia exata
    2)apenas usa um tipo de dados do Oracle que ja faz isso sozinho com um simples select (com certeza tb escrito por alienigenas :smiley: )!

Logo sem duvida a discussao eh grande, mas o que vale eh o bom senso, quanto ao sort novamente o order by eh padrao no SQL ANSI, logo eu posso uza-lo sem medo de ser feliz!

[obs] Fala serio, escrevi pra caramba, pessoal nao pega mal nao eh que hoje eh segunda-feira :x ! [/obs]

Abraco,

#9

Concordo 100 % com o claudio. Em muitos casos o SQL eh bom para dedeu e inclusive indicado. Nem por isso devemos desconsiderar os CMP’s. Eu costumo escrever as minhas aplicacoes usando os dois approachs.

Nao ha duvidas que programar pensando em orientacao a objetos eh mais facil, menos complicado. Eh muito bom poder navegar entre CMR’s, pensar que uma estrutura MASTER-DETAIL seja simplesmente uma agregacao e o container cuidar dos lazy load por voce, principalmente em logicas de negocio, como atualizacao de dados.

Por outro lado , existem casos em que sql secao eh muito mais facil, dar likes, order by. Podemos tambem gerar SQL dinamicamente, pensando em uma interface que paremetros podem ou nao fazer parte do where. Nesse caso construir o SQL na mao grande eh melhor, e retornar a aplicacao um CachedResultSet, ou algo parecido (caso for paginado eh melhor soh mandar a pagina mesmo).

Prefiro programar usando o melhor de cada mundo.

#10

O sort das Collections usa o mergesort, que ja eh computacionalmente eficiente (nao da para fazer melhor baseando-se em comparacao). O sort de um order by vai se aproveitar da estrutura da barvore, se devidamente indexado naquele campo. Se for um orderby Name, que normalmente nao esta indexado, os dois sao computacionalmente de mesma velocidade.

Bem, eu acho charmosa a ideia de fazer Collections.sort() em vez de order by, nao ha como negar.

#11

Bancos de dados são feitos para operar com volumes enormes de dados, que não cabem na memoria, então a maioria é voltada a usar ordenação em disco e progressiva, ordernar conforme for necessario, oque involve toda uma gama diferentes de algoritmos.
Quick sort deixa de ser o bicho da goiaba quando se fala de ordenação em disco, normalmente se usa multi-way mergesort e bucket sort, ou mesmo bulk insertion sort quando se esta falando em ordernar enquanto se transmite. Isso quando não existe algum indice envolvido, pq ai podesse simplesmente navegar por ele.

CMP pode se mostrar inutil quando se precisa de recursos que somente SQL pode te proporcionar, como ORDER BY.
Falando nisso, passei por algo parecido a isso semana passada. Tinham detectado problema em um sistema que eu dou manutenção, de repente parava tudo e então vinha 1 pagina de 500 com Out-Of-Memory, adivinha oque era? Era em uma consulta ao catalogo de logradouros nacionais, uns 630 mil, dada 1 circunstancia o sistema carregava só TODOS registros em memoria e (tentava) ordenar eles, como o servidor é um PC 32bits, essa operação nunca vai ser completada com sucesso.

Outro caso é quando a base de dados não é um rdbms, nem segue o modelo relacional, nesse caso CMP meio que cai por agua abaixo.
Tenta usar CMP com ldap de backend? Ai voce mistura ldap-transactions no meio disso e coisa pega ainda mais…

Falando em ordenação, sinto falta de 1 std::sort() do C++ que é capaz de escolher mergesort para listas ligagas e intro/quick sort para vectors e deques sem voce precisar se preocupar.

#12

[quote=“louds”]Bancos de dados são feitos para operar com volumes enormes de dados, que não cabem na memoria, então a maioria é voltada a usar ordenação em disco e progressiva, ordernar conforme for necessario, oque involve toda uma gama diferentes de algoritmos.
Quick sort deixa de ser o bicho da goiaba quando se fala de ordenação em disco, normalmente se usa multi-way mergesort e bucket sort, ou mesmo bulk insertion sort quando se esta falando em ordernar enquanto se transmite. Isso quando não existe algum indice envolvido, pq ai podesse simplesmente navegar por ele.
[/quote]

como eu disse, mergesort eh o melhor que voce pode fazer uma ordenacao que use comparacao. Bucket sort nao usa comparacao, indice tambem nao, porque ja estava tudo la nas folhas :).

multi way mergesort e outros nao sao mais velozes, soh fazem “tricks” para ajudar na performance final, nao computacional. nenhum algoritmo de ordenacao (comparativo) eh melhor que o mergesort computacionalmente, e nao da.

[quote=“louds”]
Falando em ordenação, sinto falta de 1 std::sort() do C++ que é capaz de escolher mergesort para listas ligagas e intro/quick sort para vectors e deques sem voce precisar se preocupar.[/quote]

A velocidade computacional dos dois eh a mesma. Alias, se nao tomar cuidado, a do quick eh pior (o introspection sort meio que rouba, mas tudo bem).

Eh, 600 mil registros para ele ficar dando compareTo eh triste hein? Complicado. E ele fica passivando e ativando toda essa galera, ja que 600 mil entidades nao cabem na memoria.

#13

O custo computacional do quicksort e do mergesort são razoavelmente diferentes; do uso de cpu o primeiro o pior caso é quadrático, o segundo não existe diferença entre pior e melhor.

O custo de memoria do mergesort para estruturas de dados que não são listas-ligadas é muito maior. Enquanto um quick sort bem implementado utiliza +/- lg(N) frames, mergesort vai precisar de de um vetor auxiliar de N/2 para ordernar um vetor.

#14

[quote=“louds”]O custo computacional do quicksort e do mergesort são razoavelmente diferentes; do uso de cpu o primeiro o pior caso é quadrático, o segundo não existe diferença entre pior e melhor.
[/quote]

Um quicksort bem programado eh sempre nlogn (basta aleatorizar a ordem da entrada). O custo computacional dos dois fica igual. Assim como heapsort e qquer outro nlogn.

[quote=“louds”]
O custo de memoria do mergesort para estruturas de dados que não são listas-ligadas é muito maior. Enquanto um quick sort bem implementado utiliza +/- lg(N) frames, mergesort vai precisar de de um vetor auxiliar de N/2 para ordernar um vetor.[/quote]

Eh verdade. Por isso que o java usa mergesort para listas, e quicksort para arrays. Viu como o pessoal da sun nao eh bobo?

#15

Esse link se encaixa aqui :

Do not perform database tasks in code

#16

Fala galera,

show de bola esse link que o douglasfs postou, e nele tem um outro link para um artigo do Martin Fowler sobre o assunto do topico.

Domain Logic and SQL
http://www.martinfowler.com/articles/dblogic.html

Abraco,

#17