开发者社区> oneapm_official> 正文

JPA2.1 中三个提升应用性能的新功能

简介:
+关注继续查看

经常在网上看到开发者们抱怨 JPA 性能低下的帖子或文章,但如果仔细查看这些性能问题,常会发现导致问题的根本原因大致包括以下几个:

  • 使用过多的 SQL 查询从数据库中获取所需的实体信息,即我们常说的n+1查询问题

  • 逐个更新实体,而不是使用单条语句进行更新

  • 使用 Java 应用程序而非数据库进行大量数据处理

JPA2.1 中三个提升应用性能的新功能

JPA提供了处理这类问题的方法,并给 JPA2.1 增加了一些额外功能,可以极大地提升性能表现,笔者将在本文中解释如何利用 JPA2.1 的功能避免上述问题。

顺便提一下,如果想了解Java项目中更多的典型性能问题,可以参考笔者最近发布的基于性能调查结果的深度报告,如果你在寻找 JPA 资源,点击此链接便可获取JPA2.1特征的备忘清单。接下来我们来看看如何用JPA来解决现有的性能问题。

解决「SQL 查询过多」的问题

根据以往的经验,使用过多的 SQL 查询获取所要求的实体是导致性能问题最普遍的原因。

即使是看起来最简单的查询,如果操作不当,也会触发几十次甚至上百次的 SQL 查询。而且,你在本节中可以看到,这类不当操作不一定会出现在查询语句中,而可能只是几个配置不当的注解。所以,如果你觉得这个问题不会造成影响,请三思。

如果在你的项目中出现以下几段代码,你会怎么想?


List authors = this.em.createQuery("SELECT a FROM Author a",
        Author.class).getResultList();
for (Author a : authors) {
    System.out.println("作者 "
            + a.getFirstName()
            + " "
            + a.getLastName()
            + " 书籍信息 "
            + a.getBooks()
                    .stream()
                    .map(b -> b.getTitle() + "("
                            + b.getReviews().size() + " 评论)")
                    .collect(Collectors.joining(", ")));
}

上面的代码段会打印所有作者的姓名及其书名,看起来非常简单,但你是否想过它给数据库发送了多少次查询?一次?还是两次?或者 Author、Book、Review 实体各一次?

实际上,这取决于数据库中作者的人数。如果数据库较小,里面只有11名作者和6本书。那么这段代码会触发12次查询,其中1次用于获取所有作者姓名,另外11次给每位作者匹配书名。这一问题被称作 n+1 查询问题,无论我们使用的是 MySQL、SqlServer 还是其他数据库,都容易出现此类问题。因此在生产环境中,随着数据量不断增大,代码的性能就越差。

我们可以通过多种方法,用一次查询获取所有要求的实体信息 ,从而避免这一情况。在笔者看来,使用 @NamedEntityGraph 来解决此问题是最新,也最好的方法。

实体图通过独立于查询的方法指定应该从数据库中获取的实体的图。这意味着,你需要为实体图创建一个独立的定义,并在需要时与查询合并。下段代码展示了如何定义根据作者名提取书名的 @NamedEntityGraph


@Entity
@NamedEntityGraph(name = "graph.AuthorBooks", attributeNodes = @NamedAttributeNode("books"))
public class Author implements Serializable {
…
}

现在,实体管理器可以用这个图为参考,通过一次查询获取所有作者和书名。在图的定义中可以看到,笔者只提供了包含相关实体的属性名称。因此,笔者将@NamedEntityGraph作为loadgraph (负载图),这样便可提取其他所有属性及其定义的获取类型,如下所示:


EntityGraph graph = this.em.getEntityGraph("graph.AuthorBooks");

List authors = this.em
.createQuery("SELECT DISTINCT a FROM Author a", Author.class)
.setHint("javax.persistence.loadgraph", graph).getResultList();

该示例展示了一个非常简单的实体图,在实际的应用中,很可能会用到更复杂的图,但这也不成问题。你可以定义多个 @NamedAttributeNodes 以定义更复杂的图,也可以用@NamedSubGraph 注解来创建多层次的图。如果想了解更多关于 @NamedEntityGraphs的信息,请点击实体图使用方式详解

在某些使用案例中,你可能还需要用更动态的方式来定义实体图,比如,根据一些输入参数进行定义。在此类案例中,通过 Java API 用编程的方式定义实体图效果更佳。

解决「逐个更新实体」的问题

