Análise de Desempenho dos Frameworks de Persistência Hibernate e EclipseLink

Transcrição

1 Análise de Desempenho dos Frameworks de Persistência e EclipseLink Aurélio Vargas Ramos Júnior 1, Edson A. Oliveira Junior 2 Resumo. Nas aplicações de software é comum o armazenamento de dados persistentes. Esses sistemas são apoiados, em sua maioria, por gerenciadores de banco de dados relacionais, um framework de persistência gerencia a base de dados e o mapeamento entre a base de dados e os objetos. Este artigo compara a performance de dois frameworks de persistência e EclipseLink JPA usando uma base de dados de uma locadora de DVDs. Para facilitar tais testes, faz-se uso da API JPA que permite a fácil migração entre esses frameworks com pequenas alterações em sua configuração. Palavras-chave: framework, ORM,, JPA, EclipseLink, benchmark. Abstract. In the applications software is common to store persistent data. These systems are supported mostly by managers relational database, a persistence framework manages the database and the mapping between the database and the objects. This paper compares the performance of two persistence frameworks and EclipseLink JPA using a DVD rental database. To facilitate these tests, it is using the JPA API that allows easy migration between these frameworks with small changes to your configuration. Keywords: framework, ORM,, JPA, EclipseLink, benchmark. 1. Introdução Trabalhar com software orientado a objetos e bancos de dados relacionais pode ser trabalhoso e demorado, devido a incompatibilidade entre o paradigma de representação dos dados no modelo de objetos e o modelo de bancos de dados relacionais (conflito de impedância) [7]. Frameworks de mapeamento objeto relacional são uma solução. O Mapeamento Objeto-Relacional, (Object Relational Mapping - ORM) refere-se à técnica de mapeamento de dados a partir de uma representação do modelo de objeto em uma representação do modelo de dados relacional [3]. Servindo como uma ponte entre esse conflito de impedância o que torna a persistência de objetos mais simples, o trabalho do desenvolvedor é definir como os objetos são mapeados nas tabelas do banco e o Framework ORM faz o acesso ao banco, gerando inclusive os comandos em SQL necessários para tarefas padrões. Este artigo tem como meta comparar dois frameworks ORM, o que é um dos mais consolidados por desenvolvedores Java e.net e o EclipseLink, um framework extensível que permite interagir com vários serviços de dados, incluindo Banco de Dados, Web Services, Objetos XML, EIS, etc. Sendo assim, EclipseLink não implementa apenas o padrão JPA, mas também outros padrões como JAXB, JCA e SDO. Para tal comparação serão utilizadas algumas operações de 1 Aluno do curso de especialização em Desenvolvimento de Sistemas para Web Universidade Estadual de Maringá (UEM) - Av. Colombo, 5790 Bloco C56 Maringá PR Brasil ramos.junior@outlook.com 2 Departamento de Informática Universidade Estadual de Maringá (UEM) - Av. Colombo, 5790 Bloco C56 Maringá PR Brasil - edson@din.uem.br 1

