QueryDSL SQL与JDBCTemplate之间的性能测试

Question

我试图说服“上级”使用querydsl sql作为我们的持久性。但是他们更喜欢，原因是它提供了最好的原始性能。

当然，性能是我们的首要要求。这就是为什么JPA根本不是一种选择。是否QueryDSL SQL开销太大，无法将其从我们的选项中删除？

我想知道是否进行了“最近”的性能测试，以显示querydsl sql在jdbctemplate和jpa中的表现。

我偶然发现了这。与jdbctemplate和jpa实现相比，我想知道querydsl sql的相对性能。

Answer 1

我做了一些性能测试来比较querydsl和jdbctemplate之间的开销/性能比较。

以下是我所做的

1. 创建了一个使用querydsl和uses模板的spring引导项目。
2. 创建了两个端点，一个用于使用querydsl，另一个用于jdbctemplate。
3. querydsl配置使用spring自动配置的数据源来配置其SQLQueryFactory。
4. JdbcTemplate也是用相同的自动配置数据源自动配置的。
5. 存储库中有两个类似查询的实现，一个使用querydsl，另一个使用jdbctemplate。查询相对比较复杂，由两个内部联接和where子句组成。
6. 服务方法有一个for循环，并在每次迭代中调用存储库方法。不是的。迭代是可配置的，并且已经设置为100,000次迭代。
7. 在控制器中的服务方法周围使用System.nanoTime()来计算执行存储库方法的多次迭代所需的时间。
8. JdbcTemplate平均花费800 of来执行10万个存储库调用。
9. Querydsl平均花费了5000 of来执行10万个存储库调用。 10.观察:对于相同的查询，Querydsl比JdbcTemplate慢6倍。开销大概在querydsl.的查询序列化中。

QueryDSL库实现

List<Customer> customers = new ArrayList<>();
Customer customerObj = null;
List<Tuple> customerTuples =queryFactory.select(customer.firstName,customer.status,customer.customerId).
                                from(customer).innerJoin(customerChat).on(customer.customerId.eq(customerChat.senderId)).
                                innerJoin(customerChatDetail).on(customerChat.chatDetailId.eq(customerChatDetail.chatDetailId)).
                                where(customerChatDetail.isRead.eq(true).and(customer.status.eq(true))).fetch();

    for (Tuple row : customerTuples) {
        customerObj = new Customer();
      customerObj.setFirstName(row.get(customer.firstName));
      customerObj.setStatus( row.get(customer.status));
      customerObj.setCustomerId(row.get(customer.customerId));
      customers.add(customerObj);
    }
return customers;

JdbcTemplate实现

List<Customer> customers = this.jdbcTemplate.query(
            "select first_name,status,customer_id from customer inner join v_customer_chat on customer.customer_id=v_customer_chat.sender_id inner join v_customer_chat_detail on v_customer_chat.chat_detail_id = v_customer_chat_detail.chat_detail_id where v_customer_chat_detail.is_read = ? and customer.status = ?;",new Object[] {true, true},
            new RowMapper<Customer>() {
                public Customer mapRow(ResultSet rs, int rowNum) throws SQLException {
                    Customer customer = new Customer();
                    customer.setFirstName(rs.getString("first_name"));
                    customer.setStatus(rs.getBoolean("status"));
                    customer.setCustomerId(rs.getLong("customer_id"));
                    return customer;
                }
            });  

基本上，我试图对不同的库做完全相同的事情，并度量哪一个库会产生更多的开销。

1. 使用联接执行一个相对复杂的查询。
2. 从结果集中填充bean。

我正在使用H2内存数据库.数据库只保存每个表的几条记录。和一个匹配查询的结果行。

该方法在for循环(1,000次迭代)中执行。以及在循环周围的System.nanoTime()帮助下计算的时间。

它是一个具有不同端点的spring引导项目(一个用于querydsl，另一个用于jdbctemplate)。querydsl和queryfactory的配置如下所示

  @Autowired
public DataSource dataSource;

@Bean
public PlatformTransactionManager transactionManager() {
    return new DataSourceTransactionManager(dataSource);
}

@Bean
public com.querydsl.sql.Configuration querydslConfiguration() {
    SQLTemplates templates = H2Templates.builder().build();
    com.querydsl.sql.Configuration configuration = new com.querydsl.sql.Configuration(templates);

    configuration.setExceptionTranslator(new SpringExceptionTranslator());

    return configuration;
}

@Bean
public SQLQueryFactory queryFactory() {
    Provider<Connection> provider = new SpringConnectionProvider(dataSource);
    return new SQLQueryFactory(querydslConfiguration(), provider);
}

Answer 2

分析一下你的应用程序，看看在查询中花了些什么时间。是查询的解析和编译，还是查询本身？

您是否正在编写返回整个域对象或列子集的查询(使用JPA“选择新BlaBlaDTO”类型构造)？

您是否考虑过使用Spring数据JPA，其中您可以完全控制是使用原始SQL、命名查询还是Spring数据JPAs方法命名约定查询？

您的JDBC连接设置是否可以在数据库端缓存已准备好的语句，以便它们只需要为具有不同参数的相同查询准备一次(这就产生了巨大的不同)？

您是否使用第一级和第二级缓存来提高服务器端性能？

选择原始JDBC作为首选机制将是糟糕的；复杂的查询、不进行脏检查、不进行乐观锁定等等。

Answer 3

M如果在数据库访问方面(在JavaEE平台中)寻找性能，最好的选择是纯JDBC，但每个人都知道它的局限性，以及在原生SQL中广泛使用字符串。Spring数据、JPA或QueryDSL，所有这些框架都为您提供了其他好处，例如类型安全性、表和对象之间的关系映射。

所以，如果你的团队真的很关心你的表现，那应该是你的赌注。