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

Transcrição

1 Análise de Desempenho dos Frameworks de Persistência e Spring Data Vitor Gotardo, Edson A. Oliveira Junior 2 Resumo. Grande parte das aplicações desenvolvidas utilizando linguagens orientadas a objetos persistem seus objetos por meio de bases de dados relacionais com o apoio de frameworks de Mapeamento Objeto-Relacional (ORM), como. Este artigo apresenta uma análise de desempenho baseada em benchmark dos frameworks e Spring Data. Tal análise fornece indícios iniciais para que analistas e desenvolvedores possam escolher os frameworks mais apropriados para o desenvolvimento de seus projetos. Palavras-chave: framework, ORM,, JPA, Spring Data, benchmark. Abstract. Most applications developed using object-oriented languages persist your objects using relational databases with support of Object-Relational Mapping (ORM) frameworks such as. This paper presents a benchmark-based performance analysis for and Spring Data frameworks. Such an analysis provides initial evidence to analysts and developers may choose the most appropriate frameworks for the development of their projects. Keywords: framework, ORM,, JPA, Spring Data, benchmark.. Introdução Muitas aplicações utilizam dados que precisam ser guardados e recuperados, em um ambiente orientado a objetos. Os objetos são utilizados para representar esses dados, e nesse caso, é o objeto que precisa ser armazenado. Para tanto, existem três tipos de mecanismos de persistência de objetos: Object-Oriented Database Management Systems (OODBMS), Relational Database Management Systems (RDBMS) e Object- Relational Database Management Systems (ORDMS) []. Um problema muito conhecido na persistência de objetos em um banco de dados relacional é o conflito de impedância, que surge entre o modelo orientado a objeto e o modelo relacional e também entre a linguagem orientada a objeto e a linguagem de consulta (query) relacional []. Conflito de impedância é quando dois sistemas diferentes não funcionam de maneira ideal e eficiente quando conectados para funcionarem em conjunto. Poderíamos dizer então que os conceitos de modelo de orientação a objeto e do modelo relacional possuem valores de impedância diferentes. Enquanto o modelo relacional dá mais ênfase aos dados em si e sua representação e organização, o modelo orientado a objetos enfoca na abstração dos dados e seu comportamento, operações na forma de objetos [7]. O Mapeamento Objeto-Relacional (Object-Oriented Mapping - ORM) foi desenvolvido para servir como uma ponte entre esse conflito de impedância e tornar a persistência de objetos mais simples. Assim, é oferecido um mapeamento entre o modelo orientado a objeto e o modelo relacional []. 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 vitorgotardo7@gmail.com 2 Departamento de Informática Universidade Estadual de Maringá (UEM) - Av. Colombo, 5790 Bloco C56 Maringá PR Brasil - edson@din.uem.br

2 Este artigo tem como meta comparar dois frameworks ORM, o que é um dos mais consolidados por desenvolvedores Java e.net e o Spring Data JPA que é um framework recente, mas que promete agilizar o desenvolvimento da camada de persistência. Para tal comparação serão utilizados algumas operações de persistência sendo elas: consultas simples e com joins, inserção, alteração e exclusão. Será utilizado 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 Spring Data JPA; na Seção 4 é apresentada a conclusão e trabalhos que podem ser desenvolvidos futuramente. 2. Revisão Bibliográfica 2.. O é um projeto que tem como objetivo ser uma solução completa para o problema de mapeamento persistindo dados em Java. Ele serve como mediador na interação de aplicações com banco de dados relacional, deixando o desenvolvedor livre para concentrar-se na camada de negócio da aplicação. O é uma solução não intrusiva. O desenvolvedor não precisa seguir todas as regras e design patterns quando estiver desenvolvendo a camada lógica de negócio e classes de persistência, mas, o se integra facilmente com a maioria das novas e existentes aplicações e não requer grandes mudanças na aplicação [9] Spring Data JPA O Spring oferece suporte para as tecnologias de acesso a dados desde seu início. Este oferece uma implementação mais simples de acesso a dados, independente da tecnologia utilizada como JDBC,, TopLink, JDO e ibatis para a persistência de dados. O principal alvo do Spring em relação a acesso a dados era bancos de dados relacionais, sendo que esta tecnologia era predominante quando se trata de persistência de dados. Com a chegada da tecnologia NoSQL a espaço para criar suporte para desenvolvedores surgiu. Além disso, ainda existem melhorias a serem feitas relacionadas ao acesso a dados relacionais. Foram esses fatores que incentivaram a criação do projeto Spring Data que consiste em módulos dedicados para tecnologias como NoSQL, JPA e módulos JDBC para suporte a banco de dados relacional [2]. O projeto Spring Data JPA, embora não seja um framework ORM, foi desenvolvido com base no padrão JPA 2 para trabalhar com qualquer framework que siga tal especificação. O Spring Data JPA é responsável pela criação das classes Data Access Object (DAO) que possuem os métodos concretos para comunicação com a base de dados. Assim, fica abstraída a necessidade de se criar classes concretas para os repositórios de dados, sendo necessário apenas criar uma interface específica para cada classe de entidade, e nelas, estender a interface JpaRepository [3] Benchmark Employees Sample Database O benchmark é um teste, ou uma série de testes, que medem o desempenho de um sistema ou subsistema enquanto executam tarefas definidas. O benchmark deve medir o pico de desempenho de um sistema, normalmente operações com um problema conhecido. Benchmarks medem a capacidade de um sistema, muitas vezes referente a performance de uma aplicação em particular, como um banco de dados []. 2

