- Ano,
@BatchSize
je určen k použití s línými asociacemi. - Hibernace stejně provede více příkazů na většině stanic, i když je počet neinicializovaných proxy/kolekcí menší než zadaná velikost dávky. Další podrobnosti naleznete v této odpovědi. Také více lehčích dotazů ve srovnání s méně velkými může pozitivně přispět k celkové propustnosti systému.
@BatchSize
na úrovni třídy znamená, že zadaná velikost dávky pro entitu bude použita pro všechny@*ToOne
líné asociace s touto entitou. Podívejte se na příklad sPerson
entity v dokumentaci.
Propojené otázky/odpovědi, které jste uvedli, se více týkají potřeby optimalizace a líného načítání obecně. Platí zde samozřejmě také, ale netýkají se pouze dávkového načítání, což je pouze jeden z možných přístupů.
Další důležitá věc souvisí s dychtivým načítáním, které je zmíněno v propojených odpovědích a které naznačuje, že pokud se vlastnost používá vždy, můžete dosáhnout lepšího výkonu pomocí dychtivého načítání. To obecně není pravda pro sbírky a v mnoha situacích také pro asociace typu to-one.
Předpokládejme například, že máte následující entitu, pro kterou je bs
a cs
jsou vždy používá se při A
se používá.
public class A {
@OneToMany
private Collection<B> bs;
@OneToMany
private Collection<C> cs;
}
Dychtivě načítám bs
a cs
očividně trpí problémem s výběry N+1, pokud je nespojíte v jediném dotazu. Ale pokud je spojíte v jediném dotazu, například jako:
select a from A
left join fetch a.bs
left join fetch a.cs
poté vytvoříte úplný kartézský součin mezi bs
a cs
a vrátí count(a.bs) x count(a.cs)
řádků v sadě výsledků pro každý a
které jsou čteny jeden po druhém a sestavovány do entit A
a jejich sbírky bs
a cs
.
Dávkové načítání by v této situaci bylo velmi optimální, protože byste nejprve přečetli A
s, poté bs
a poté cs
, což má za následek více dotazů, ale s mnohem menším celkovým množstvím dat přenesených z databáze. Samostatné dotazy jsou také mnohem jednodušší než velký dotaz se spojeními a databáze se snáze spouští a optimalizuje.