2 persistência a saber: consultas simples e com joins, inserção, alteração e exclusão. Será utilizada uma média do desempenho dos procedimentos executados para encontrar o framework com menor tempo médio nas operações de persistência. Este artigo está organizado da seguinte forma: na Seção 2 são abordadas as tecnologias utilizadas para efetuar a comparação dos frameworks; na Seção 3 é realizado o estudo comparativo de desempenho entre e EclipseLink e na Seção 4 é apresentada a conclusão e trabalhos que podem ser desenvolvidos futuramente. 2. Revisão Bibliográfica 2.1. O framework foi desenvolvido por uma equipe de programadores Java liderada por Gavin King e teve sua primeira versão divulgada em Segundo King [5], um dos objetivos ao criar o projeto era resolver seus problemas referentes à persistência causados pelo EJB 2.0, o qual considerava muito complexo. Devido à popularidade do projeto e por se tratar de um projeto pessoal, King utilizava seu tempo livre para que pudesse resolver problemas identificados pelos usuários do. Com um escopo muito vasto, o projeto tornou-se inviável de ser mantido apenas nos tempos livres, assim King aceitou entrar para o JBoss Group, passando a ser remunerado para continuar a desenvolver o projeto, o que lhe permitiu dedicação completa ao [5]. Com a especificação da JPA (Java Persistence API), solidificou-se como a implementação mais utilizada. Diversos projetos também passaram a ser desenvolvidos pela equipe do a fim de aprimorar os recursos existentes no framework. Muitos deles, em vez de serem anexados ao projeto Core, tornaram-se plugins, tais como Search, o OGM e o Validator. Este último, inclusive, teve fortes influências para a criação de uma nova especificação, a Bean Validation (JSR 303). A partir da versão 3.5, o tornou-se uma implementação certificada para a JPA2 (JSR 317), lançada oficialmente no final de Várias annotations surgiram e muitos recursos foram aprimorados [9]. A escolha do se deve ao fato de ele ser o framework ORM Java mais consolidado do mercado e implementar a especificação padrão Java EE para persistência, o JPA EclipseLink JPA O Eclipse Persistence Services Project, mais conhecido como EclipseLink, é uma solução abrangente de persistência open source. Seu projeto foi iniciado por uma doação do código-fonte completo e suítes de teste de produtos da Oracle TopLink. Esse projeto traz a experiência de mais de 12 anos de uso comercial e de Desenvolvimento [1]. Podese dizer que o EclipseLink evoluiu ao ponto de ser uma ferramenta superior ao TopLink. É dito que as próximas versões do TopLink incluirão o EclipseLink, assim como a próxima versão do Oracle Application Server [4]. Similar ao, a intenção do projeto é oferecer uma solução baseada em padrões centrados no JPA [1]. A escolha do EclipseLink se deve porque apesar do ter originado a JPA, o EclipseLink substituiu o produto Oracle TopLink Essentials e também se tornou a implementação de referência da versão JPA 2.0, sendo distribuído juntamente com o servidor de aplicações GlassFish V3 [10] Java Persistence API (JPA) O Java Persistence API (JPA) é uma especificação de persistência padrão aprovada pela JCP (Java Community Process) em meados de 2006, como parte da especificação EJB3 (Enterprise Java Beans 3). O JPA lida com a forma como os dados 2

3 relacionais são mapeados para objetos Java, a maneira que esses objetos são armazenados em um banco de dados relacional para que possam ser acessados posteriormente e, a existência continuada de um estado da entidade mesmo após a aplicação que usa termina. Além de simplificar o modelo de persistência da entidade, o JPA padroniza mapeamento objeto-relacional [4]. Neste artigo a base de dados foi mapeada utilizando do padrão JPA 2.0, para padronizar a aplicação o que torna possível que a aplicação seja independente do framework abordado. Sendo assim para cada teste, foi necessário somente alterar a biblioteca utilizada pela aplicação (framework) Protótipo de aplicação para os casos de teste O objetivo deste trabalho é analisar o desempenho dos frameworks e EclipseLink de ORM para a linguagem Java, para isso foram realizados testes utilizandose um protótipo de sistema simples para a gestão de locadora de filmes. A base de dados DVD rental é uma base de testes que foi portada para o Postgres do banco de dados Sakila, originalmente para MySQL e desenvolvida por Mike Hillyer do MySQL AB documentation team. Essa base foi modificada para se adequar às funcionalidades do PostgreSQL 3. O DVD rental representa um processo de comércio de uma loja de locação de DVD com aproximadamente registros. Possuindo muitos objetos como: 15 tabelas 1 trigger 7 views 8 funções 1 domínio 13 seqüências A Figura 1 ilustra o diagrama de entidade-relacionamento dessa base. 3 O esquema e seus dados estão disponíveis no endereço: 3

4 Figura 1: Modelo Entidade-Relacionamento do banco de dados Dvd Rental. 3. Estudo Comparativo de Desempenho entre e EclipseLink JPA 3.1. Ambiente de Execuções Para efetuar as execuções de benchmark foi utilizado: Eclipse Kepler Java EE for Web Developers como ambiente de desenvolvimento integrado (IDE); 4.3.1; EclipseLink JPA 2.5.1; Postgres 9.3; Java JDK 1.7.0_45; Sistema Operacional Linux Mint 16 Petra x86_64 GNU/Linux; e Sistema de arquivos - ext4. O computador usado para os testes é um Dell Intel optiplex 780 processador Intel(R) Core(TM)2 Quad CPU 2.83GHz, 4GB de memória RAM. O projeto pode ser baixado no repositório GitHub Planejamento, Execução e Análise dos Resultados 4

