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

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

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

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

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

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

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

jOOQ:

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

Iciql:

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

QueryDSL:

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

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

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

ОТВЕТЫ

Ответ 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 для декомпиляции их естественного синтаксиса . Но я думаю, что это можно опустить, если это означает слишком большое влияние.

Ответ 2

Вы также должны посмотреть MyBatis Statement Builder.

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

Ответ 3

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

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

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

Игорь