Comparaison des requêtes DSL de Querydsl, jOOQ, JEQUEL, activejdbc, iciql et autres
Quelqu'un peut-il m'indiquer des ressources sur la comparaison des performances entre les différentes bibliothèques Query DSL pouvant être utilisées avec Java, telles que:Querydsl,jOOQ,JEQUEL,activejdbc,iciqlet etc ...
Background: J'utilise le modèle Spring JDBC, mais cela nécessitait encore que les requêtes soient écrites au format chaîne simple. Bien que l’écriture des requêtes directes ne me pose pas de problème, je crains toutefois une dépendance directe aux noms de table de base de données. Je ne souhaite utiliser aucun framework ORM comme Hibernate ou JPA/EclipseLink. J'ai besoin de performances brutes aussi élevées que possible (IMO, elles sont bonnes pour les applications plus centrées sur CRUD). Je ne peux me permettre un léger surcoût pour ces DSL que si c'est un peu (je crois que ce sera surtout des concaténations StringBuilder/String!)
J'ai envisagé d'utiliser des requêtes nommées externalisées dans certains fichiers XML. Mais nous essayons simplement d’évaluer la valeur fournie par les différentes bibliothèques Query DSL.
Edit: plus sur mon exigence: _ Je souhaite connaître la comparaison des performances entre ceux-ci lors de la création d'une requête moyennement complexe à l'aide de leurs méthodes API. Tout ce dont j'ai besoin est de générer une chaîne de requête à l'aide de l'une de ces bibliothèques de requêtes DSL et de la transmettre au modèle Spring JDBC. Je souhaite donc savoir si l’ajout de cette étape intermédiaire entraîne des pertes de performances considérables. Je souhaite utiliser des requêtes nommées ou créer ma propre bibliothèque utilisant uniquement StingBuilder ou une approche similaire.
update _ mon expérience avec jOOQ, iciql, QueryDSL:
Même si je n’ai pas mentionné cela dans mon message d’origine, je suis aussi très intéressé par la facilité d’utilisation et les frais généraux que je dois avoir dans mes classes d’entités (comme si d’autres annotations ou implémentations étaient nécessaires).
jOOQ:
- nécessite de changer les propriétés de l'entité à la manière spécifique de la bibliothèque
- peut renvoyer une chaîne de requête SQL
Iciql:
- l'entité peut être mappée avec peu ou pas de modifications (peut être mappée de 3 façons au total)
- mais avec cela, il se limite à sélectionner uniquement des requêtes (pour mettre à jour/supprimer/... nécessite à nouveau des modifications d'entité)
QueryDSL:
- plusieurs façons de lier des entités à une table (autres que les méthodes spécifiques à la bibliothèque, l'utilisation d'annotations JPA est prise en charge). mais nous devons modifier les entités au moins
- pas de moyen simple/direct pour obtenir la chaîne de requête
(Toutes les observations ont peu de connaissances, mais corrigez s'il y en a.)
Avec tout ce qui précède, je reste fidèle à l’écriture de requêtes nommées :( Mais comme la réponse de Lukas Eder semble expliquer au sujet de mon post d’origine, j’ai accepté le sien.
Dans les JVM modernes, vous ne devriez pas trop vous préoccuper de la concaténation de chaînes SQL. La surcharge réelle que toute couche d'abstraction de base de données peut produire (par rapport au temps d'aller-retour relativement long pour la base de données) est généralement due à la mise en cache de second niveau, effectuée dans Hibernate/JPA. Ou en mappant de manière inefficace les modèles d'objet sur SQL d'une manière telle que l'utilisation d'index ou la transformation de requête générale devient impossible.
Par rapport à cela, la concaténation de chaînes est vraiment négligeable, même pour les constructions SQL complexes avec plusieurs UNIONs, imbriqués SELECTs, JOINs, semi-JOINs, anti-JOINs, etc. Je suppose que tous les frameworks que vous avez mentionnés fonctionnent de manière similaire vous gardez le contrôle de votre SQL.
D'autre part, certains cadres ou modes d'utilisation de ces cadres peuvent en réalité extraire l'ensemble du résultat en mémoire. Cela peut poser problème si vos jeux de résultats sont volumineux, notamment parce que, avec les génériques de Java, la plupart des types primitifs (int, long, etc.) sont probablement mappés vers leurs wrappers correspondants (Integer, Long).
En ce qui concerne jOOQ (dont je suis le développeur), j'ai déjà décrit la bibliothèque avec YourKit Profiler pour l'exécution de requêtes volumineuses. Le travail en bloc a toujours été effectué dans la base de données et non dans la construction de la requête. jOOQ utilise une seule variable StringBuilder pour chaque requête. J'imagine (non vérifié), que QueryDSL et JEQUEL fais la même chose ...
En ce qui concerne iciql , qui est une fourchette de JaQu , le fait qu’ils utilisent l’instrumentation Java pour décompiler leur syntaxe natural . Mais je suppose que cela peut être omis, si cela signifie trop d'impact.
Vous devriez également consulter MyBatis Statement Builder .
Bien que MyBatis soit clairement une technologie de cartographie, elle possède un DSL de générateur d’informations qui semble être découplé de MyBatis (c’est-à-dire que vous n’avez besoin de rien d’autre de MyBatis pour utiliser les constructeurs ... ennuyeusement, ce n’est pas dans son propre récipient). Je n'aime pas ça parce qu'il utilise ThreadLocals.
Je ne peux pas parler pour d'autres frameworks, mais j'ai effectué une analyse primitive des performances pour comparer ActiveJDBC et Hibernate. Le test était sur un ordinateur portable avec 8G de RAM, lecteur SSD contre MySQL. Table PEOPLE avec quelques colonnes simples et un identifiant de substitution PK.
Un test consistait à insérer 50K enregistrements en tant qu'objets et l'autre à lire les objets de 50K à partir d'une table à la fois (en mémoire). Dans les deux tests, ActiveJDBC a montré une amélioration des performances de 40% par rapport à Hibernate. Dans les deux cas, les requêtes générées étaient de simples insertions et sélections, se ressemblant beaucoup.
j'espère que cela t'aides,
Igor
Une bibliothèque légère sans dépendance pour la création de requêtes SQL par programme est le OpenHMS SQL Builder bibliothèque:
https://openhms.sourceforge.io/sqlbuilder/
Disponible en tant que dépendance Maven:
https://mvnrepository.com/artifact/com.healthmarketscience.sqlbuilder/sqlbuilder