5 3.2.1 Definição de Contexto e Planejamento do Estudo Comparativo Objetivo do Estudo Comparar frameworks de persistência objeto-relacional, com o objetivo de identificar o melhor desempenho com relação à operações de persistência de dados em um banco de dados relacional, do ponto de vista de analistas e desenvolvedores de software, no contexto de um estudo de caso específico para operações de persistência relacionais Seleção das Variáveis Variáveis independentes (entrada/causa): o Framework de persistência - e EclipseLink JPA; o Sistema Operacional Linux Mint 16 Petra x86_64 GNU/Linux; o Sistema de arquivos - ext4; e o Banco de Dados Postgres Variável dependente (observação/efeito): o Desempenho Definição das Hipóteses Hipótese Nula (H0): os tempos médios para a execução das operações de persistência usando e EclipseLink JPA são os mesmos. Hipótese Alternativa (H1): o tempo médio de execução das operações de persistência usando é menor que o tempo médio usando EclipseLink; e Hipótese Alternativa (H2): o tempo médio de execução das operações de persistência usando é maior que o tempo médio usando EclipseLink Definição do plano de Testes Procedimentos metodológicos Foram gravados tempos de relógio do sistema em dois momentos: na requisição e na obtenção da resposta. Calcula-se a diferença entre o tempo do momento de obtenção da resposta e o tempo do momento da requisição [6]. RES = T2 T1 T1: Tempo obtido no momento da requisição. T2: Tempo obtido no momento da resposta. RES: Tempo de resposta Medidas 5

6 Boral e Dewitt [6] definem que quatro tipos de consultas são necessárias para a realização da análise de desempenho em sistemas de bancos de dados. Grupos Utilização de CPU Utilização de Disco Tipo 1 Baixo Baixo Tipo 2 Baixo Alto Tipo 3 Alto Baixo Tipo 4 Alto Alto Quadro 1: Tipos de consultas para análise de desempenho. Segundo os autores as consultas em bancos de dados consomem basicamente dois recursos de sistema: a) Ciclos de CPU: são consumidos tanto pelo sistema que executa a consulta (a aplicação) como por outras funções executadas pelo próprio SGBD. Ciclos de CPU também são consumidos pelo Sistema Operacional na iniciação das operações de disco. b) Operações de Disco: são consumidos durante a recuperação dos dados requeridos para responder uma consulta, armazenar dados de uma consulta no disco ou atividades de swapping. As consultas foram baseadas no Quadro 1, e nas métricas definidas para avaliação das alternativas de persistência de dados num ambiente objeto relacional, por Santos e Martins [7]. Foram utilizadas 2 métricas de consulta e 3 métricas de inserção de entidades. Sendo as consultas executadas as seguintes: Inserções Consultas Inserção simples; Inserção em Cascata; Inserção relacionamento ManyToMany; Consulta em profundidade; Consulta relacionamento M:N; Consulta de 1 tupla campo indexada; Consulta de 100 tuplas em não indexadas; Consulta tuplas de utilizando índice com relação a outra tabela; Consulta 100 tuplas de utilizando de função agregada; Execução do Estudo Comparativo O estudo comparativo foi conduzido com base na execução de 12 operações de persistência, sendo 6 consultas, 3 inserções e 3 exclusões. Cada consulta foi executada 100 vezes, sendo efetuado o cálculo médio do desempenho de cada consulta para ser criado o gráfico dos resultados. Inserções: para testar o tempo necessário para efetuar as inserções foram testados três tipos de inserções sendo: a inserção de uma entidade disjunta [2], na qual 6

