java - JPA 性能优化或替代方案

Question

我们目前正在进行一个对数据库读取性能要求很高的项目。

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

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

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

@Entity
public class Item {

    @Id
    public myField;


    // other fields...
}

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

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

谢谢!

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

Answer 1

有许多关于提高 EclipseLink/JPA 性能的文章和博客您可能会研究，例如 EclipseLink Performance , JPA Performance Tuning和 Optimizing the EclipseLink Application

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

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

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