3 Neste artigo o benchmark é utilizado para medir o desempenho de frameworks ORM efetuando operações de persistência em banco de dados relacional, assim, tornando possível a comparação entre eles. A base de dados Employee Sample Database foi desenvolvida por Crews e Maxia [4] e fornece aproximadamente 60MB de dados que estão separados em seis tabelas, fornecendo um total de 4 milhões de registros. Tal benchmark é bastante interessante para realizar tarefas de comparação de mecanismos de persistência de dados Java Persistence Query Language Em muitas maneiras o JPQL é similar ao SQL, uma ferramenta para interagir com base de dados relacional. Além disso, o JPQL é similar ao SQL em sua sintaxe, declarações e cláusulas. A principal diferença entre JPQL e SQL esta nos objetos que são especificados nas declarações e o objeto retornado por esta declaração. Em declarações SQL, é definido diretamente o objeto que deseja utilizar, por exemplo, uma tabela ou view para ser consultada ou modificada. Em declarações JQPL são utilizadas as entidades. E o mesmo acontece para os resultados retornados pela consulta JQPL, estes são instâncias de entidades, enquanto que os resultados retornados pelo SQL são tabelas ou views. Resumindo, o JQPL trata as entidades mapeadas para uma estrutura de base de dados, não precisando lidar com a estrutura da base de dados diretamente. O JQPL simplifica muito a tarefa de recuperar entidades. Todas as instâncias de entidades retornadas são automaticamente mapeadas. Assim, não é necessário mapear estas instâncias manualmente [0] A pode ser utilizada para criar consultas usando JPA e vincular esta consulta a um método na interface dos repositórios. Assim, quando o método é chamado, o Spring Data JPA executa a consulta especificada na [6]. 3. Estudo Comparativo de Desempenho entre e Spring Data JPA 3.. Ambiente de Testes Para efetuar os testes de benchmark foi utilizado: Spring Tool Suite como ambiente de desenvolvimento integrado (IDE) Spring Framework ; Spring Data JPA.3.4; MySQL ; Java JDK.7; Maven para construir os projetos mais facilmente mantendo as versões dos pacotes utilizados sempre estáveis e garantir que as mesmas versões foram utilizadas para os dois projetos. O computador usado para os testes tem processador I7@4.5Ghz com 4 núcleos reais e 8 threads, e 6GB de memoria RAM Planejamento, Execução e Análise dos Resultados 3

4 3.2. 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 a 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 benchmark 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 Spring Data JPA 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 Spring Data JPA são os mesmos. Hipótese Alternativa (H): o tempo médio de execução das operações de persistência usando é menor que o tempo médio usando Spring Data JPA. 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 Spring Data JPA Execução do Estudo Comparativo O estudo comparativo foi conduzido com base na execução de 4 operações de persistência, sendo consultas (query a query), sendo que as consultas (query3 e query5) possuem JOIN e as demais são consultas simples, inserção, alteração e exclusão. Cada consulta foi executada 0 vezes manualmente, sendo efetuado o cálculo médio do desempenho de cada consulta para ter uma ideia geral dos resultados. Query: é uma consulta simples que busca Employee em um total de registros. Foi utilizado somente a tabela employees da base de dados e o comando utilizado para esta consulta Employee e WHERE e.id = "). Como mostra a Figura o efetuou a consulta em 0,63s e o Spring Data JPA efetuou a consulta em 0,048s. 4

