join fetch ve Sayfalama — 10 Sipariş İçin Bütün Tablo

Ekranda yalnızca on sipariş var. Testte her şey hızlıydı, canlıda sayfa saniyelerce açılmıyor. Bellek grafiği her tıklamada sıçrıyor.

Sayfayı veritabanı keser

LIMIT 10 OFFSET 20 veritabanına “yirmi satırı atla, on tane ver” der. Kesme işini veritabanı yapar ve ağdan yalnızca on satır geçer.

Ama siparişi satırlarıyla birlikte çekmek için tabloları birleştirirsin. Bu birleştirmede bir sipariş, satır sayısı kadar sonuç satırı üretir. On sonuç satırı artık on sipariş demek değildir.

join fetch sayfalamayla buluşunca

join fetch?Terimin tanımını açfetch joinJPQL'de join fetch: ilişkili entity ya da koleksiyonu aynı sorguda doldurur. Koleksiyonla birlikte sayfalanırsa LIMIT düşer ve sayfa bellekte kesilir.Sözlükte gör → bir koleksiyonu tek sorguda doldurur. Sayfalamayla birleşince Hibernate HHH90003004 uyarısını yazar: “applying in memory”. Hata yok, sadece yavaş ve aç gözlü bir sorgu.

hibernate.query.fail_on_pagination_over_collection_fetch=true ayarı bu uyarıyı hataya çevirir. Sorun böylece ilk testte görünür.

İki küçük sorgu

Birinci sorgu yalnızca sayfadaki siparişlerin id’lerini LIMIT ile alır. İkinci sorgu o id’ler için join fetch yapar. Kesme veritabanında kalır ve yalnızca gereken satırlar gelir.

Diğer yol batch fetching?Terimin tanımını açbatch fetchingTembel koleksiyon ya da ilişkileri tek tek değil, birkaçını bir IN sorgusuyla yükleme. default_batch_fetch_size ya da @BatchSize ile açılır; N+1'i küçültür.Sözlükte gör →: sayfayı tembel yüklersin, satırlara ilk dokunuşta Hibernate on siparişin satırlarını tek bir IN sorgusuyla getirir. Bu, N+1?Terimin tanımını açN+1Bir sorgu listeyi getirir, sonra her eleman için bir sorgu daha atılır. Her biri hızlı olduğu için yavaş sorgu logunda görünmez; yavaşlayan şey toplam gidiş-dönüş sayısıdır.Sözlükte gör → sorununu da iki sorguya indirir.

Kendin gör

1. Varsayılanla oynat. LIMIT yok, 50 siparişin hepsi belleğe geldi.
2. Tabloyu 10.000 yap. Aynı on sipariş için on bin sipariş kuruldu.
3. “Bellekte sayfalamayı yasakla”yı aç. Sorgu çalışmadan hata verdi.
4. Tembel yüklemeyi seç. Doğru sonuç ama 11 sorgu.
5. Batch fetch’i ve iki adımlı yolu dene. İkisi de iki sorgu, satır sayısı tablo büyüdükçe değişmiyor.

Tuzaklar

Spring Data’da gizli hâli. Page<Order> findAll(Pageable) üstüne koleksiyon için @EntityGraph koymak da aynı bellekte sayfalamayı yapar.

İki List’i birden fetch etmek. İki List koleksiyonunu aynı sorguda join fetch edersen MultipleBagFetchException alırsın. Set’e çevirmek hatayı susturur ama satırları çarpar: 5 satır ve 4 ödeme, sipariş başına 20 satır eder.

IN sorgusu sırayı korumaz. İkinci sorguya da aynı order by’ı yaz; yoksa sayfa karışık sırada gelir.

Aşağıdaki örnek bir bankanın müşteri listesi ekranından: her müşteri kartlarıyla birlikte, sayfa sayfa.

1
@Entity
2
@Table(name = "customers")
3
class Customer {
4

5
    @Id
6
    private Long id;
7

8
    private String fullName;
9
    private Instant createdAt;
10

11
    @OneToMany(mappedBy = "customer")
12
    private Set<Card> cards = new HashSet<>();   // lazy by default for collections
13

14
    protected Customer() {
15
    }
16

17
    Long id() {
18
        return id;
19
    }
20

21
    Set<Card> cards() {
22
        return Collections.unmodifiableSet(cards);
23
    }
24
}

1
interface CustomerRepository extends JpaRepository<Customer, Long> {
2

3
    // Step 1: only ids, so LIMIT/OFFSET stays in the SQL. Spring Data adds the count query.
4
    @Query("select c.id from Customer c order by c.createdAt, c.id")
5
    Page<Long> findIdPage(Pageable pageable);
6

7
    // Step 2: the details of exactly those customers. IN does not keep order,
8
    // so the same ORDER BY is repeated here.
9
    @Query("""
10
            select c from Customer c
11
              left join fetch c.cards
12
             where c.id in :ids
13
             order by c.createdAt, c.id
14
            """)
15
    List<Customer> findWithCards(Collection<Long> ids);
16
}

1
@Service
2
class CustomerListing {
3

4
    private final CustomerRepository customers;
5

6
    CustomerListing(CustomerRepository customers) {
7
        this.customers = customers;
8
    }
9

10
    @Transactional(readOnly = true)
11
    public Page<Customer> page(int number, int size) {
12
        Page<Long> ids = customers.findIdPage(PageRequest.of(number, size));
13
        if (ids.isEmpty()) {
14
            return Page.empty(ids.getPageable());
15
        }
16
        List<Customer> rows = customers.findWithCards(ids.getContent());
17
        return new PageImpl<>(rows, ids.getPageable(), ids.getTotalElements());
18
    }
19
}

1
spring:
2
  jpa:
3
    properties:
4
      hibernate:
5
        query:
6
          # join fetch + paging in one query now throws instead of loading the table
7
          fail_on_pagination_over_collection_fetch: true
8
        # lazy collections touched in a loop load in groups of up to 16
9
        default_batch_fetch_size: 16

1
@DataJpaTest
2
@Import(CustomerListing.class)
3
@Sql("/customers-25-with-cards.sql")   // 25 customers, created in id order
4
class CustomerListingTest {
5

6
    @Autowired CustomerListing listing;
7

8
    @Test
9
    void secondPageHasTenCustomersInOrderWithTheirCards() {
10
        Page<Customer> page = listing.page(1, 10);
11

12
        assertThat(page.getTotalElements()).isEqualTo(25);
13
        assertThat(page.getContent()).extracting(Customer::id)
14
                .containsExactly(11L, 12L, 13L, 14L, 15L, 16L, 17L, 18L, 19L, 20L);
15
        assertThat(page.getContent()).allSatisfy(c -> assertThat(c.cards()).isNotEmpty());
16
    }
17
}

Kendini sına