Самый эффективный способ массового выбора из таблицы с миллионными записями - PullRequest
0 голосов
/ 19 февраля 2019

Я заинтересован в получении и выполнении некоторой обработки для всех сущностей A, возвращаемых запросом в форме:

 SELECT * FROM A a WHERE a.id not in (select b.id from B)

Где A является «сложной» сущностью в том смысле, что она наследуется (InheritanceTyped.Joined) из других сущностей, а некоторые из его атрибутов являются другими сущностями (@OneToOne и @ManyToOne).

Самому запросу для получения результатов требуется несколько минут, поэтому мое желание выполнить его как можно меньше.

Вот различные подходы, которые я пытался получить как можно эффективнее для этих элементов A:

  1. Пагинация с использованием setFirstResult / setMaxResults Делайте работу, но довольномедленно, поскольку кажется, что запрос выполняется каждый раз (около 50 обработанных элементов в секунду)
  2. Получение идентификаторов сначала, объекты A затем Сохранение всех идентификаторов в памяти выполнимо, поэтомуЯ выполняю один раз

    SELECT a.id FROM A a WHERE a.id not in (select b.id from B)
    

, а затем select a from A a WHERE a.id= :id, что происходит относительно быстро при индексации столбца id.В настоящее время это наиболее эффективное решение (около 100 обработанных элементов в секунду)

Использование ScollableResults У меня были большие надежды с этим решением, но в итоге оно оказалось медленнее, чем другие альтернативы, в результате чего я обработал около 20 элементов в секунду ...

Как неофит, я не знаю, какие еще варианты исследовать, или я сделал что-то не так в любой из моих попыток.

Отсюда и мои вопросы:

  1. Существуют ли ( фактически ) другие подходы для эффективного решения такого рода проблем?
  2. Это нормально, что ScrollableResults работали так плохо?Есть ли что-то, на что я должен был обратить внимание при реализации этого решения?

РЕДАКТИРОВАТЬ: Вот план выполнения execution plan

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...