5 0,2 0,5 0,63 0, 0,05 0,048 0 Figura : Busca Employee em um total de registros. Query2: é uma consulta simples que busca registros do tipo Employee que possuam o ID maior que utilizando o operador >. Foi utilizado somente a tabela employees da base de dados e o comando utilizado para esta consulta Employee e WHERE e.id > 20000"). Como mostra a Figura 2 o efetuou a consulta em,006s e o Spring Data JPA efetuou a consulta em,087s.,,08,06,04,02 0,98 0,96,006,087 Figura 2: Busca registros do tipo Employee com ID maior que Query3: é uma consulta com JOIN que busca registros do tipo Employee que possuam o ID maior que e estão no Department de ID 7, os resultados estão ordenados pela data de início e de término que determinado Employee permaneceu no departamento. Foram utilizadas as tabelas employees e dept_emp e o comando utilizado para esta consulta Employee e INNER JOIN e.deptemps de WHERE e.id > AND de.pk.department = 7 ORDER BY de.from_date, de.to_date"). Como mostra a Figura 3, o efetuou a consulta em 3,826s e o Spring Data JPA efetuou a consulta em 3,536s. 5

6 3,9 3,8 3,7 3,6 3,5 3,4 3,3 3,826 3,536 Figura 3: Busca registros do tipo Employee com ID maior que que estão no Department de ID 7, ordenados pelas datas de início e término. Query4: é uma consulta simples que busca registros do tipo Employee que possuam o ID maior ou igual a utilizando o operador >=. Foi utilizado somente a tabela employees da base de dados e o comando utilizado para esta consulta Employee e WHERE e.id >= 20000"). Como mostra a Figura 4, o efetuou a consulta em,02s e o Spring Data JPA efetuou a consulta em,055s.,06,05,04,03,02,0,02,055 Figura 4: Busca registros do tipo Employee com ID maior ou igual que Query5: é uma consulta com JOIN que busca registros do tipo Employee que estão no Department de ID 7. Foi utilizado as tabelas employees e dept_emp e o comando utilizado para esta consulta Employee e INNER JOIN e.deptemps de WHERE de.pk.department = 7"). Como mostra a Figura 5, o efetuou a consulta em 3,787s e o Spring Data JPA efetuou a consulta em 3,470s. 6

7 3,9 3,8 3,7 3,6 3,5 3,4 3,3 3,787 3,47 Figura 5: Busca registros do tipo Employee que estão no Department de ID 7. Query6: é uma consulta simples que busca registros do tipo Employee que possuam o ID menor que utilizando o operador <. Foi utilizado somente a tabela employees da base de dados e o comando utilizado para esta consulta Employee e WHERE e.id < 20000"). Como mostra a Figura 6, o efetuou a consulta em 0,997s e o Spring Data JPA efetuou a consulta em,064s.,08,06,04,02 0,98 0,96 0,997,064 Figura 6: Busca registros do tipo Employee com ID menor que Query7: é uma consulta simples que busca registros do tipo Employee que possuam o ID menor ou igual a utilizando o operador <=. Foi utilizado somente a tabela employees da base de dados e o comando utilizado para esta consulta Employee e WHERE e.id <= 20000"). Como mostra a Figura 7, o efetuou a consulta em,007s e o Spring Data JPA efetuou a consulta em,04s.,05,04,03,02,0 0,99,007,04 Figura 7: Busca registros do tipo Employee com ID menor ou igual que

8 Query8: é uma consulta simples que busca registros do tipo Employee que possuam o ID diferente de utilizando o operador <>. Foi utilizado somente a tabela employees da base de dados e o comando utilizado para esta consulta Employee e WHERE e.id <> 20000"). Como mostra a Figura 8, o efetuou a consulta em,006s e o Spring Data JPA efetuou a consulta em,037s.,04,037,03,02,0,006 0,99 Figura 8: Busca registros do tipo Employee com ID diferente de Query9: é uma consulta simples que busca registros do tipo Employee que possuam o ID entre e utilizando o operador BETWEEN. Foi utilizado somente a tabela employees da base de dados e o comando utilizado para esta consulta Employee e WHERE e.id BETWEEN AND 50000"). Como mostra a Figura 9, o efetuou a consulta em 0,998s e o Spring Data JPA efetuou a consulta em,033s.,04,03,02,0 0,99 0,98 0,998,033 Figura 9: Busca registros do tipo Employee com ID entre e Query0: é uma consulta simples que busca registros do tipo Employee que são do GENDER(sexo) masculino(m) utilizando o operador IN. Foi utilizado somente a tabela employees da base de dados e o comando utilizado para esta consulta Employee e WHERE e.gender IN('M')"). Como mostra a Figura 0, o efetuou a consulta em 0,999s e o Spring Data JPA efetuou a consulta em,030s. 8

