JPA 性能优化或替代方案

Question

我们目前处于一个对数据库读取性能要求很高的项目中。

我们目前正在使用 JPA（EclipseLink 实现），目前只是因为它提供了方便的数据库访问和列映射。

对于我们的查询，我们使用高度具体的 SQL 查询。我们还使用一个数据库（SAP HANA，内存中），因此不需要语言抽象。数据库访问非常快，我们目前的瓶颈确实是应用服务器，尤其是持久层。

结果集通常也不包含实体，因为实体是由上下文组成的。对我们来说，使用像下面这样的 @Id 字段没有意义，因为我们没有唯一的字段（只有组合，但定义 IdClass 开销太大）。

@Entity
public class Item {

    @Id
    public myField;


    // other fields...
}

如果我想运行类型化的本机查询，这似乎是由 JPA 强制执行的。这个假设是真的吗？目前我们还没有找到绕过 ID 映射的方法。

这些发现是否有效？ 如果不是，我们如何才能使我们对 JPA 的使用性能更高（与普通 JDBC 相比存在显着延迟），同时也无需为结果类型定义 @Id（因为它在我们的情况下没用）？ 如果是，是否有另一个 Java 库仅在 JDBC 之上提供一个最小层而没有太多延迟，提供比普通 JDBC 更方便的使用（具有列映射和所有这些好东西）。

谢谢！

用例：我们希望从数据库中传输历史 GPS 传感器数据。除了将其转换为 JSON 之外，我们还进行了一些转换/验证。这就是为什么我们实际上需要构建对象。所以我们基本上寻找的是一种将select语句的字段映射到属性的便捷方式。我希望这是有道理的。

Answer 1

有很多关于提高 EclipseLink/JPA 性能的文章和博客，您可以查看，例如 EclipseLink Performance、JPA Performance Tuning 和 Optimizing the EclipseLink Application

最后，尽管这在很大程度上取决于您的特定用例以及您可能想要的任何未来用例。 JPA 旨在使 JDBC 之上的读写更容易和更易于维护，并增加了许多性能优势，例如缓存。如果您使用它的目的只是读取原始数据，那么额外的层可能是额外的开销，不会增加任何价值。让 JPA 从结果集中构建实体、维护缓存并监视更改只是让您的应用程序忽略它并获取原始数据并没有多大意义。

我不明白你为什么会有一个带有单个 myField 的 Item 表。应用程序如何使用它以及它与其他表和潜在实体的关系如何？

这种结构不是关系数据库和 ORM 的正常用例，但在 JPA 中仍有解决方法。数据可以由其他实体在元素集合中使用，甚至不被映射，并且使用直接通过 JDBC 层传递的本机 SQL 查询。 EclipseLink 本身有许多超越 JPA 的映射类型和选项，可能会根据您的用例使用。