java - Comparando Querydsl, jOOQ, JEQUEL, activejdbc, iciql y otros DSL de consulta

performance spring-jdbc

Question

Alguien puede indicarme algunos recursos sobre la comparación de rendimiento entre las diferentes bibliotecas de consultas DSL disponibles para usar con Java, como: Querydsl , jOOQ , JEQUEL , activejdbc , iciql y etc ...

Fondo: Estoy usando la plantilla Spring JDBC, pero eso aún requería que las consultas se escribieran en formato de cadena simple. Aunque no tengo problemas para escribir las consultas directas, me preocupa tener dependencia directa en los nombres de las tablas de la base de datos. No quiero usar ningún marco ORM como Hibernate o JPA / EclipseLink. Necesito el rendimiento en bruto lo más alto posible (IMO, son buenos para más aplicaciones centradas en CRUD). Puedo pagar algunos gastos generales leves para estos DSL solo si eso es un poco (creo que será principalmente concatenaciones de StringBuilder / String)

He considerado usar consultas con nombre externalizadas en algunos xml. Pero solo se trata de evaluar el valor que proporcionan las diferentes bibliotecas de consulta DSL.

Edición: más sobre mis requisitos: quiero saber la comparación de rendimiento entre estos cuando se crea una consulta moderadamente compleja utilizando sus métodos API. Todo lo que necesito es generar una cadena de consulta utilizando cualquiera de estas bibliotecas de consulta DSL y pasarla a la plantilla Spring JDBC. Por lo tanto, quiero saber si la adición de este paso intermedio conlleva una penalización de rendimiento considerable, quiero usar consultas con nombre o crear mi propia biblioteca que solo utiliza StingBuilder o un enfoque similar

actualizar mi experiencia con jOOQ, iciql, QueryDSL:

Aunque no mencioné esto en mi publicación original, también estoy interesado en la facilidad de uso y los gastos generales que necesito tener en mis clases de entidad (como si se necesitaran anotaciones adicionales o implementaciones).

jOOQ:

• Requiere cambiar las propiedades de la entidad a la forma específica de la biblioteca.
• puede devolver cadena de consulta SQL

Iciql:

• la entidad se puede asignar sin cambios o con pequeños cambios (se puede asignar utilizando un total de 3 formas)
• pero con eso se limita a solo seleccionar consultas (para actualizar / eliminar / ... requiere cambios de entidad nuevamente)

QueryDSL:

• se admiten varias formas de vincular entidades con una tabla (además de las formas específicas de la biblioteca, se admiten las anotaciones JPA). Pero necesitamos modificar las entidades al menos
• no hay forma simple / directa de obtener la cadena de consulta

(todas las observaciones son con poco conocimiento que tengo sobre estos; si alguno de estos es incorrecto, corríjalo)

Con todo lo anterior, me quedo con la escritura de consultas con nombre :( Pero como la respuesta de Lukas Eder parece explicarse acerca de mi preocupación por la publicación original (rendimiento), he aceptado la suya.

Answer 1

En las JVM modernas, no debería preocuparse demasiado por la concatenación de cadenas SQL. La verdadera sobrecarga que cualquier capa de abstracción de la base de datos puede producir (en comparación con el tiempo de ida y vuelta relativamente alto de la base de datos y el respaldo), generalmente se debe al almacenamiento en caché de segundo nivel, que se realiza en Hibernate / JPA. O al asignar de manera ineficiente los modelos de objetos a SQL de una manera que el uso de índices o la transformación de consulta general se vuelve imposible.

Comparado con eso, la concatenación de cadenas es realmente insignificante, incluso para construcciones de SQL complejas con varios UNIONs , UNIONs anidados, JOINs , semi-JOINs , anti-JOINs , etc. , ya que te permiten mantener el control sobre tu SQL.

Por otro lado, algunos marcos o modos de uso en esos marcos pueden obtener el conjunto de resultados completo en la memoria. Eso puede causar problemas si sus conjuntos de resultados son grandes, también porque con los genéricos de Java, la mayoría de los tipos primitivos ( int , long , etc.) probablemente se asignan a sus envoltorios correspondientes ( Integer , Long ).

En cuanto a jOOQ (del cual soy el desarrollador), anteriormente he perfilado la biblioteca con YourKit Profiler para la ejecución masiva de consultas. El trabajo masivo siempre se realizó en la base de datos, no en la construcción de consultas. jOOQ utiliza un único StringBuilder para cada consulta. Me imagino (no verificado), que Querydsl y JEQUEL hacen lo mismo ...

En cuanto a iciql , que es una bifurcación de JaQu , podría haber un impacto adicional por el hecho de que utilizan la instrumentación Java para descompilar su sintaxis natural . Pero supongo que eso se puede omitir, si significa demasiado impacto.

Answer 2

No puedo hablar por otros marcos, pero realicé un análisis primitivo del rendimiento para comparar activejdbc y Hibernate. La prueba se realizó en una computadora portátil con 8G RAM, unidad SSD contra MySQL. Tabla de PERSONAS con unas pocas columnas simples y un ID de sustituto PK.

Una prueba fue insertar registros de 50K como objetos, y la otra fue leer los objetos de 50K de la tabla a la vez (en la memoria). En ambas pruebas, ActiveJDBC mostró una mejora del rendimiento del 40% sobre Hibernate. En cualquier caso, las consultas generadas fueron simples inserciones y selecciones, muy parecidas entre sí.

espero que esto ayude,

Igor

Answer 3

También debe mirar MyBatis Statement Builder .

Si bien MyBatis es claramente una tecnología de mapeo, sí tiene un DSL del generador de sentencias que parece estar desacoplado de MyBatis (es decir, que no necesita nada más de MyBatis para usar los constructores ... de manera molesta, no está en su propio contenedor). No me gusta porque utiliza ThreadLocals.