9 ,04,03,02,0 0,99 0,98 0,999,03 Figura 0: Busca registros do tipo Employee que são do sexo masculino. Query: é uma consulta simples que busca registros do tipo Employee que possuam primeiro nome com as letras Sa utilizando o operador LIKE. Foi utilizado somente a tabela employees da base de dados e o comando utilizado para esta consulta Employee e WHERE e.first_name LIKE '%Sa%'"). Como mostra a Figura, o efetuou a consulta em,039s e o Spring Data JPA efetuou a consulta em,066s.,07,066,06,05,04,039,03,02 Figura : Busca registros do tipo Employee que possuam Sa no primeiro nome. Query2: foram inseridos.000 objetos do tipo Employee na tabela employees. Todas as propriedades do objeto foram preenchidas, sendo elas: first_name, last_name, gender, hire_date, birth_date. Como mostra a Figura 2, o efetuou a inserção em 0,70s e o Spring Data JPA efetuou a inserção em 5,930s ,70 5,93 Figura 2: Inserção de.000 objetos do tipo Employee. 9

10 Query3: foram alterados os últimos registros do tipo Employee, os campos alterados foram: first_name, last_name, gender. Como mostra a Figura 3, o efetuou a operação em 0,77s e o Spring Data JPA efetuou a operação em 0,078s. 0,2 0,77 0,5 0, 0,078 0,05 0 Figura 3: Alteração dos últimos registros do tipo Employee. Query4: foram excluídos os últimos registros do tipo Employee. Como mostra a Figura 4, o efetuou a operação em 0,247s e o Spring Data JPA efetuou a operação em 0,47s. 0,3 0,25 0,2 0,5 0, 0,05 0 0,247 0,47 Figura 4: Exclusão dos últimos registros do tipo Employee Análise dos Dados do Estudo Comparativo Com base na execução das 4 operações de persistência realizadas neste estudo o obteve melhor desempenho em 9 operações. O Spring Data JPA obteve melhor desempenho em 5 operações. Sendo assim, o framework obteve o melhor desempenho geral com base nas operações utilizadas neste estudo. A Tabela mostra o desempenho dos frameworks categorizados por tipo de operação. Cláusulas Spring Data JPA WHERE 8 JOIN x 2 INSERT x UPDATE x 0

11 DELETE x Total 9 5 Tabela : 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, consequentemente, a hipótese alternativa (H) deve ser aceita, sendo que na média, o framework obteve melhor desempenho do que o framework Spring Data JPA para as operações realizadas neste estudo. O resultado do desempenho geral dos frameworks pode ser visto na Figura 5. 2,5,99,544 0,5 0 Figura 5: Desempenho geral dos frameworks. 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 podendo guiar analistas e gerentes na escolha do framework de persistência mais adequado para os seus projetos. Com base nos resultados obtidos pode-se observar uma ligeira vantagem na utilização do com relação ao Spring Data para o conjunto de operações definidas pelo benchmark utilizado. Como direção a trabalhos que podem ser desenvolvidos futuramente tem-se: (i) a análise do desempenho em um sistema multiusuário; (ii) planejamento e realização de uma análise comparativa utilizando benchmarks com operações de persistência mais complexas; (iii) estudo comparativo dos diferentes tipos de linguagem de queries suportadas pelos frameworks; e (iv) comparação de funcionalidades entre os frameworks. Referências Bibliográficas [] 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: 0, set, 203. [2] MIKAEL KOPTEFF The Usage and Performance of Object Databases compared with ORM tools in a Java environment. Disponível em: <

12 Kopteff The Usage and Performance of Object Databases Compared with ORM Tools in a Java Environment March 2008.PDF>. Acesso em: 0, set, 203. [3] MARCIO BALLEM S. Persistencia com Spring Data JPA. Disponível em: < Acesso em: 0, set, 203. [4] MYSQL Employees Sample Database Introduction. Disponível em: < Acesso em:, set, 203. [5] ORACLE The Java Persistence Query Language. Disponível em: < Acesso em:, set, 203. [6] PETRI KAINULAINEN Spring Data JPA Tutorial Part Three: Custom Queries with Query Methods. Disponível em: < Acesso em: 0, out, 203. [7] 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, [8] SHOAIB MAHMOOD BHATTI, ZAHID HUSSAIN ABRO, FARZANA RAUF ABRO Performance Evaluation of Java Based Object Relational Mapping Tools. Disponível em: < Acesso em: 6, nov, 203. [9] CHRISTIAN BAUER, GAVIN KING Java Persistence with. Manning Publications, Revised edition, p. 4, [0] YULI VASILIEV Beginning Database-Driven Application Development in Java EE: Using GlassFish. Apress, edition, p , [] 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. 9, [2] JONATHAN L. BRISBIN, OLIVER GIERKE, THOMAS RISBERG, MARK POLLACK, MICHAEL HUNGER Spring Data. O'Reilly Media, edition, p. 3,