java - Pruebas de rendimiento entre QueryDSL SQL vs JDBCTemplate

spring

Question

Estoy intentando convencer a "los superiores" de que utilicen querydsl sql para nuestra persistencia. Pero prefieren la jdbctemplate de primavera, por la razón de que da el mejor rendimiento en bruto.

El rendimiento es nuestro principal requisito por supuesto. Por eso JPA no es una opción en absoluto. ¿La sobrecarga SQL de QueryDSL es demasiado para eliminarla de nuestras opciones?

Quería saber si hay pruebas de rendimiento "recientes" para mostrar cómo las tarifas sqld de querydsl con jdbctemplate y jpa.

Me encontré con esto . Quiero saber el rendimiento relativo de querydsl sql cuando se compara con jdbctemplate y una implementación jpa.

Answer 1

He realizado algunas pruebas de rendimiento para comparar la comarison de gastos generales / rendimiento entre querydsl y jdbctemplate.

Aquí esta lo que hice
1. Creó un proyecto de arranque de primavera que usa querydsl y jdbctemplate
2. Creado 2 puntos finales, 1 para usar querydsl y otro para jdbctemplate.
3. La configuración querydsl usa el origen de datos autoconfigurado de arranque de primavera para configurar su SQLQueryFactory.
4. JdbcTemplate también se autoconfigura con el mismo origen de datos autoconfigurado.
5. Hay 2 implementaciones de una consulta similar en el repositorio, una usa querydsl y la otra usa jdbctemplate. La consulta es relativamente compleja y consiste en un par de combinaciones internas y cláusulas where.
6. Los métodos de servicio tienen un bucle for y llaman al método de repositorio en cada iteración. El número de iteraciones es configurable y se ha establecido en iteraciones de 1 lakh.
7. System.nanoTime () se usa alrededor del método de servicio en el controlador para calcular el tiempo que le tomó ejecutar muchas iteraciones del método de repositorio.
8. JdbcTemplate tomó un promedio de 800ms para ejecutar llamadas de repositorio de 1 lakh.
9. Querydsl tomó un promedio de 5000ms para ejecutar llamadas de depósito de 1 lakh.
10. Observación: Querydsl es 6 veces más lento que JdbcTemplate para la misma consulta. La sobrecarga es presumiblemente en la serialización de consulta de querydsl.

Implementación del repositorio 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;

Implementación de 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;
                }
            });  

Básicamente estoy tratando de hacer exactamente lo mismo con diferentes bibliotecas y medir cuál incurre en más sobrecarga.
1. Ejecute una consulta relativamente compleja con combinaciones.
2. Rellenar frijoles del conjunto de resultados.

Estoy usando la base de datos H2 In-memory. La base de datos contiene solo un par de registros para cada tabla. Y 1 fila de resultados que coincide con la consulta.

El método se ejecuta en un bucle for (iteraciones de 1 lakh). Y tiempo calculado con la ayuda de System.nanoTime () alrededor del ciclo.

Es un proyecto de arranque de primavera con diferentes puntos finales (uno para querydsl y otro para jdbctemplate). La configuración para querydsl y queryfactory se realiza de la siguiente manera

  @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

Perfile su aplicación y vea qué es lo que toma el tiempo en la consulta. ¿Es el análisis sintáctico y la compilación de la consulta, o la consulta misma?

¿Estás escribiendo consultas que devuelven todo el objeto de dominio o un subconjunto de columnas (utilizando el constructo de tipo JPA "select new BlaBlaDTO")?

¿Ha considerado utilizar Spring Data JPA en el que tiene control total sobre si desea utilizar RAW SQL, consultas con nombre o el método Spring Data JPAs para dar nombre a las consultas sobre convenciones?

¿Su configuración de conexión JDBC permite almacenar en caché las declaraciones preparadas en el lado de la base de datos, de modo que solo necesitan estar preparadas una vez para la misma consulta con diferentes parámetros (esto hace una gran diferencia)?

¿Está utilizando un caché de primer y segundo nivel para mejorar el rendimiento del servidor?

Elegir JDBC sin procesar como mecanismo preferido terminará siendo horrible; consultas complejas, sin comprobación sucia, sin bloqueo optimista, etc.

Answer 3

Ammen.M si busca rendimiento en términos de acceso a bases de datos (en la plataforma JavaEE), la mejor opción es JDBC puro, pero todo el mundo conoce sus limitaciones y el uso extensivo de cadenas con SQL nativo. Spring Data, JPA o QueryDSL, todos estos marcos te ofrecen otros beneficios como seguridad de tipo, mapeo relacional entre tablas y Objetos.

Entonces, si su equipo está realmente preocupado por el rendimiento, esa debería ser su apuesta.