逐个更新实体是造成 JPA 性能问题的另一个常见原因。作为 Java 开发者,我们习惯处理对象,并用面向对象的方式思考问题。尽管这是实现复杂逻辑和应用的好方法,但也是处理数据库时导致性能退化的一个常见原因。

从面向对象的角度来看,对实体进行更新和删除操作是完全可以接受的。但当你不得不更新一大组实体时,这种操作就会非常低效。持久性提供者(Persistence Provider)将为每个更新实体创建一个更新语句,并在下一次 flush 操作时发送至数据库中。

然而,SQL 提供了一个更为高效的方式。它允许你创建可一次性更新多个实体的更新语句。你还可以对 JPA 2.1 引入的 CriteriaUpdate 和 CriteriaDelete 语句进行同样的操作。

如果你之前用过 criteria 条件查询,肯定对新的 CriteriaUpdate 以及CriteriaDelete 语句非常熟悉,更新和删除操作的创建方式几乎与 JPA 2.0 中引入的 criteria 条件查询创建方式一样。

在下面的代码段中可以看到,你需要从实体管理器中获取 CriteriaBuilder 并用它创建 CriteriaUpdate 对象,对 CriteriaQuery 进行的操作与此类似,主要区别在于用于定义更新操作的 set 方法。


CriteriaBuilder cb = this.em.getCriteriaBuilder();
// create update
CriteriaUpdate update = cb.createCriteriaUpdate(Author.class);
// set the root class
Root a = update.from(Author.class);
// set update and where clause
update.set(Author_.firstName, cb.concat(a.get(Author_.firstName), " - updated"));
update.where(cb.greaterThanOrEqualTo(a.get(Author_.id), 3L));
// perform update
Query q = this.em.createQuery(update);
q.executeUpdate();

在 CriteriaDelete 操作中,你只需要在实体管理器中调用 createCriteriaDelete 方法以获取 CriteriaDelete 对象,并用它来定义与上例类似的 FROM 和 WHERE 查询部分。

在数据库中处理数据

作为 Java 开发者,我们倾向于在 Java 中实现所有的应用逻辑,这也是造成性能问题的一大常见原因。别误会,在 Java 中实现逻辑的好处很多,但如果将部分逻辑实现在数据库中,只把结果发送到业务逻辑层,也能得到很好的效果。

在数据库中执行逻辑的方法很多。只用 SQL 语句,也能完成很多事情,如果不够,你还可以调用数据库的特定功能和存储过程。在本文中,笔者将仔细探讨存储过程,更确切地说是探讨调用存储过程的方式。

在 JPA 2.0 中,并没有针对存储过程的实际支持,本地查询是调用存储过程的唯一方式。JPA 2.1.引入了 @NamedStoredProcedureQuery 和更为动态的StoredProcedureQuery,改变了这一现状。在本文中,笔者将重点关注基于注解的、用 @NamedStoredProcedureQuery 进行调用的存储过程的定义。笔者在自己的博客中详细介绍了动态存储过程查询 。

在下面代码段中可以看到, @NamedStoredProcedureQuery 的定义非常简洁,你需要指定查询的名称、数据库中的存储过程名称以及输入和输出参数。在本例中,笔者用输入参数 x 和 y 调用存储过程 calculate,期望的输出参数为 sum,其它支持的参数类型还有用于输入和输出的参数 INPUT 和用于检索结果集的 REF_COURSOR


@NamedStoredProcedureQuery(
name = "calculate",
procedureName = "calculate",
parameters = {
@StoredProcedureParameter(mode = ParameterMode.IN, type = Double.class, name = "x"),
@StoredProcedureParameter(mode = ParameterMode.IN, type = Double.class, name = "y"),
@StoredProcedureParameter(mode = ParameterMode.OUT, type = Double.class, name = "sum") })

@NamedStoredProcedureQuery 的使用方法与 @NamedQuery 相似,你需要向实体管理器的createNamedStoredProcedureQuery 方法提供查询名称,以便在本次查询中获取StoredProcedureQuery 对象,然后,用 setParameter 方法设定输入参数,之后再用execute 方法调用存储过程。


StoredProcedureQuery query = this.em.createNamedStoredProcedureQuery("calculate");
query.setParameter("x", 1.23d);
query.setParameter("y", 4.56d);
query.execute();
Double sum = (Double) query.getOutputParameterValue("sum");

总结

