Какие знаешь стратегии загрузки данных в Hibernate?

Стратегии загрузки данных в Hibernate

Эффективная работа с ORM зависит от правильной стратегии загрузки связанных данных. Неправильный выбор приводит к проблемам производительности и N+1 queries. Рассмотрю основные стратегии и их применение.

1. Lazy Loading (Ленивая загрузка)

Lazy Loading — отложенная загрузка связанных объектов до момента их реального использования.

Базовая конфигурация

import javax.persistence.*;

@Entity
public class User {
    @Id
    private Long id;
    private String name;
    
    // ✅ Lazy Loading по умолчанию для ToMany
    @OneToMany(mappedBy = "user", fetch = FetchType.LAZY)
    private List<Order> orders;
    
    // ✅ Lazy Loading для ToOne (если явно указать)
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "company_id")
    private Company company;
}

@Entity
public class Order {
    @Id
    private Long id;
    private String description;
    
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "user_id")
    private User user;
}

Использование

public void lazyLoadingExample() {
    User user = userRepository.findById(1L).get();
    System.out.println("User: " + user.getName());  // ✅ SELECT * FROM users
    
    // ❌ LazyInitializationException если session закрыта
    System.out.println("Orders: " + user.getOrders());
    // Происходит SELECT * FROM orders WHERE user_id = 1
}

Проблемы Lazy Loading

// ❌ LazyInitializationException
User user = userRepository.findById(1L).get();
// session закрывается после выхода из транзакции
System.out.println(user.getOrders());  // ОШИБКА!

// ✅ Решение 1: @Transactional для разных методов
@Transactional
public User getUserWithOrders(Long id) {
    User user = userRepository.findById(id).get();
    user.getOrders().size();  // Инициализируем в транзакции
    return user;
}

// ✅ Решение 2: Open Session in View
@Configuration
public class HibernateConfig {
    @Bean
    public OpenSessionInViewFilter openSessionInViewFilter() {
        return new OpenSessionInViewFilter();
    }
}

2. Eager Loading (Безотлагательная загрузка)

Eager Loading — загружает связанные данные сразу при загрузке основного объекта.

@Entity
public class User {
    @Id
    private Long id;
    private String name;
    
    // ✅ Eager Loading — сразу загружаем заказы
    @OneToMany(mappedBy = "user", fetch = FetchType.EAGER)
    private List<Order> orders;
}

public void eagerLoadingExample() {
    User user = userRepository.findById(1L).get();
    // ✅ В одном запросе загружены и пользователь, и его заказы
    System.out.println("User: " + user.getName());
    System.out.println("Orders: " + user.getOrders());  // Нет доп запросов
}

Проблемы Eager Loading

// ❌ Картезиево произведение при JOIN
@Entity
public class User {
    @OneToMany(fetch = FetchType.EAGER)
    private List<Order> orders;  // 10 заказов
    
    @OneToMany(fetch = FetchType.EAGER)
    private List<Review> reviews;  // 5 отзывов
}
// Результат: 10 × 5 = 50 дублей записи User!

// ❌ Загружаем ненужные данные
User user = userRepository.findById(1L).get();
// Если нам нужно только name, мы всё равно загружаем все заказы

3. FETCH JOIN (явное указание)

FETCH JOIN — явное указание в JPQL/HQL запросе какие связи загружать.

import org.springframework.data.jpa.repository.Query;

public interface UserRepository extends JpaRepository<User, Long> {
    
    // ✅ FETCH JOIN загружает заказы в одном запросе
    @Query("SELECT u FROM User u LEFT JOIN FETCH u.orders WHERE u.id = ?1")
    User findByIdWithOrders(Long id);
    
    // ✅ Можем загружать несколько связей
    @Query("SELECT u FROM User u " +
           "LEFT JOIN FETCH u.orders " +
           "LEFT JOIN FETCH u.company " +
           "WHERE u.id = ?1")
    User findByIdWithOrdersAndCompany(Long id);
    
    // ✅ Для списков
    @Query("SELECT u FROM User u LEFT JOIN FETCH u.orders")
    List<User> findAllWithOrders();
}

Использование

public void fetchJoinExample() {
    // ✅ Один SELECT с JOIN загружает всё
    User user = userRepository.findByIdWithOrders(1L);
    System.out.println("Orders: " + user.getOrders());
    // SQL: SELECT u.* FROM users u 
    //      LEFT JOIN orders o ON u.id = o.user_id
    //      WHERE u.id = 1
}

4. Entity Graph (для Spring Data JPA)

Entity Graph — более гибкий способ указания стратегии загрузки.

import org.springframework.data.jpa.repository.EntityGraph;

public interface UserRepository extends JpaRepository<User, Long> {
    
    // ✅ Загружаем orders и company
    @EntityGraph(attributePaths = {"orders", "company"})
    Optional<User> findById(Long id);
    
    // ✅ Кастомный граф
    @EntityGraph(
        attributePaths = {"orders", "orders.items", "company"}
    )
    List<User> findAll();
    
    // ✅ С предикатом
    @EntityGraph(attributePaths = {"orders"})
    User findByName(String name);
}

Определение именованных графов

import org.hibernate.annotations.NamedEntityGraph;

@Entity
@NamedEntityGraph(
    name = "user-with-orders",
    attributeNodes = {
        @NamedAttributeNode("orders"),
        @NamedAttributeNode(value = "company")
    }
)
public class User {
    @Id
    private Long id;
    private String name;
    
