如何借助 NoSQL 提高 JPA 应用性能

Mar6166 8年前
   <p>【编者按】关注 NoSQL 的动态发展很重要。NoSQL 的好处并不仅限于新的应用开发。在某些案例中,你可以见识到重新访问现有的、传统的框架带来的积极效果,比如说你的 JPA 的实现。本文系国内ITOM 管理平台OneAPM 编译呈现。</p>    <p>多年以前,笔者在为一家世界顶级汽车公司做电子商务网站项目时,曾经碰到过一个听起来像科幻故事的概念:通过实体类别来自动实现数据持久存储。</p>    <p>是的,笔者说的就是现在大家都知道的分布式组件标准(EnterpriseJavaBeans)。发布于1998年,后来被并入 Java EE 的技术规范,它引入了实体(Entity Beans)的概念。当时的想法是提供一个开发框架,让开发者可以将他们的对象自动映射到相关表格,这样该框架就可以在数据库中持续自动将应用程序数据持久存储。这被称为 ORM:对象关系映射。</p>    <p>当时是21世纪初,大家还习惯于等待当时最牛的太阳微系统公司(Sun Microsystem)——跟现在苹果公司的地位差不多——带来各种重大发明,不过那可真的是模式的变更。它是紧跟面向对象编程(Object Oriented programming)出现的概念,不过它本身对主流应用开发世界来说就是一个重大的模式转变。当时,在一个集中的数据库中持久存储数据的概念已经得到广泛接受,关系数据库也有很多。服务器端 web 应用开始成为主流,当然,你还得选择存储数据的数据库,虽然关系数据库并不是唯一的选择,但它们是当时所谓的“桌面应用”的首选。这些都表明,应用存储和检索数据的唯一方式是通过执行 SQL 查询。在很多情况下,这种操作是非常复杂的。</p>    <p>与之相反,Java 完全是面向对象的,不会被理解为表格和关系。关系数据库很容易就能被其他过程式语言借助 SQL 来采用。当时,Java 还饱受微软和太阳间的诉讼的影响,该诉讼涉及到 Java 和 IE 间的兼容性。开发者们都在讨论哪个平台或者框架能够胜出:Java 还是微软新发布的.NET。</p>    <p>在这种背景下,EJB 提出的自动持久存储是个令人欣喜,同时又极富创新的概念。不过,当时的硬件现实条件摆出了一个挑战:虽然这个概念不错,但是当时的处理硬件尚未准备好。Java 的问题已经足够证明,被认为是“老派做法”的运行解释代码并不会降低所有进程的速度。在 EJB 要求的多层额外管理中执行这样的代码,更是超出想象。还有别忘了,我们说的是32位单核处理器时代,高端服务器的内存也不过 256 MB 到512 MB!(参考 <a href="/misc/goto?guid=4959673746892599575" rel="nofollow,noindex">topdesignmag.com</a> )</p>    <p>时间快进到2016年,Hibernate 已经发布了第5版, <a href="/misc/goto?guid=4958984561219205875" rel="nofollow,noindex">根据最新调查</a> ,超过73%的 Java 开发是在某个 Java EE 框架下进行的。</p>    <p>自2009年起,随着 JPA 2.0 的规范出台,越来越多的应用从这种抽象概念中受益。Gavin King 于2001年开发的 Hibernate ORM 得到广泛使用,更是起到了推动作用,这是由前 EJB2 式实体类别提供的更简单的持久化能力实现方法。由于被认证为 <a href="/misc/goto?guid=4959673747131183588" rel="nofollow,noindex">2010 JPA 2.0 规范</a> 的一种实施方法,Hibernate 成为应用开发者们广泛推崇和使用的技术。</p>    <p>然而,发布15年以来,开发者论坛关于最初主题的讨论依然有很多:如何改善 JPA 的性能表现。虽然硬件速度有了很大提升,同样的问题依然存在。如今 JPA 成了主流技术,影响着世界上数以万计的系统,这个问题就变得更加重要。ORM 架构内在的问题并没有改变:将面向对象的世界映射到关系世界并不是个小任务,需要付出大量的额外努力才能实现无缝对接。</p>    <p>很多年前,Ted Neward 把 ORM 称为“ <a href="/misc/goto?guid=4959673747216815628" rel="nofollow,noindex">计算机世界的越南</a> ”,把它跟收益递减规律联系在一起:一开始看起来很好,但是你用得越多,要获得额外收益就越难。在某些时候,因为前期已经付出了资金和时间,你很难“放弃诱饵,转身跑掉”。他甚至还建议同时使用 ORM 方案和直接的 SQL 方案(或者 JDBC),这样“就可以绕过那些 ORM 会带来麻烦的地方”。这跟性能表现有很大关系。</p>    <p><a href="/misc/goto?guid=4959673747292835386" rel="nofollow,noindex">jhades.org</a> 的成员在他们的 <a href="/misc/goto?guid=4959673747380745280" rel="nofollow,noindex">博客</a> 中提出了一个很好的观点,他们说,ORM 给自己带来的主要问题是挑战(实时)同步两个完全不同的数据结构。表格、关系和面向对象这几个数据结构之间并没有什么相似性。结果就是,传统的关系数据库管理系统在所有的 ORM 实施过程中的表现都有所降低,就是因为 SQL 与这些受益于 ORM 的应用之间没有相似性,也就是所谓的 <a href="/misc/goto?guid=4959673747449503665" rel="nofollow,noindex">领域驱动设计</a> (Domain Driven Design)。</p>    <p>但是如今,整个数据库产业都在经历变革。过去15年来,你得很有勇气,才敢避开关系数据库管理系统,使用其他备选方案来持久存储数据——如果你能找到的话,更不要说你还要费尽力气解释自己为什么要这么做。如今,大量 NoSQL 数据库增加了计算机科学出现更多新模式的可能性。说 JPA 不能从中受益简直是大错特错,而且笔者认为它绝对能从中受益。从数据结构的观点来看,要在 JPA 实现方法中持久存储数据,很多 NoSQL 方法都更合理,效果也比表格或关系数据管理系统更好。</p>    <p>笔者的研究似乎表明这是真的。我们最近基于自己的键值存储(key-value store,缩写为 KVS)数据库引擎 <a href="/misc/goto?guid=4959673747534009636" rel="nofollow,noindex">c-treeACE V11</a> 发布了一个新的 JPA 实现方法。最初的测试结果表明,在使用 c-treeACE 替代 SQL 数据库后,性能提升了30%。</p>    <p>实现这种效果是通过有效利用一种智能映射方法,能够识别出那些可以在低层级 KVS 中执行的检索,从而避免繁冗、不必要的 SQL。由于 c-treeACE 是一种多模式数据库,与数据库互动的层(Java 持久存储层,缩写为 JPL)能够在 SQL 和 NoSQL 之间自如转换,从而优化每次 query.z 的执行。</p>    <p><img src="https://simg.open-open.com/show/deb3e6edb73ebfa420fd6e0d9641c8b0.png"></p>    <p>总之,关注 NoSQL 的各种动态发展很重要。NoSQL 的好处并不仅限于新的应用开发。在某些案例中,你可以见识到重新访问现有的、传统的框架带来的积极效果,比如说你的 JPA 的实现。无论你是用 Hibernate,或者其他 ORM 框架,数据库替换都会是一个低风险、小投入的项目。你可能会发现,你很快就能节省几千美元。</p>    <p>OneAPM 能为您提供端到端的Java 应用性能解决方案,我们支持所有常见的 Java 框架及应用服务器,助您快速发现系统瓶颈,定位异常根本原因。分钟级部署,即刻体验,Java 监控从来没有如此简单。想阅读更多技术文章,请访问OneAPM 官方技术博客。</p>    <p>原文地址: <a href="/misc/goto?guid=4959673769343244858" rel="nofollow,noindex">https://dzone.com/articles/how-to-improve-performance-of-your-jpa-application</a></p>    <p> </p>    <p>来自: <a href="/misc/goto?guid=4959673747617280078" rel="nofollow">http://blog.oneapm.com/apm-tech/720.html</a></p>    <p> </p>