7 foi inserida a entidade Actor. A inserção em um relacionamento M*N (relacionamento Actor Film) e uma inserção em cascata (foram persistidas as entidades City e Country através da persistência da entidade Address). Como mostra a Figura 2, o levou um tempo maior que o EclipseLink na inserção em um relacionamento M*N, sendo que nas demais o apresentou um desempenho melhor. EclipseLink JPA 0,004 0,004 0,01 0,003 0,007 0, ,002 0,004 0,006 0,008 0,01 0,012 0,014 0,016 0,018 0,02 Tempo em segundos Simples Aninhada Relacionamento M*N Figura 2: Desempenho inserções. Consultas: foram efetuadas 6 tipos de consulta as duas primeiras são busca em profundidade (a partir da Entidade Payment obteve se a entidade Store através da junção com mais 3 entidades), nessa consulta o EclipseLink teve um melhor desempenho. A segunda consulta é o retorno de um relacionamento M*N, na qual foi buscada a entidade Rental de um cliente. Nessa consulta o apresentou um melhor desempenho como mostra a Figura 3. EclipseLink JPA 0,004 0,017 0,002 1, ,2 0,4 0,6 0,8 1 1,2 1,4 1,6 Tempo em segundos Busca Profundidade Relacionamento M*N Figura 3: Busca em Profundidade e consulta de um relacionamento M*N. Grupo 1: é uma consulta simples que busca 1 registro do tipo Customer por ID. Conforme o Quadro 1 apresentado na seção , essa consulta ocupa pouco processamento e utilização de disco. O comando utilizado para essa consulta foi: SELECT c FROM Customer c WHERE c.customerid = 3. Como mostra a Figura 4, o efetuou a consulta em 0,007s e o EclipseLink JPA efetuou a consulta em 0,006s. 7

8 EclipseLink JPA 0,006 0,007 0,0054 0,0056 0,0058 0,006 0,0062 0,0064 0,0066 0,0068 0,007 0,0072 Tempo em segundos Figura 4: Seleção de um registro por atributo índice. Grupo 2: é uma consulta que busca 100 registros do tipo Film por titulo e ID utilizando o operador >. Conforme o Quadro 1 apresentado na seção , essa consulta ocupa pouco processamento e muito do disco. O comando utilizado para esta consulta foi: FROM Film f WHERE f.title LIKE 'on%' AND f.filmid > 500. Como mostra a Figura 5, o efetuou a consulta em 0,004s e o EclipseLink efetuou a consulta em 0,005s. EclipseLink JPA 0,005 0, ,001 0,002 0,003 0,004 0,005 0,006 Figura 5: Seleção de 100 registros em 1000 utilizando operador LIKE. Grupo 3: é uma consulta que busca 1000 registros do tipo Payment através de uma junção com a entidade Rental e utilizando o ID de Rental para a seleção. Conforme o Quadro 1 apresentado na seção , essa consulta ocupa bastante processamento e pouca utilização do disco. O comando utilizado para essa consulta foi: SELECT p FROM Payment p LEFT JOIN FETCH p.rental LEFT JOIN FETCH p.rental WHERE p.rental.rentalid = 2. Como mostra a Figura 6, o efetuou a consulta em 0,006s e o EclipseLink efetuou a consulta em 0,008s. EclipseLink JPA 0,008 0, ,001 0,002 0,003 0,004 0,005 0,006 0,007 0,008 0,009 Figura 6: Seleção de registros de utilizando índice de outra entidade. 8

9 Grupo 4: é uma consulta que busca 100 registros do tipo Payment por ID utilizando a função de agregação COUNT(). Conforme a tabela apresentada na seção , esta consulta ocupa bastante processamento e disco. O comando utilizado para esta consulta foi: SELECT COUNT(p) FROM Payment p WHERE p.customer.customerid = 1 AND p.paymentid <= 100. Como mostra a Figura 7, o efetuou a consulta em 0,004s e o EclipseLink efetuou a consulta em 0,003s. EclipseLink JPA 0,003 0, ,0005 0,001 0,0015 0,002 0,0025 0,003 0,0035 0,004 0,0045 Figura 7: Selecionar 100 registros de com função agregada Análise dos Dados do Estudo Comparativo Com base na execução das operações de persistência realizadas neste estudo o obteve melhor desempenho em 5 operações. O EclipseLink JPA obteve melhor desempenho em 4 operações. Sendo assim, o framework obteve o melhor desempenho total com base nas operações utilizadas neste estudo. O Quadro 2 mostra a quantidade de vezes que o framework foi superior categorizados por tipo de operação. Cláusulas EclipseLink JPA INSERT 2 1 SELECT 3 3 Total 5 4 Quadro 2: Desempenho dos frameworks categorizados por tipo de operação. Assim, o estudo realizado fornece indícios de que a hipótese nula (H0) deve ser rejeitada e, conseqüentemente, a hipótese alternativa (H1) deve ser aceita, sendo que no total de operações, o framework obteve melhor desempenho do que o framework EclipseLink JPA para as operações de consulta realizadas neste estudo. Já o framework EclipseLink obteve melhor desempenho médio nas operações. 4. Conclusões e Trabalhos Futuros Este artigo apresentou uma análise de desempenho baseada em benchmark por meio de uma série de operações de persistência com o intuito de fornecer evidências iniciais, para guiar na escolha do framework de persistência mais adequado para projetos de persistência baseados em mono-usuário e acesso não concorrente. Os resultados 9

