Сравнение Querydsl, jOOQ, JEQUEL, activejdbc, iciql и других DSL запросов

Question

Может кто-нибудь указать мне на некоторые ресурсы о сравнении производительности среди различных библиотек Query DSL, доступных для использования с Java, например: Querydsl , jOOQ , JEQUEL , activejdbc , iciql и т. Д. ..

Справочная информация: Я использую шаблон Spring JDBC, но для этого по-прежнему требовалось, чтобы запросы были записаны в формате простой строки. Хотя у меня нет проблем при написании прямых запросов, но меня беспокоит прямая зависимость от имен таблиц БД. Я не хочу использовать какие-либо рамки ORM, такие как Hibernate или JPA / EclipseLink. Мне нужна максимально высокая исходная производительность (IMO, они хороши для более ориентированных на CRUD приложений). Я могу позволить себе небольшие накладные расходы для этих DSL, только если это немного (я полагаю, это будут в основном конкатенации StringBuilder / String!)

Я рассмотрел использование именованных запросов, выведенных в некоторый xml. Но просто пытаюсь оценить значение, которое предоставляют разные библиотеки Query DSL.

Редактировать: больше по моему требованию: Я хочу знать сравнение производительности между ними при построении умеренно сложного запроса с использованием их методов API. Все, что мне нужно, это сгенерировать строку запроса, используя любую из этих библиотек DSL, и передать ее в шаблон Spring JDBC. Итак, я хочу знать, если добавление этого промежуточного шага влечет за собой значительное снижение производительности, я хочу использовать именованные запросы или создать свою собственную библиотеку, которая просто использует StingBuilder или аналогичный подход

обновление мой опыт работы с jOOQ, iciql, QueryDSL:

Несмотря на то, что я упустил упомянуть об этом в своем первоначальном посте, я также заинтересован в простоте использования и накладных расходах, которые мне нужно иметь в моих классах сущностей (например, если требуются какие-либо дополнительные аннотации или реализации).

jOOQ:

• требует изменения свойств объекта в соответствии с библиотекой
• может вернуть строку SQL-запроса

Iciql:

• сущность может быть сопоставлена ​​без изменений или с небольшими изменениями (может быть сопоставлена ​​всего тремя способами)
• , но при этом он ограничивает только выбор запросов (для обновления / удаления / ... требуется повторное изменение сущности)

QueryDSL:

• несколько способов связать сущности с таблицей (кроме библиотечных, поддерживаются аннотации JPA). но нам нужно изменить сущности как минимум
• нет простого / прямого способа получить строку запроса

(все наблюдения с небольшим знанием, которые у меня есть по этим вопросам; если какие-либо из них неверны, пожалуйста, исправьте)

Учитывая все вышесказанное, я придерживаюсь написания именованных запросов :( Но, как кажется, ответ Лукаса Эдера объясняет мою первоначальную проблему с постом (производительность), я принял его.

Answer 1

В современных JVM вам не стоит слишком беспокоиться о конкатенации строк SQL. Истинные издержки, которые может создать любой уровень абстракции базы данных (по сравнению с относительно высоким временем прохождения туда-обратно и обратно), обычно связаны с кэшированием второго уровня, которое выполняется в Hibernate / JPA. Или путем неэффективного отображения объектных моделей в SQL таким образом, что использование индексов или общего преобразования запросов становится невозможным.

По сравнению с этим конкатенация строк действительно незначительна, даже для сложных конструкций SQL с несколькими UNIONs, вложенными SELECTs, JOINs, semi-JOINs, anti-JOINs и т. Д., Поэтому я предполагаю, что все Платформы, о которых вы упомянули, работают аналогичным образом, поскольку они позволяют вам контролировать SQL.

С другой стороны, некоторые фреймворки или режимы использования в этих фреймворках могут фактически загружать весь набор результатов в память. Это может вызвать проблемы, если ваши результирующие наборы большие, а также потому, что с обобщениями Java большинство примитивных типов (int, long и т. Д.), Вероятно, отображаются в соответствующие им оболочки (Integer, Long).

Что касается jOOQ (из которых я являюсь разработчиком), я ранее профилировал библиотеку с YourKit Profiler для массового выполнения запросов. Основная работа всегда выполнялась в базе данных, а не в построении запросов. jOOQ использует один StringBuilder для каждого запроса. Я предполагаю (не проверено), что QueryDSL и JEQUEL делают то же самое ...

Что касается iciql , который является форком JaQu , то может быть некоторое дополнительное влияние из-за того, что они используют инструментарий Java для декомпиляции своего естественного синтаксиса . Но я думаю, что это может быть опущено, если это означает слишком большое влияние.

Answer 2

Вам также следует взглянуть на MyBatis Statement Builder .

Несмотря на то, что MyBatis, несомненно, является технологией отображения, он имеет DSL-конструктор Statement, который, кажется, отделен отMyBatis (то есть вам больше ничего не нужно от MyBatis, чтобы использовать строителей ... досадно, что это не в его собственной банке).Мне не нравится, потому что он использует ThreadLocals.

Answer 3

Я не могу говорить о других платформах, но я провел примитивный анализ производительности, чтобы сравнить ActiveJDBC и Hibernate.Тест проводился на ноутбуке с 8G RAM, SSD-накопителем против MySQL.Таблица PEOPLE с несколькими простыми столбцами и суррогатным идентификатором PK.

Один из тестов заключался в вставке 50К-записей в качестве объектов, а другой - в считывание 50К-объектов из таблицы одновременно (в памяти).В обоих тестах ActiveJDBC показал улучшение производительности на 40% по сравнению с Hibernate.В любом случае сгенерированные запросы были просто вставлены и выбраны, очень похожи друг на друга.

надеюсь, это поможет,

Игорь

Answer 4

Облегченная библиотека без зависимостей для создания программных SQL-запросов - это OpenHMS SQL Builder библиотека:

https://openhms.sourceforge.io/sqlbuilder/

Доступно как зависимость Maven:

https://mvnrepository.com/artifact/com.healthmarketscience.sqlbuilder/sqlbuilder