entityManager.createQuery () отнимает много времени для построения запроса и привязки параметров. Производительность влияет - PullRequest
Новая
       97

entityManager.createQuery () отнимает много времени для построения запроса и привязки параметров. Производительность влияет

0 голосов
/ 27 марта 2020

Мы используем запрос критериев Spring JPA (javax.persistence.criteria.CriteriaQuery) для извлечения данных из базы данных. Мы используем javax.persistence.criteria.Predicate для создания предикатов. У нас есть 1500 предикатов «ИЛИ» в одном запросе. И каждый предикат имеет 6 предикатов AND. 

SELECT (*) FROM TABLE_ABC as T1 WHERE  (t1.column1 = 'c11' AND
   t1.column2 = 'c12' AND t1.column3 = 'c13' AND t1.column4 = 'c14' AND
   t1.column5 = 'c15') 
  OR 
   (t1.column1 = 'c21' AND t1.column2 = 'c22'
   AND t1.column3 = 'c23' AND t1.column4 = 'c24' AND t1.column5 = 'c25')
   OR 
    (t1.column1 = 'c31' AND t1.column2 = 'c32'
   AND t1.column3 = 'c33' AND t1.column4 = 'c34' AND t1.column5 = 'c35').....

Раньше мы использовали «org.hibernate.Criteria» и использовали «Conjuction» и «Disjunction» для построения одного и того же запроса. Этот подход работал эффективно. Поскольку "org.hibernate.Criteria" ограничен, мы переходим к пакету запросов javax-attribute. Мы сталкиваемся с большой деградацией производительности. Детализация журналов показывает, что время расходуется больше на шаге

=> entityManager.createQuery (), который выполняет следующие операции

  1. CriteriaCompiler.compile
  2. CriteriaQueryImpl $ 1.buildCompiledQuery
  3. CriteriaCompiler $ 1 $ 1.bind

Эти операции занимают больше времени.

Есть ли решение для ускорения выполнения ? Является ли «javax.persistence.criteria.CriteriaQuery» способом продвижения вперед?

Пожалуйста, помогите здесь!

Пожалуйста, см. Код ниже: 

@Transactional(propagation = Propagation.REQUIRES_NEW, isolation = Isolation.READ_COMMITTED)
public getData(List<DataDAO> dataReqList) {
{

    CriteriaBuilder builder = em.getCriteriaBuilder();
    CriteriaQuery<DataReq> criteriaQuery = builder.createQuery(DataReq.class);
    Root<DataReq> dataReqRoot = criteriaQuery.from(DataReq.class);
    Predicate[] predicateArr = new Predicate[dataReqList.size()];

    for (DataDAO dataReq : dataReqList) {

                    predicateArr[i] = builder.and(
                            builder.equal(dataReqRoot.get(TEST_S), dataReq.getS()),
                            builder.equal(dataReqRoot.get(TEST_T2), dataReq.getT2()),
                            builder.equal(dataReqRoot.get(K1), dataReq.getK1()),
                            builder.equal(dataReqRoot.get(K2), dataReq.getK2()),
                            builder.equal(dataReqRoot.get(TEST_P), dataReq.getP()),
                            builder.equal(dataReqRoot.get(TEST_T1),
                                    dataReq.getT1(),
                            builder.equal(dataReqRoot.get(TEST_I), dataReq.getI()));

                            i++;
    }

    List<Data> dataResultList = getResultList(builder, criteriaQuery, predicateArr);

}

private List<Data> getResultList(CriteriaBuilder builder,
            CriteriaQuery<DataReq> criteriaQuery, Predicate[] predicateArr) {
    criteriaQuery.where(builder.or(predicateArr));
    TypedQuery<DataReq> query = entityManager.createQuery(criteriaQuery);

    List<DataReq> dataReqList = null;
    try {

        dataReqList = query.getResultList();
    } catch(Exception e) {
    ...
    }

    return convertToData(dataReqList);

}

Тот же запрос с «org.hibernate.Criteria» и использованием «Conjuction» и «Disjunction» работает очень эффективно в миллисекундах.

1 Ответ

0 голосов
/ 29 марта 2020

Для контекста, в зависимости от базы данных, которую вы используете, это похоже на динамический предикат c IN с выражениями значения строки. Если поддерживается, вы также можете написать: 

WHERE (t1.column1, t1.column2, t1.column3, t1.column4, t1.column5, t1.column6) IN (
  ('c11', 'c12', 'c13', 'c14', 'c15', 'c16'),
  ('c21', 'c22', 'c23', 'c24', 'c25', 'c26'),
  ...
)

Такие длинные списки IN превратятся в проблемы не только в клиентских библиотеках, которые генерируют динамические c SQL, но и на стороне сервера. Вы упомянули переменные связывания, возможно, старый используемый вами API все-таки не использовал переменные связывания, а встроил все значения в запрос. Я видел, что это намного лучше в Oracle для больших наборов параметров, так что это один из случаев, когда встроенные значения могут быть лучше, чем переменные связывания .

Так как вы ' Используя Hibernate, вы можете попробовать включить 

<property name="hibernate.criteria.literal_handling_mode" value="bind"/>

См. HHH-9576 и этот ответ

Возможно, даже лучшее решение с использованием массивов

Вышеприведенное (возможно) поможет восстановить предыдущую производительность, с которой вы столкнулись, но в зависимости от размера списка IN могут быть и лучшие решения. Я написал в блоге об альтернативе, в которой вы можете использовать массивы вместо отдельных значений привязки, в случае, если вы используете Oracle или PostgreSQL.

Возможно, даже лучшее решение, использующее временные таблицы

Другой вариант, который я часто видел, - это использовать временные таблицы в форме (при условии Oracle): 

CREATE GLOBAL TEMPORARY TABLE predicates (
  column1 VARCHAR2(100),
  column2 VARCHAR2(100), 
  column3 VARCHAR2(100), 
  column4 VARCHAR2(100), 
  column5 VARCHAR2(100), 
  column6 VARCHAR2(100)
)

И затем, перед выполнением запроса , пакетно вставьте все различные значения предикатов в эту таблицу, а затем наполовину соедините ее: 

WHERE (t1.column1, t1.column2, t1.column3, t1.column4, t1.column5, t1.column6) IN (
  SELECT column1, column2, column3, column4, column5, column6
  FROM predicates
)

Если у вас нет временных таблиц, вы можете вместо этого попробовать обычные таблицы и добавить в нее столбец транзакции_id, очистка содержимого вручную после ваших запросов.

...