Comparación de Querydsl, jOOQ, JEQUEL, activejdbc, activql y otros DSL de consulta

Question

Comparación de Querydsl, jOOQ, JEQUEL, activejdbc, activql y otros DSL de consulta

Puede que alguien me apunte a algunos recursos acerca de la comparación de rendimiento entre los diferentes DSL de Consultas bibliotecas disponibles para el uso con Java, como: Querydsl, jOOQ, JEQUEL, activejdbc, iciql y etc...

Background: Estoy usando plantilla Spring JDBC, pero eso aún requería que las consultas se escribieran en formato de cadena simple. Aunque no tengo problemas por escrito las consultas directas, pero me refiero a tener dependencia directa de los nombres de tabla de la base de datos. No quiero usar ningún framework OR como Hibernate o JPA / EclipseLink. Necesito el rendimiento bruto lo más alto posible (IMO, son buenos para aplicaciones más centradas en CRUD). Puedo permitirme algunos gastos generales leves para estos DSLs solo si eso es un poco (creo que será sobre todo StringBuilder/Cadenas concatenaciones!)

He considerado usar consultas con nombre externalizadas en algún xml. Pero sólo tratando de evalúe el valor que proporcionan las diferentes bibliotecas DSL de consulta.

Editar: más sobre mi requerimiento: Quiero conocer la comparación de rendimiento entre estos al construir una consulta moderadamente compleja utilizando sus métodos API. Todo lo que necesito es generar una cadena de consulta usando cualquiera de estas bibliotecas DSL de consulta y pasarla a la plantilla Spring JDBC. Por lo tanto, quiero saber si la adición de este paso intermedio incurre en una penalización de rendimiento considerable, quiero usar consultas con nombre o construir mi biblioteca propia que solo utiliza StingBuilder o enfoque similar

actualizar mi experiencia con jOOQ, Querql, QueryDSL:

Aunque me perdí de mencionar esto en mi post original, también estoy interesado en la facilidad de uso y la sobrecarga que necesito tener en mis clases de entidad (como si se requieren anotaciones o implementaciones adicionales).

JOOQ:

requiere cambiar las propiedades de la entidad a la forma específica de la biblioteca
puede volver Cadena de consulta SQL

{[0] }qlQl:

la entidad se puede mapear sin cambios o con pocos cambios (se puede mapear usando un total de 3 formas)
pero con eso se limita a solo seleccionar consultas (para update/delete/... requiere cambios de entidad de nuevo)

QueryDSL:

múltiples formas de enlazar entidades con tabla (además de las formas específicas de la biblioteca, se admite el uso de anotaciones JPA). pero necesitamos modificar las entidades al menos
no hay una manera simple / directa de obtener la cadena de consulta

(todas las observaciones son con poco conocimiento que tengo sobre estas; si alguna de estas son incorrectas, por favor corrija)

Con todo lo anterior, me quedo con escribir consultas con nombre :( Pero como la respuesta de Lukas Eder parece explicar sobre mi preocupación original del post (rendimiento), he aceptado la suya.

26

java performance spring-jdbc querydsl jooq

Author: Lukas Eder, 2011-08-30

Source

3 answers

También debe mirar MyBatis Statement Builder .

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

6

Author: Adam Gent,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-02-05 10:37:46

No puedo hablar de otros frameworks, pero realicé un análisis primitivo de rendimiento para comparar ActiveJDBC e Hibernar. La prueba fue en una computadora portátil con 8G RAM, unidad SSD contra MySQL. Gente de la tabla con algunas columnas simples y un sustituto ID PK.

Una prueba era insertar registros 50K como objetos, y la otra era leer los objetos 50K de la tabla a la vez (en memoria). En ambas pruebas ActiveJDBC mostró una mejora del rendimiento del 40% sobre la Hibernación. En cualquier caso, el las consultas generadas eran simples insertar y seleccionar, muy similares entre sí.

Espero que esto ayude,

Igor

2

Author: ipolevoy,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-09-01 22:44:02

score 27 · Accepted Answer

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 a la base de datos y viceversa), generalmente se debe al almacenamiento en caché de segundo nivel, que se realiza en Hibernate/JPA. O mediante la asignación ineficiente de modelos de objetos a SQL de una manera que el uso de índices o transformación de consulta general se vuelve imposible.

Comparado con eso, la concatenación de cadenas es realmente insignificante, incluso para construcciones SQL complejas con varios UNIONs, anidados SELECTs, JOINs, semi-JOINs, anti-JOINs, etc, así que supongo que todos los frameworks que mencionaste funcionan de manera similar, ya que te permiten mantener el control sobre tu SQL.

Por otro lado, algunos frameworks o modos de uso en esos frameworks pueden traer todo el conjunto de resultados a 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 asignen a sus envoltorios correspondientes(Integer, Long).

En cuanto a jOOQ (del cual soy el desarrollador), previamente 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...

Como para iql , que es una bifurcación de JaQu , podría haber algún impacto adicional por el hecho de que utilizan instrumentación Java para descompilar su sintaxis natural. Pero supongo que se puede omitir, si significa demasiado impacto.