Otimizando ORM com Hibernate

1/97
PGBR2013
Desenvolvendo Otimizado com PostgreSQL e
Programação Orientada a Objetos
Pablo Filetti Moreira
pablo.filetti@gmail.com

2/97
Agenda
● Baixa performance...
● ORM – Mapeamento Objeto/Relacional
● JPA – Java Persistence API
● Hibernate
● Fetching – Eager
● Fetching – Lazy
● Collection Fetching – Lazy
● Collection Fetching – Eager
● Cache do 1º Nível
● Cache do 2º Nível
● DynamicUpdate
● Query com NEW
● Batch Update
● Batch …
● Binários
● Query com FETCH
● BatchSize

3/97
Baixa performance...
Para Fernando Ike de Oliveira
60% Problemas são relacionados ao mau uso de expressões SQL.
20% Problemas são relacionados a má modelagem do BD's.
10% Problemas são relacionados a má configuração do SGDB.
10% Problemas são relacionados a má configuração do SO.
(OLIVEIRA,http://www.midstorm.org/~fike/palestras/tuning_pg_consegi.pdf)

4/97
Para Fábio Telles Rodriguez
Por mais que os desenvolvedores reclamem do servidor de banco de dados, em 80% dos casos o
problema está na aplicação e em 20% no SGDB. Não que a aplicação seja ruim em si, mas ela pode
não usar o SGDB de forma eficiente. Existem várias formas de se obter os mesmos dados de forma
ineficiente. Pior, uma consulta que funcionava bem num SGDB pode ter uma performance catastrófica
em outro SGDB. Infelizmente isto pode ocorrer também com migrações para outra versão do mesmo
SGDB. Mesmo assim, a culpa ainda não é do SGDB. A aplicação que tem (infelizmente) de adaptar às
especificidades de cada fornecedor e cada versão.
Na verdade, se formos levar a questão de forma mais ponderada, a lei não seria 80/20, seria 99,9/0,01 .
Isto ocorre por um motivo simples, ajustes de SQL e modelagem podem resultar em ganhos de
performance da ordem de 10, 100 ou até 1000 vezes. Enquanto isso, ajustes no SO e SGDB tem
ganhos da ordem de até 10 vezes. Portanto, antes de mais nada
aprenda a modelar bem e conheça as minúcias do SQL do seu SGDB. Depois aprenda a analisar com
profundidade os planos de execução e reescreva consultas complexas a partir deste tipo de análise.
(RODRIGUES, http://www.midstorm.org/~telles/2008/03/04/12-dicas-para-aprender-a-ajustar-a-
performance-de-bancos-de-dados/)

5/97
Para Kenia Milene
65% das causas de baixa performance em Bancos de Dados são causadas pelas aplicações.
Dificilmente temos no mesmo ambiente um DBA Desenvolvedor ou um Desenvolvedor DBA, sendo
assim, muito , mas muito cuidado na criação das consultas.
25% são causados pelos modelos de dados. Banco mal modelado
tende a ser terrível. A melhor forma é normalizar o modelo, com isso
ganhamos economia de espaço e a não repetição dos dados. Porém é necessário uma análise, pois
em relatórios muito grandes não é
aconselhável normalização quando falamos de ganho de performance.
5% são problemas do SGDB, acontece do gerenciador do banco
não ter um algoritmo eficiente, ou não consegue manter as informações necessárias na memória por
tempo eficiente. Atenção na aplicação de patchs e upgrades de versões.
5% são causadas por configurações ou deficiências do Sistema
Operacional. Atenção no fluxo da rede, muitas vezes o servidor esta com uma placa de rede não
adequada para a quantidade de fluxo de
informações que trafega. Verificações de parâmetros de Kernel também são consideráveis, pois o S.O
pode não estar deixando o banco escalonar que influencia no impacto do sistema. (MILENE,
http://keniamilene.wordpress.com/2007/10/25/regras-basicas-de-tuning-de-banco-de-dados/).

6/97
Para Claudia Machado
●Sistema operacional, caso tenha sido mal parametrizado;
●SGBD Relacional, por causa de inadequadas configurações relacionadas às
áreas de buffers, organização do logging, alocação de arquivos, entre outros;
●Rede, no caso de impactos no tráfego em razão de processamento de dados
efetuados no servidor ou na rede;
●Modelo físico de dados, em razão de inadequação na definição da estrutura
das tabelas e índices;
●Aplicação, quando ocorrem problemas na estrutura lógica efetuada pelo
programador, o que compreende a linguagem hospedeira e os comandos em
SQL.
(MACHADO,http://linhaseletrasweb.blogspot.com/2010/03/tuning-de-bancos-de-
dados.html)

7/97
A culpa é de quem???
Desenvolvedores
“Este Banco é uma carroça”
DBAs
“Esta aplicação é cheia de
gambiarras”

8/97
ORM – Mapeamento Objeto/Relacional
Por muitos anos, persistência tem sido um tópico quente de debates na
comunidade Java. Muitos desenvolvedores nem mesmo concordam com o
escopo do problema. Será a persistência um problema que já foi resolvido pela
tecnologia relacional e suas extensões como procedimentos armazenados
(stored procedures), ou ele é um problema mais amplo que precisa ser
endereçado por modelos de componentes Java especiais, como os entity beans
(componentes de entidade) do EJB? Devemos escrever à mão até mesmo as
mais primitivas operações CRUD (criar, ler, atualizar, deletar – create, read,
update, delete) em SQL e JDBC, ou esse trabalho deve ser automatizado?
Como alcançamos portabilidade se todo sistema de gerenciamento de banco
de dados possui o seu próprio dialeto SQL? Devemos abandonar o SQL em
definitivo e adotar uma tecnologia diferente de banco de dados, como o sistema
de banco de dados orientado para objetos? O debate continua, mas agora a
solução chamada mapeamento objeto/relacional (ORM – object/relational
mapping) tem uma grande aceitação. (BAUER e KING, 2007, p.4)

9/97
JPA – Java Persistence API
● Especificação
● Providers
● Hibernate
● EclipseLink
● OpenJPA
● TopLink

10/97
Hibernate
O Hibernate é um projeto ambicioso que visa ser uma solução
completa para o problema de gerenciar dados persistentes em
Java. Ele medeia a interação da aplicação com o banco de
dados relacional, deixando o desenvolvedor livre para se
concentrar no problema de negócio que tem nas mãos. O
Hibernate é uma solução não intrusiva. Não é necessário que
você siga muitas das regras e dos padrões de projeto
específicos do Hibernate quanto estiver escrevendo a sua
lógica de negócio e suas classes persistentes; é por essa razão
que o Hibernate se integra tranquilamente à maioria das novas
e existentes aplicações e não necessita de mudanças
incômodas ao resto da aplicação. (BAUER e KING, 2007, p.4)

11/97
Hibernate
● Produtivade
● Multibanco
● Sem SQL
● Criteria + JPQL (HQL)
● Cache
● Envers – Auditoria
● Hibernate Statistics

12/97
Fetching – Classe Produto

14/97
Fetching – Eager
select
produto0_.id as id1_2_,
produto0_.descricao as descricao1_2_,
produto0_.fabricante_id as fabricante5_1_2_,
produto0_.nome as nome1_2_,
produto0_.tipo_id as tipo6_1_2_,
produto0_.valor as valor1_2_,
fabricante1_.id as id0_0_,
fabricante1_.nome as nome0_0_,
tipoprodut2_.id as id2_1_,
tipoprodut2_.descricao as descricao2_1_
from
public.produto produto0_
inner join
public.fabricante fabricante1_
on produto0_.fabricante_id=fabricante1_.id
inner join
public.tipo_produto tipoprodut2_
on produto0_.tipo_id=tipoprodut2_.id
where
produto0_.id=?
select
from
inner join
inner join
where
produto0_.id=?

15/97
Fetching – Mapeamento Lazy

17/97
Fetching – Lazy
select
produtofet0_.id as id1_0_,
produtofet0_.descricao as descricao1_0_,
produtofet0_.fabricante_id as fabricante5_1_0_,
produtofet0_.nome as nome1_0_,
produtofet0_.tipo_id as tipo6_1_0_,
produtofet0_.valor as valor1_0_
from
public.produto produtofet0_
where
produtofet0_.id=?
select
produtofet0_.id as id1_0_,
produtofet0_.descricao as descricao1_0_,
produtofet0_.fabricante_id as fabricante5_1_0_,
produtofet0_.nome as nome1_0_,
produtofet0_.tipo_id as tipo6_1_0_,
produtofet0_.valor as valor1_0_
from
public.produto produtofet0_
where
produtofet0_.id=?

18/97
Fetching – Lazy
select
fabricante0_.nome as nome0_0_
from
where
fabricante0_.id=?
select
from
where
fabricante0_.id=?

19/97
Fetching – Lazy
select
from
where
tipoprodut0_.id=?
select
from
where
tipoprodut0_.id=?

20/97
Collection Fetching – Classe Fabricante

21/97
Collection Fetching – Lazy
select
from
where
fabricante0_.id=?
select
from
where
fabricante0_.id=?

22/97
Collection Fetching – Lazy
select
produtos0_.fabricante_id as fabricante5_0_2_,
produtos0_.id as id2_,
produtos0_.id as id1_1_,
produtos0_.descricao as descricao1_1_,
produtos0_.nome as nome1_1_,
produtos0_.tipo_id as tipo6_1_1_,
produtos0_.valor as valor1_1_,
from
public.produto produtos0_
inner join
on produtos0_.tipo_id=tipoprodut1_.id
where
produtos0_.fabricante_id=?
select
from
inner join
where
produtos0_.fabricante_id=?

23/97
Collection Fetching – Mapeamento Eager

24/97
Collection Fetching – Eager

25/97
Collection Fetching – Eager
Hibernate:
select
from
left outer join
on fabricante0_.id=produtos1_.fabricante_id
left outer join
where
fabricante0_.id=?
Hibernate:
select
from
left outer join
on fabricante0_.id=produtos1_.fabricante_id
left outer join
where
fabricante0_.id=?

26/97
Cache de 1º Nível – 1º Exemplo

27/97
select
from
inner join
inner join
where
produto0_.id=?
select
from
inner join
inner join
where
produto0_.id=?

28/97
Não faz consulta no BD.
A Entidade esta no Cache de 1º Nível

29/97
HashCode pri. produto: 1262837020HashCode pri. produto: 1262837020

30/97
HashCode seg. produto: 1262837020HashCode seg. produto: 1262837020

31/97
Resultado da comparação equals: trueResultado da comparação equals: true

32/97
Resultado da comparação equals: trueResultado da comparação equals: true

33/97

34/97
Cache de 1º Nível – 2º Exemploselect
from
inner join
inner join
where
produto0_.id=?
select
from
inner join
inner join
where
produto0_.id=?

35/97
select
from
inner join
inner join
where
produto0_.id=?
select
from
inner join
inner join
where
produto0_.id=?

36/97
HashCode pri. usuário: 1520159108HashCode pri. usuário: 1520159108

37/97
HashCode seg. usuário: 1147380142HashCode seg. usuário: 1147380142

38/97
Resultado da comparação equals: falseResultado da comparação equals: false

39/97
Cache de 2º Nível
Providers
● EhCache
● OSCache
● Terracotta
● Infinispan

40/97
Cache de 2º Nível – Persistence.xml

41/97
Cache de 2º Nível – Mapeamento Cache

42/97
Cache de 2º Nível – Estratégias
● READ_ONLY - Esta é a estratégia mais restritiva, indicada para entidades
que são apenas lidas e nunca modificadas pela aplicação.
● READ_WRITE - A estratégia leitura e escrita é a mais abrangente e suporta
escrita mais frequente, garantido que a última versão do cache é a mesma do
banco.
● NONSTRICT_READ_WRITE - Indicada para objetos que são raramente
atualizados e que têm probabilidade de atualizações simultâneas muito baixas
e é a mais comum. Caso muitas atualizações ocorram "simultaneamente"
pode ser que a última versão comitada no banco não seja a mesma que
acabou ficando no seu cache.
● TRANSACTIONAL - É totalmente transacional, com suporte a caches
distribuídos. Poucos providers oferecem esse suporte. O provider EhCache
não tem suporte a esta estratégia.

43/97

44/97
select
from
where
tipoprodut0_.id=?
select
from
where
tipoprodut0_.id=?

45/97

46/97
HashCode pri. tipo de produto: 480476266HashCode pri. tipo de produto: 480476266

47/97
HashCode seg. tipo de produto: 1142116702HashCode seg. tipo de produto: 1142116702

48/97
Resultado da comparação equals: falseResultado da comparação equals: false

49/97

50/97
select
tipoprodut0_.id as id2_,
tipoprodut0_.descricao as descricao2_
from
select
tipoprodut0_.id as id2_,
tipoprodut0_.descricao as descricao2_
from

51/97

52/97

53/97
DynamicUpdate – 1º Exemplo

54/97
select
from
inner join
inner join
where
produto0_.id=?
select
from
inner join
inner join
where
produto0_.id=?

55/97
update
public.produto
set
descricao=?,
fabricante_id=?,
nome=?,
tipo_id=?,
valor=?
where
id=?
update
public.produto
set
descricao=?,
fabricante_id=?,
nome=?,
tipo_id=?,
valor=?
where
id=?

56/97
DynamicUpdate – Mapeamento

57/97

58/97
select
from
inner join
inner join
where
produto0_.id=?
select
from
inner join
inner join
where
produto0_.id=?

59/97
update
public.produto
set
nome=?
where
id=?
update
public.produto
set
nome=?
where
id=?

60/97
Query com NEW – 1º Exemplo

61/97

62/97
select
produto0_.id as id1_,
produto0_.descricao as descricao1_,
produto0_.fabricante_id as fabricante5_1_,
produto0_.nome as nome1_,
produto0_.tipo_id as tipo6_1_,
produto0_.valor as valor1_
from
order by
produto0_.nome
select
from
order by
produto0_.nome

63/97

64/97

65/97
select
produto0_.id as col_0_0_,
produto0_.nome as col_1_0_
from
order by
produto0_.nome
select
produto0_.id as col_0_0_,
produto0_.nome as col_1_0_
from
order by
produto0_.nome

66/97
Batch Update – 1º Exemplo

67/97
Hibernate:
select
from
Para cada item do resultado acima faz:
Hibernate:
select
from
where
fabricante0_.id=?
Hibernate:
select
from
where
tipoprodut0_.id=?
...
Hibernate:
select
from
Para cada item do resultado acima faz:
Hibernate:
select
from
where
fabricante0_.id=?
Hibernate:
select
from
where
tipoprodut0_.id=?
...

68/97
Executa para cada item do resultado da lista.
Hibernate:
update
public.produto
set
valor=?
where
Id=?
...
Executa para cada item do resultado da lista.
Hibernate:
update
public.produto
set
valor=?
where
Id=?
...

69/97

70/97
update
public.produto
set
valor=valor*?
update
public.produto
set
valor=valor*?

71/97
Batch ...
● Batch Insert
● Batch Delete

75/97
Binários select
processo0_.id as id6_0_,
processo0_.dataDistribuicao as dataDist2_6_0_,
processo0_.numero as numero6_0_
from
public.Processo processo0_
where
processo0_.id=?
select
from
where
processo0_.id=?

76/97
Binários select
movimentos0_.processo_id as processo5_6_1_,
movimentos0_.id as id1_,
movimentos0_.id as id8_0_,
movimentos0_.data as data8_0_,
movimentos0_.descricao as descricao8_0_,
movimentos0_.numero as numero8_0_,
movimentos0_.processo_id as processo5_8_0_
from
public.Movimento movimentos0_
where
movimentos0_.processo_id=?
select
from
where

77/97
Binários A cada iteração do FOR do movimento faz:
select
arquivos0_.movimento_id as movimento7_8_1_,
arquivos0_.id as id1_,
arquivos0_.id as id7_0_,
arquivos0_.conteudo as conteudo7_0_,
arquivos0_.conteudo_tipo as conteudo3_7_0_,
arquivos0_.data_verificacao_assinatura as data4_7_0_,
arquivos0_.nome as nome7_0_,
arquivos0_.signatario as signatario7_0_
from
public.Arquivo arquivos0_
where
arquivos0_.movimento_id=?
A cada iteração do FOR do movimento faz:
select
arquivos0_.conteudo as conteudo7_0_,
from
public.Arquivo arquivos0_
where

78/97
Binários
Somente quando o usuário clicar
neste link que vamos mostrar o conteúdo
do arquivo.
????
Somente quando o usuário clicar
neste link que vamos mostrar o conteúdo
do arquivo.
????

83/97
Binários select
from
where
processo0_.id=?
select
from
where
processo0_.id=?

84/97
Binários select
from
where
select
from
where

85/97
Binários A cada iteração do FOR do movimento faz:
select
arquivos0_.conteudo_id as conteudo6_7_0_,
from
public.arquiv0 arquivos0_
where
select
from
where

87/97
Query com FETCH select
process0x0_.id as id4_0_,
process0x0_.dataDistribuicao as dataDist2_4_0_,
process0x0_.numero as numero4_0_,
movimentos1_.processo_id as processo5_4_0__,
movimentos1_.id as id0__
from
public.process0 process0x0_
left outer join
public.moviment0 movimentos1_
on process0x0_.id=movimentos1_.processo_id
where
process0x0_.id=?
select
from
left outer join
where
process0x0_.id=?

88/97
Query com FETCH
Agora não faz nada, já carregou os
movimentos na consulta anterior.

89/97
Query com FETCH
select
from
where
select
from
where

93/97
BatchSize select
from
left outer join
where
process0x0_.id=?
select
from
left outer join
where
process0x0_.id=?

94/97
BatchSize

95/97
BatchSize
select
from
where
arquivos0_.movimento_id in (
?, ?, ?, ?, ?
)
select
from
where
arquivos0_.movimento_id in (
?, ?, ?, ?, ?
)

96/97
Utilizar
● A vontade
● Hibernate Statistics
● Paginação
● query.setFirstResult() - Offset
● query.setMaxResults() - Limit
● Pool de conexões
● Aplication server – Ex: JBOSS AS
● C3P0
● Com cautela
● Sql nativo - Procedures
● Desnormalização

Otimizando ORM com Hibernate

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (17)

Semelhante a Otimizando ORM com Hibernate

Semelhante a Otimizando ORM com Hibernate (20)

Otimizando ORM com Hibernate