JPA 给数据库存储和检索带来诸多便利。通过这一工具,可快速开展项目,解决大部分问题,但也更容易导致实现非常低效的持久层。由此,普遍存在的问题包括:使用过多查询获取所需数据、逐个更新实体以及在 Java 中执行所有逻辑。

JPA 2.1规范引入了几个新的功能以应对这些低效操作,比如实体图(entity graphs),条件更新(criteria update)和存储过程查询(stored procedure queries)。笔者的JPA2.1新功能备忘单囊括了JPA 2.1的这些功能及其他新功能,你可以免费下载。

(编译自:http://zeroturnaround.com/rebellabs/three-jpa-2-1-features-that-will-boost-your-applications-performance/

OneAPM 为您提供端到端的 Java 应用性能解决方案,我们支持所有常见的 Java 框架及应用服务器,助您快速发现系统瓶颈,定位异常根本原因。分钟级部署,即刻体验,Java 监控从来没有如此简单。想阅读更多技术文章,请访问 OneAPM 官方技术博客

本文转自 OneAPM 官方博客

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
新功能:SLS支持持续性能数据采集与监控
降本增效的背景下,提升资源利用率变得更加重要,SLS 新功能持续性能数据采集与监控助力开发者突破性能瓶颈,定位系统顽疾。
19362 0
企业级解决方案-性能指标监控|学习笔记
快速学习企业级解决方案-性能指标监控
31 0
阿里云发布性能测试 PTS 2.0:低成本、高效率、多场景压测,业务稳定性保障利器
618 来临,高峰时段的品牌直播间要同时容纳几百万人线上发弹幕、抢货、抢红包,如此大的用户体量、高频交互以及脉冲流量场景,对于后端服务器来说都是不小的挑战。 为了确保线上稳定性以及优质的交互体验,通过性能测试 PTS(Performance Testing Service)进行压测成为很多平台和品牌商的首选。
349 0
移动端性能监测工具篇之U-APM
移动端性能监测工具篇之U-APM
198 0
Dapper,大规模分布式系统的跟踪系统。“目前市面的全链路监控系统基本都是参考Google的Dapper来做的”
Dapper--Google生产环境下的分布式跟踪系统,应运而生。那么我们就来介绍一个大规模集群的跟踪系统,它是如何满足一个低损耗、应用透明的、大范围部署这三个需求的。当然Dapper设计之初,参考了一些其他分布式系统的理念,尤其是Magpie和X-Trace,但是我们之所以能成功应用在生产环境上,还需要一些画龙点睛之笔,例如采样率的使用以及把代码植入限制在一小部分公共库的改造上。
343 0
ODC V3.2.0 新版本发布 | 着重用户体验,挑战权限管控业务场景
OceanBase 开发者中心(OceanBase Developer Center,ODC)在经过了新一轮的优化与提升后,迎来了 V3.2.0 新版本。
121 0
构建完整的性能压测体系及工具选型
本文作者: 殷成涛(花名:风起),阿里云PTS开发工程师,专注于性能压测与高可用架构领域 本文致力于给出性能压测的概念与背景介绍,同时针对市场上的一些性能压测工具,给出相应的对比,从而帮助大家更好地针对自身需求实现性能压测。
114 0
应用性能与优化服务(RPOS)
激增的订单量离不开背后强大的技术支撑,各家电商平台的IT部门在大促前都会有针对性的进行系统性能优化。原因很简单,应用性能和客户体验将会直接影响企业的业务收益。亚马逊曾经统计过,其网站首页平均打开时间每增加100毫秒,销售收入就会下降1%。
287 0
干货|车来了APM应用性能体验实践
车来了通过使用友盟+应用性能监控平台U-APM,实现了实时、可靠、全面地捕获应用崩溃、ANR、自定义异常、卡顿、启动分析等问题,全面提升用户体验。并轻松解决了传统应用稳定性监控服务普遍存在的难题
306 0
如何在 20 分钟内给你的 K8s PaaS 上线一个新功能?
上个月,KubeVela 正式发布了, 作为一款简单易用且高度可扩展的应用管理平台与核心引擎,可以说是广大平台工程师用来构建自己的云原生 PaaS 的神兵利器。 那么本文就以一个实际的例子,讲解一下如何在 20 分钟内,为你基于 KubeVela 的 PaaS “上线“一个新能力。
5530 0
+关注
oneapm_official
分享技术干货,解决性能问题,塑造品牌力量!
文章
问答
视频
文章排行榜
最热
最新
相关电子书
更多
如何保证移动应用的稳定性
立即下载
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载