zapobieganie wybiórcom N + 1 w JPA

Question

Mam zlecenia JPA w stosunku ManyToOne do Klienta. Jest dwukierunkowy, dzięki czemu Klient ma również zamówienia w polu OneToMany. Obie relacje używają pobierania EAGER (lub są w programie pobierania OpenJPA).

Po wybraniu z zamówienia otrzymuję 1 opcję wyboru dla zamówień i N opcji dla pola Klient.orders. Ku mojemu zaskoczeniu ten problem występuje w OpenJPA, EclipseLink i Hibernate, nawet gdy używam JOIN FETCH (który działa w przypadku jednokierunkowym).

Czy istnieje dobry sposób rozwiązania tego problemu? Czy istnieją jakieś rozwiązania dotyczące rozwiązywania problemów z wyborem N + 1 w przypadku bardziej złożonych wykresów?

EDIT: Wyniki moich badań: - Na OpenJPA (którego używam) nie wiem rozwiązanie jeszcze - Na hibernacji @Fetch (FetchMode.SUBSELECT) rozwiązuje ten problem. Korzystanie z @BatchSize również pomaga, to wybiera określoną liczbę customer.orders pól w tym samym czasie. - Dla EclipseLink znalazłem podobną funkcję @BatchFetch (value = BatchFetchType.IN), ale nie pomaga w tym przypadku, przypuszczam, że nie może wydajnie obsłużyć tego w dwukierunkowej relacji.

Answer 1

W dowolnej strukturze ORM problem N + 1 jest powszechny. Nie możesz tego uniknąć. Ale, to jest więcej o tym, jakie podejście podejmiesz, aby rozwiązać problem. Możesz użyć asocjacji i leniwego obciążenia lub spodziewanej daty obciążenia na podstawie Twojej implementacji. Możesz także wykonać mapowanie bazy danych i pobrać wszystkie powiązane dane w jednym zapytaniu i możesz zmapować je do swojego Modelu. Ponieważ baza danych jest indeksowana, ta operacja może być szybsza niż pobieranie danych i mapowanie przy użyciu zapytań N + 1 (jeśli pozwala na to twoje opóźnienie sieci).

Answer 2

Spójrz na: What is SELECT N+1?, ponieważ jest tam wiele dobrych informacji.

Jeżeli Państwa wykorzystaniem Hibernate: Hibernate - Chapter 19: Improving Performance - Fetching Strategies

My own personal solution is to use native SQL and tmp ids table to dlatego, że ogólnie IMHO N + 1 Select Problem jest głównie problem z przetwarzaniem wsadowym. W przeciwnym razie leniwy ładunek (zazwyczaj roztwór N + 1) może być korzystny dla wydajności.

Answer 3

Oto rozwiązanie:

1. oddzielna warstwa podmiot od warstwy API i interakcji z instancje API wyłącznie w tobie aplikacji. Api w tym kontekście może być również określane jako DTO.

2. Usuń relację całkowicie z Entity.

3. Utwórz mechanizm wskazujący, że chcesz pobrać dzieci. Na przykład: propaguj fetchRequestList do warstwy, która odwzorowuje API na Entity (w ten sposób możesz pobierać warunkowo).

4. Podczas wykonywania zapytania należy zebrać obiekty rodzica w normalny sposób.

5. Pobranie całej kolekcji dzieci przy użyciu nazwanego sparametryzowanego zapytania z klauzulą ​​IN opartą na FK na nadrzędną PK.

6. Prześledź wyniki i dopasuj je do rodziców.

Zmuszałoby to ORM do wykonywania zapytań n + 1, a nie n (n + 1) zapytań.Pamiętaj, że będziesz teraz musiał dodawać kaskadowe zapisywanie, usuwanie, aktualizowanie itp za pomocą niestandardowej logiki.