Java Persistence API (JPA)是存取Java关系数据的企业级标准JPA为Java对象映射到数据库图解提供支持包括一个简单的API设计和查询语言的表达查询语言的表达是为了检索来自数据库映射的结果并且因为这个结果改变回执 JPA通过书写以及维护他们自己的映射代码允许存在单一的API而不管平台应用服务器或者提供持久执行为开发者提高生产率这些高速缓存解决方案允许经常的存取实体到存储器可以减少到数据库查询的次数和大量花费在转换数据库查询结果到对象上的处理时间高速缓存可以深入的积极的对应用性能产生影响
JPA和数据网格
数据网格是运行在有代表性的低耗硬件群集上面的软件支持数据存贮和处理服务数据网格产品聚集了处理能源和存储群集服务的能力使得客户端通过API可以使用它API是为防护设计的避免分布式计算的复杂数据网格作为可伸缩的分布式存储被普遍运用;无论如何分布式数据处理也是常见的特性作为存储器数据网格提供一种方法来超越单一服务器因为堆栈大小的限制这个解决办法就是通过分布式数据存取所有的集群服务器
尽管他们在专业技术领域内的应用被限制但是在当今企业应用中与数据网格相关的话题仍然层出不穷数据网格已经成为一种主流当开发应用程序的时候开发者需要考虑网格架构并且意识到在未来网格在应用程序中的应用比例会被提高
考虑一个银行系统通过在写入数据库前确认所有项目来处理存款和撤销请求确认的内容也许包括帐目是否有效提出请求的是否是户主账户上是否有户主要求提取的存款数额等等你可以想象在这样一个系统中还有很多需要确认的地方你需要从数据库中读取数据总和数据总和执行一个确认的单一请求是有重要意义的并且会引起很多查询幸运的是在JPA中创建这样一个以数据库为中心的应用程序是非常简单的绘制领域内的每一个classe到数据库并且书写必要的JP QL查询来检索确认的对象系统也许不得不从数据库读取大量的数据来处理每一个请求但是它运作的很好
现在如果我们需要显着的提高这个系统的生产力我们不得不解决它唯一但是最大的瓶颈通过查询数据库得出确认数据大多数JPA执行不是提供一个L存储功能就是支持第三方L存储功能的整合但是如果我们不得不处理大量随机到达的请求在存储器中拥有必须的参考数据是不太可能的事情存储器在你重复的存取一些数据是非常的有效如果你存取的是随机数据存储器不太可能储存你当即所需要的数据当然你可以不停的增加存储器的容量来满足你的需求但是每一个服务器只能拥有这么多的堆栈
数据网格提供一种方法来超越单一服务器因为堆栈大小而产生的限制以及在集群服务器上分布存储对象现在要面临的挑战是将数据网格技术与JPA融合从而能够提高生产力而不需要完全改写应用程序当然作为软件系统的代表性案例有很多案例是接近一体化的每一个都伴有各自的优势劣势让我们来看看整合的体系架构以及我们应该如何使用
数据网格作为中间级别的对象存储
像我们前面所提到的数据网格产品可以扩展存储存取一个集群并且可以作为一个共享的中间存储使用他们提供一个单一的逻辑堆栈可以从物理层面进行扩展这种扩展是伴随着全部的存储容量在多重服务器上实现的全部的存储容量是包括所有的群集服务器的堆栈在例子当中这意味着通过增加更多的服务器到网格它的存储容量可以增加要点是所有的确认数据必须预先加载(通常是加热存储器)自从确认数据的存取成为我们的瓶颈存取所有的必须数据在实际上消除了这个问题
举例来说在我们的银行系统中考虑一个简单的可以确定的方法
public boolean isValidAccount(Request request) {
Account account = entityManagerfind(
Accountclass requestgetAccountId());
if (account == null) {
return false;
} else {
return accountisValid();
}
}
伴随着数据网格整合成为L存储器查询功能将会检查网格所需要的账户如果不查询它可以转而查询基础数据库无论如何如果网格中包含了所有的帐号信息这就没必要查询数据库预热应用存储器可以从确认队列中完整的清除数据库存取过程
主键查询可以很容易的运用到数据网格中但是JP QL查询如何那?考虑这种方法使用非主键查询的请求
public Customer getTxCustomer(Request request)
throws NoResultException {
Customer customer = entityManager
createQuery(select c from Customer c
where cmasterAccountId = :id)
setParameter(id requestgetMasterAccountId())
getSingleResult();
return customer;
}
查询数据网格
得出一个匹配随意准则的对象仍然是一件困难的事情
首先
它依赖于数据网格是否提供某种查询框架
第二
JPA/data网格一体化可以将JP QL转化为此框架
如果满足这两个必要条件
我们例子中的查询就可以被应用在网格中
而不是数据库中
这种方式的另一个很有价值的特性是执行并行查询的可能性显而易见的是我们例子中的查询可以在网格中所有的服务器上并行执行查找需要的对象无论如何一个查询执行后返回很多的对象是件有趣的事情每一个网格服务器都可以执行并行查询来识别这些对象使其与被给予的标准相匹配在个对象上并行执行这种查询十次比在个对象上查询一次的速度快得多服务器越多每个服务器上分配的对象数量就越少查询速度也就越快!
遗憾的是关于查询问题还是有一个麻烦就是返回多重结果与主键查询不同主键查询中如果存储器失误会自动的引起数据库查询而现在是否从网格中得到足够的结果是不明确的也许你只能查询网格中的一部分对象所以一个网格查询是无法返回数据库中其他部分的查询结果通过确保所有的对象都在网格中预热存储器解决了这个问题 但这并不总是可行无论如何对于一个特定的使用案例也许你知道一个特有的查询是否需要网格或者数据库再JPA中通过查询节点实现查询功能的也许就像下面的演示
Customer customer = entityManager
createQuery(select c from Customer c
where cmasterAccountId = :id)
setParameter(id requestgetMasterAccountId())
setHint(myjpaimplementationdontquerygrid true)
getSingleResult();
当然
现在没有JPA标准来说明是否把查询用于数据网格
这意味着你不得不在你编译的代码中采用特殊执行的节点
幸运的是
JPA规范依赖于执行
忽略那些不明白的的节点
所以你编译的代码并没有因为节点而与任何一个特定对象结合
更新对象
当你看到网格上面的JPA很自然的你会首先想到查询但是我们也不得不考虑更新输入新对象修改现有对象以及删除对象当网格在L存储器中时确定网格的更新仅仅在数据库执行过程成功交付之后产生是非常重要的输入新对象会引起数据库INSERT并且新对象会被放置到网格中修改对象会引起数据库UPDATE并且被更新的对象会被放置到网格中最后删除一个对象会引起数据库DELETE并且这个对象会从网格中被移除关键点是更新数据网格一次数据库执行过程可以成功交付
数据网格作为系统备份
当JPA使用数据网格作为一个分布式存储器数据库就成为了系统备份这是系统本来面目的最终来源并且保持实时更新但是数据网格实现备份的意义是什么?这个案例经常使用在金融应用软件上用以处理快速的变化以及过度过程数据如果没有数据库或者数据库仅仅被用来存放数据或者是只是一个货舱而不是联机系统网格上面的JPA看起来会怎么样?
