Java: fill the gaps

Как найти и починить in-memory пагинацию в Spring Data JPA

N+1 - самая известная проблема в Spring Data JPA/Hibernate, но не единственная. В этом посте расскажу об in-memory пагинации.

В чем суть.

Пагинацию логично делать на уровне БД с помощью limit и offset. Но иногда Hibernate делает пагинацию на стороне клиента. Выгружает все записи из память, выбирает из них заданное количество и возвращает.

Чем плохо:
❌ Запрос выполняется долго, тк по сети передается куча данных
❌ Забивается оперативная память. В худшем случае получаем OutOfMemoryError

Проблема возникает при сочетании предварительной загрузки связных сущностей и Pageable.

Простой пример. У постов есть комментарии со связью OneToMany:

@Entity
public class Post {
   @OneToMany
   private List<Comment> comments;
}

Мы хотим получить 5 постов с комментариями. Чтобы избежать N+1, загружаем комментарии через EntityGraph:

@EntityGraph
List<Post> findAllPosts(PageRequest.of(0, 5));

Метод findAllPosts вернёт 5 постов, как мы и просили. Но в логах увидим SQL запрос без лимитов, в память загрузятся все посты.

Как найти места со скрытой пагинацией?

Hibernate пишет в консоль ворнинг, который легко пропустить. Лучше сделать так:
🌷 Ставим свойство

spring.jpa.properties.hibernate.query.fail_on_pagination_over_collection_fetch=true

🌷 Запускаем интеграционные тесты
🌷 Смотрим, где падают исключения

Как починить скрытую пагинацию?

Способов много, самое простое - добавить над списком @BatchSize. Либо поставить свойство

spring.jpa.properties.hibernate.default_batch_fetch_size=50

Тогда BatchSize будет по умолчанию применяться для всех списков.
Про другие решения и перфоманс читайте в этой статье на Хабре

Зачем Hibernate использует in-memory пагинацию?

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

Сразу возникает вопрос. Почему в таких случаях не сделать 2 запроса?
▫️ select * from posts limit 5;
▫️ Извлечь айдишники постов
▫️ select * from comments where post_id in (?,?,?,?,?);
▫️ Связать сущности

Решение выглядит просто, и вариант с BatchSize примерно так и работает. Почему оно не используется по умолчанию - непонятно.

Hibernate - яркий пример “протекающих абстракций”. Куча нюансов и проблем, о которых нужно знать. В документации по поводу in-memory панинации есть такая фраза:

Possibility of terrible performance is left as a problem for the client to avoid.
Проблема ужасного перформанса - это проблема клиента.
Вся суть хибернейта🤌

По возможности не тащите его в проект. Есть более удобные и прозрачные альтернативы. Например, Spring Data JDBC💚

🔥159👍71❤31👎5

14.9K views06:05