    @OneToMany(mappedBy = "user")
    private List<Order> orders;
    
    @ManyToOne
    private Company company;
}

// Использование именованного графа
public interface UserRepository extends JpaRepository<User, Long> {
    @EntityGraph(value = "user-with-orders")
    Optional<User> findById(Long id);
}

5. Batch Fetching

Batch Fetching — загружает ленивые коллекции батчами, не одну за раз.

import org.hibernate.annotations.BatchSize;

@Entity
public class User {
    @Id
    private Long id;
    private String name;
    
    // ✅ Загружаем в батчах по 10 пользователей
    @OneToMany(mappedBy = "user", fetch = FetchType.LAZY)
    @BatchSize(size = 10)
    private List<Order> orders;
}

public void batchFetchingExample() {
    List<User> users = userRepository.findAll();  // SELECT * FROM users
    
    for (User user : users) {
        // ❌ Без @BatchSize: N SELECT запросов
        // ✅ С @BatchSize: N/10 SELECT запросов
        System.out.println(user.getOrders());
    }
}

Глобальная конфигурация

# application.properties
spring.jpa.properties.hibernate.default_batch_fetch_size=10

6. Subselect Fetching

Subselect — загружает коллекции подзапросом вместо IN clause.

import org.hibernate.annotations.Fetch;
import org.hibernate.annotations.FetchMode;

@Entity
public class User {
    @Id
    private Long id;
    private String name;
    
    // ✅ Загружает заказы подзапросом
    @OneToMany(mappedBy = "user", fetch = FetchType.LAZY)
    @Fetch(FetchMode.SUBSELECT)
    private List<Order> orders;
}

public void subselectFetchingExample() {
    List<User> users = userRepository.findAll();  // SELECT * FROM users
    
    // ✅ Один SELECT для всех заказов вместо N
    for (User user : users) {
        System.out.println(user.getOrders());
    }
    // SQL: SELECT o.* FROM orders o WHERE o.user_id IN 
    //      (SELECT id FROM users WHERE ...)
}

7. DTO Projections

DTO — загружаем только нужные поля, не весь объект.

public interface UserDTO {
    Long getId();
    String getName();
    int getOrderCount();
}

public interface UserRepository extends JpaRepository<User, Long> {
    
    // ✅ Загружаем только нужные данные
    @Query("SELECT new com.example.dto.UserDTO(u.id, u.name, SIZE(u.orders)) " +
           "FROM User u")
    List<UserDTO> findAllDTOs();
    
    // ✅ Или interface projection
    @Query("SELECT u.id as id, u.name as name, SIZE(u.orders) as orderCount " +
           "FROM User u")
    List<UserDTO> findAllProjections();
}

8. N+1 Query Problem и решения

Проблема

// ❌ N+1 queries
List<User> users = userRepository.findAll();  // 1 query
for (User user : users) {
    System.out.println(user.getOrders());  // N queries (по одному на юзера)
}
// Итого: 1 + N queries!

Решение 1: FETCH JOIN

@Query("SELECT u FROM User u LEFT JOIN FETCH u.orders")
List<User> findAllWithOrders();

// Использование
List<User> users = userRepository.findAllWithOrders();  // 1 query с JOIN
for (User user : users) {
    System.out.println(user.getOrders());  // Нет доп запросов
}

Решение 2: Entity Graph

@EntityGraph(attributePaths = {"orders"})
List<User> findAll();

Решение 3: Batch Fetching

@BatchSize(size = 20)
private List<Order> orders;

Сравнение стратегий

Лучшие практики

// ✅ По умолчанию: Lazy Loading
@OneToMany(fetch = FetchType.LAZY)
private List<Order> orders;

// ✅ Используй FETCH JOIN в запросах
@Query("SELECT u FROM User u LEFT JOIN FETCH u.orders WHERE u.id = ?1")
User findByIdWithOrders(Long id);

// ✅ Для списков: Entity Graph или Batch Size
@EntityGraph(attributePaths = {"orders"})
List<User> findAll();

// ✅ Проверяй SQL логи
// spring.jpa.show-sql=true
// spring.jpa.properties.hibernate.format_sql=true

// ❌ Избегай Eager для ToMany отношений
// ❌ Не загружай всё подряд
// ❌ Не игнорируй N+1 queries

Мониторинг N+1 queries

import org.hibernate.engine.transaction.internal.TransactionImpl;

// Логируй все SQL запросы
// application.properties
logging.level.org.hibernate.SQL=DEBUG
logging.level.org.hibernate.type.descriptor.sql.BasicBinder=TRACE
spring.jpa.show-sql=true
spring.jpa.properties.hibernate.format_sql=true

// Или программно
SessionFactory sf = entityManagerFactory.unwrap(SessionFactory.class);
Statistics statistics = sf.getStatistics();
statistics.setStatisticsEnabled(true);

Заключение

Правильная стратегия загрузки критична для производительности:

1. По умолчанию → Lazy Loading
2. Для конкретных запросов → FETCH JOIN
3. Для переиспользуемых сценариев → Entity Graph
4. Для списков → Batch Fetching
5. Когда память важна → DTO Projections

Ключевое правило: Избегай N+1 queries, проверяй логи, выбирай стратегию в зависимости от сценария, а не по умолчанию.