Использование @NamedEntityGraph для более избирательной загрузки объектов JPA в сценариях N + 1

Проблема N + 1 является распространенной проблемой при работе с решениями ORM. Это происходит, когда вы устанавливаете fetchType для некоторого отношения @OneToMany как lazy, чтобы загружать дочерние объекты только при доступе к Set / List. Предположим, у нас есть сущность Customer с двумя отношениями: набор заказов и набор адресов для каждого клиента.

Чтобы загрузить всех клиентов, мы можем выполнить следующую инструкцию JPQL и затем загрузить все заказы для каждого клиента:

Hibernate 4.3.5 (поставляется с JBoss AS Wildfly 8.1.0CR2) сгенерирует из него следующую серию операторов SQL только для двух (!) Клиентов в базе данных:

Как видим, первый запрос выбирает всех клиентов из таблицы CustomerEntity. Следующие два выбора выбирают, а затем заказы для каждого клиента, которые мы загрузили в первом запросе. Когда у нас будет 100 клиентов вместо двух, мы получим 101 запрос. Один начальный запрос для загрузки всех клиентов, а затем для каждого из 100 клиентов дополнительный запрос для заказов. Вот почему эта проблема называется N + 1.

Распространенная идиома для решения этой проблемы — заставить ORM генерировать запрос внутреннего соединения. В JPQL это можно сделать с помощью предложения JOIN FETCH, как показано в следующем фрагменте кода:

Как и ожидалось, ORM теперь генерирует внутреннее соединение с таблицей OrderEntity, и для этого требуется только один оператор SQL для загрузки всех данных:

В ситуациях, когда вы знаете, что вам придется загружать все заказы для каждого клиента, предложение JOIN FETCH минимизирует количество операторов SQL с N + 1 до 1. Это, конечно, связано с недостатком, который вы теперь переносите для всех заказов одного покупатель данные о клиенте снова и снова (из-за дополнительных столбцов клиента в запросе)

Спецификация JPA представляет версию 2.1 так называемых NamedEntityGraphs. Эта аннотация позволяет вам описать график, который запрос JPQL должен загружать более подробно, чем может сделать предложение JOIN FETCH, и, следовательно, это еще одно решение проблемы N + 1. В следующем примере демонстрируется NamedEntityGraph для нашего объекта клиента, который должен загружать только имя клиента и его заказы. Заказы описаны в подграфе ordersGraph более подробно. Здесь мы видим, что мы хотим загрузить только поля id и campaignId заказа.

NamedEntityGraph указывается в качестве подсказки для запроса JPQL после его загрузки через EntityManager с использованием его имени:

Hibernate поддерживает аннотацию @NamedEntityGraph начиная с версии 4.3.0.CR1 и создает следующую инструкцию SQL для запроса JPQL, показанного выше:

Мы видим, что Hibernate не выдает N + 1 запросов, но вместо этого аннотация @NamedEntityGraph вынуждает Hibernate загружать заказы на левое внешнее соединение. Это, конечно, тонкое отличие от предложения FETCH JOIN, где Hibernate создал внутреннее соединение. Левое внешнее объединение также будет загружать клиентов, для которых нет заказа, в отличие от предложения FETCH JOIN, где мы будем загружать только клиентов, у которых есть хотя бы один заказ.

Интересно также, что Hibernate загружает больше, чем указанные атрибуты для таблиц CustomerEntity и OrderEntity. Поскольку это противоречит спецификации @NamedEntityGraph (раздел 3.7.4), я создал для этого проблему JIRA .

Вывод

Мы видели, что в JPA 2.1 у нас есть два решения для проблемы N + 1: мы можем либо использовать предложение FETCH JOIN для быстрого извлечения отношения @OneToMany, которое приводит к внутреннему объединению, либо мы можем использовать функцию @NamedEntityGraph, которая позволяет мы указываем, какое отношение @OneToMany загрузить через левое внешнее соединение.