Какъв е проблемът N+1 в Hibernate и как може да бъде…

Проблемът N+1 в Hibernate възниква при извличане на данни, когато за получаване на родителските обекти се изпълнява един заявка, а след това за всеки дете обект (или колекция от дете обекти) се изпълнява отделна заявка. Това води до N+1 заявки към базата данни, където N е броят на родителските обекти, вместо оптимална една заявка или няколко с обединения.

Пример за сценарий с проблема N+1:

Да предположим, че имаме класове Author и Book, където автор може да има много книги.

// Автор ентитет
@Entity
public class Author {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String name;

    @OneToMany(mappedBy = "author", fetch = FetchType.LAZY) // LAZY fetch по подразбиране за колекции
    private List<Book> books;

    // гетъри и сетъри
}

// Книга ентитет
@Entity
public class Book {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String title;

    @ManyToOne
    private Author author;

    // гетъри и сетъри
}

Ако искаме да изведем всички автори и имената на техните книги:

Session session = sessionFactory.openSession();
List<Author> authors = session.createQuery("FROM Author", Author.class).list(); // 1 заявка към Author

for (Author author : authors) {
    System.out.println("Author: " + author.getName());
    for (Book book : author.getBooks()) { // N заявки към Book (по една за всеки автор)
        System.out.println("- Book: " + book.getTitle());
    }
}
session.close();

В този пример:

Изпълнява се една заявка за получаване на всички Author.
След това във всеки цикъл за всеки Author се изпълнява отделна заявка за зареждане на колекцията books. Ако имаме 100 автори, ще има 100 допълнителни заявки към таблицата Book. Общо 1 (за авторите) + 100 (за книгите) = 101 заявки.

Решения на проблема N+1:

Използване на JOIN FETCH в JPQL/HQL: Явно зарежда свързаните същности в една заявка.

Session session = sessionFactory.openSession();
List<Author> authors = session.createQuery("SELECT DISTINCT a FROM Author a JOIN FETCH a.books", Author.class).list(); // Зарежда Author и техните Books в една заявка

for (Author author : authors) {
    System.out.println("Author: " + author.getName());
    for (Book book : author.getBooks()) {
        System.out.println("- Book: " + book.getTitle());
    }
}
session.close();

Операторът DISTINCT се използва за предотвратяване на дублиране на редове в резултата.

Промяна на типа на зареждане на EAGER: Промяна на fetch = FetchType.LAZY (по подразбиране за колекции) на fetch = FetchType.EAGER.
```
@Entity
public class Author {
    // ... други полета
    @OneToMany(mappedBy = "author", fetch = FetchType.EAGER) // EAGER fetch
    private List<Book> books;
    // ... гетъри и сетъри
}
```
Не се препоръчва за колекции или обекти с голям брой връзки, тъй като може да доведе до зареждане на излишни данни и проблеми с производителността.

Използване на FetchMode в Criteria API: Позволява да се определи как да се зареждат свързаните обекти.

Session session = sessionFactory.openSession();
Criteria criteria = session.createCriteria(Author.class)
    .setFetchMode("books", FetchMode.JOIN); // Използва LEFT OUTER JOIN за зареждане на books

List<Author> authors = criteria.list();

for (Author author : authors) {
    System.out.println("Author: " + author.getName());
    for (Book book : author.getBooks()) {
        System.out.println("- Book: " + book.getTitle());
    }
}
session.close();

Използване на BatchSize анотация: Посочва Hibernate да зарежда свързаните обекти (или колекции) групирано с определен размер, което намалява броя на заявките, макар и да не ги събира в една.
```
@Entity
@BatchSize(size = 10) // Hibernate ще зарежда Author на партиди по 10
public class Author {
    // ... други полета
    @OneToMany(mappedBy = "author", fetch = FetchType.LAZY)
    @BatchSize(size = 10) // Hibernate ще зарежда books за партиди по 10
    private List<Book> books;
    // ... гетъри и сетъри
}
```
При обхождане на колекцията books за първия автор, Hibernate ще зареди books и за следващите 9 автори (ако са заредени в същата сесия). Това значително намалява броя на заявките в сравнение с N+1.

Използване на Entity Graphs: Позволява явно да се определи кои свързани обекти или колекции трябва да бъдат заредени при изпълнение на заявката.

@NamedEntityGraph(name = "author-with-books",
    attributeNodes = @NamedAttributeNode("books")
)
@Entity
public class Author {
    // ... полета и връзки
}

Session session = sessionFactory.openSession();
jakarta.persistence.EntityGraph<Author> entityGraph = session.createEntityGraph(Author.class);
entityGraph.addAttributeNodes("books");

List<Author> authors = session.createQuery("SELECT a FROM Author a", Author.class)
    .setHint("jakarta.persistence.fetchgraph", entityGraph) // или fetchgraph в зависимост от желаното поведение
    .getResultList();

for (Author author : authors) {
    System.out.println("Author: " + author.getName());
    for (Book book : author.getBooks()) {
        System.out.println("- Book: " + book.getTitle());
    }
}
session.close();

Изборът на конкретно решение зависи от контекста, вида на връзката one-to-one / one-to-many / many-to-many, обема на данните и изискваната гъвкавост. JOIN FETCH и Entity Graphs често са предпочитани за зареждане на всички свързани данни в един заявка, докато BatchSize е ефективен при работа с голям брой обекти и може да бъде полезен, когато JOIN FETCH води до прекалено големи резултати. EAGER зареждането трябва да се използва с внимание.

Какъв е проблемът N+1 в Hibernate и как може да бъде решен?