10 obtidos devem ser associados à Base de Dados Postgres e Sistema Operacional Linux (Ext4). A utilização de outras bases de dados e sistema operacionais (ou sistema de arquivos), pode levar a resultados diferentes dos apresentados aqui. Com base nos resultados obtidos pode-se observar uma ligeira vantagem na utilização do com relação ao EclipseLink para o conjunto de operações de consultas e, um desempenho aproximado porém com ligeira vantagem para o EclipseLink em operações de inserção definidas pelo benchmark utilizado. Com relação a trabalhos que podem ser desenvolvidos futuramente tem-se: (i) a análise de desempenho dos frameworks trabalhado no projeto, em um sistema multiusuário; (ii) planejamento e realização de uma análise do mesmo mapeamento em base de dados distintas, a base utilizada possui implementações para outros banco de dados; (iii) planejamento e realização de uma análise comparativa com sistemas de arquivos diferentes e (iv) estudo comparativo através de métricas qualitativas dos frameworks ORM. Referências Bibliográficas [1] CLARKE, D. Apresentando EclipseLink. Eclipse Zone, 30 jun Disponível em: < Acesso em: 15, jan, 2014 [2] DIOGO V. DOS SANTOS, MARCELO DE R. MARTINS Métricas para avaliação das alternativas de persistência de dados num ambiente objeto relacional. São Paulo: IME/USP, [3] HIBERNATE. Community Documentation. Developer Guide. Disponível em: < >. Acesso em: 15, jan, [4] HIGOR, M. Introdução ao EclipseLink. DevMedia. Disponível em: < >. Acesso em: 20, jan, 2014 [5] IZALMO PRIMO D S. Artigo Java Magazine 73 - Desenvolvendo com. Disponível em: < Acesso em: 15, jan, [6] JADER D. S. T. C. - Estudo comparativo entre os frameworks de Mapeamento Objeto- Relacional e Toplink. Maringá, Paraná: EspWeb/UEM [7] PIETER VAN ZYL, DERRICK G. KOURIE, ANDREW BOAKE Comparing the Performance of Object Databases and ORM Tools. Disponível em: < Zyl Comparing the Performance of Object Databases and ORM Tools September 2006.PDF>. Acesso em: 10, set, [8] VITOR GOTARDO - Análise de Desempenho dos Frameworks de Persistência e Spring Data. Maringá, Paraná: EspWeb/UEM [9] HANELLI TAVANTE As novidades do 4. Disponível em: < [10] SILVIO PAGANINI Persistência a toda prova. Java Magazine 81. Disponível em: < [6] MIKAEL KOPTEFF The Usage and Performance of Object Databases compared with ORM tools in a Java environment. Disponível em: < Kopteff The Usage and Performance of Object Databases Compared with ORM Tools in a Java Environment March 2008.PDF>. Acesso em: 10, set, [8] SHOAIB MAHMOOD BHATTI, ZAHID HUSSAIN ABRO, FARZANA RAUF ABRO Performance Evaluation of Java Based Object Relational Mapping Tools. Disponível em: < Acesso em: 16, nov, [9] MIKE AULT, DONALD K. BURLESON, CLAUDIA FERNANDEZ, KEVIN KLEIN, BERT SCALZO - Database Benchmarking: Practical Methods for Oracle & SQL Server. Rampant Techpress, PAP/CDR edition, p. 19, []Leia mais em: Maven, JSF 2, Spring e - Revista Java Magazine /23800#ixzz2vQ4TsGsk 10