<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=4959673747617280078" rel="nofollow">http://blog.oneapm.com/apm-tech/720.html</a></p>    <p> </p>