gpt4 book ai didi

java - 比较 Querydsl、jOOQ、JEQUEL、activejdbc、iciql 和其他查询 DSL

转载 作者:IT老高 更新时间:2023-10-28 21:03:38 30 4
gpt4 key购买 nike

谁能给我一些关于可用于 Java 的不同 Query DSL 库之间性能比较的资源,例如: Querydsl , jOOQ , JEQUEL , activejdbc , iciql 等等……

背景: 我正在使用 Spring JDBC 模板,但这仍然需要以纯字符串格式编写查询。虽然我在编写直接查询时没有问题,但我担心直接依赖于数据库表名。我不想使用任何 ORM 框架,如 Hibernate 或 JPA/EclipseLink。我需要尽可能高的原始性能(IMO,它们适用于更多以 CRUD 为中心的应用程序)。我可以为这些 DSL 提供一点点开销(我相信,它主要是 StringBuilder/String 连接!)

我考虑过在某些 xml 中使用外部化的命名查询。但只是尝试评估不同 Query DSL 库提供的值(value)。

编辑:更多关于我的要求:我想知道在使用它们的 API 方法构建一个中等复杂的查询时它们之间的性能比较。我只需要使用这些查询 DSL 库中的任何一个生成查询字符串,并将其传递给 Spring JDBC 模板。所以,我想知道添加这个中间步骤是否会导致相当大的性能损失,我想使用命名查询或构建我自己的库,它只使用 StingBuilder 或类似方法

更新我对 jOOQ、iciql、QueryDSL 的体验:

虽然我在原始帖子中没有提及这一点,但我也很喜欢我的实体类中需要的易用性和开销(比如是否需要任何额外的注释或实现)。

jOOQ:

  • 需要将实体属性更改为特定于库的方式
  • 可以返回 SQL 查询字符串

Iciql:

  • 实体可以在没有或很少更改的情况下进行映射(总共可以使用 3 种方式进行映射)
  • 但它仅限于选择查询(更新/删除/...需要再次更改实体)

查询DSL:

  • 多种方式将实体与表绑定(bind)(除了库特定的方式,支持使用 JPA 注释)。但我们至少需要修改实体
  • 没有简单/直接的方式来获取查询字符串

(所有观察都是我对这些知之甚少;如果其中任何一个不正确,请更正)

综上所述,我坚持编写命名查询 :( 但正如 Lukas Eder 的回答似乎解释了我最初的帖子关注点(性能),我接受了他的。

最佳答案

在现代 JVM 中,您不必过多担心 SQL 字符串连接。任何数据库抽象层可能产生的真正开销(与到数据库和返回的相对较高的往返时间相比)通常是由于二级缓存,这是在 Hibernate/JPA 中完成的。或者通过使用索引或一般查询转换变得不可能的方式将对象模型映射到 SQL 的效率低下。

与此相比,字符串连接真的可以忽略不计,即使对于具有多个 UNIONs、嵌套 SELECTsJOINs 的复杂 SQL 构造也是如此>semi-JOINsanti-JOINs 等,所以我猜你提到的所有框架都以类似的方式执行,因为它们允许你保持对 SQL 的控制。

另一方面,某些框架或这些框架中的使用模式实际上可能会将整个结果集提取到内存中。如果您的结果集很大,这可能会导致问题,还因为使用 Java 的泛型,大多数原始类型(intlong 等)可能映射到它们相应的包装器(Integer, Long).

至于jOOQ (我是其中的开发人员),我之前使用 YourKit Profiler 对库进行了概要分析。用于大规模查询执行。批量工作总是在数据库中完成,而不是在查询构造中。 jOOQ 对每个查询使用单个 StringBuilder。我想(未验证)QueryDSLJEQUEL做同样的事情......

至于iciql ,它是 JaQu 的一个分支,由于他们使用 Java 工具来反编译他们的 natural syntax,这可能会产生一些额外的影响。 .但我想这可以省略,如果它意味着太大的影响。

关于java - 比较 Querydsl、jOOQ、JEQUEL、activejdbc、iciql 和其他查询 DSL,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/7242388/

30 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com