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