Tag:

jpa

Optymalizacja JPA – 3 praktyczne wskazówki

by Grzegorz Sowa 16 maja, 2021

written by Grzegorz Sowa

Cześć, ten artykuł będzie krótki, a jego tematyka to optymalizacja JPA. Postaram się w nim zawrzeć kilka trików, które pomogą Ci pisać lepsze aplikacje oparte o Spring Data. Pozwolą też zwiększyć Twoją wiedzę, jak Hibernate działa „pod maską”. Jedziemy!

Kod wykorzystany w tym artykule znajdziecie tutaj

Implementuj Persistable<ID>

Ten tip przydaje się gdy mamy encję, której id nie generuje Hibernate, na przykład:

@Getter
@NoArgsConstructor(access = PRIVATE)
@Entity
public class Post {

    @Id
    private UUID id;
    private UUID author;
    private String text;

    public static Post newInstance(UUID author, String text) {
        Post post = new Post();
        post.id = UUID.randomUUID();
        post.author = author;
        post.text = text;
        return post;
    }
}

Wygląda dobrze? No to włączmy logowanie zapytań SQL i przyjrzyjmy się, co się dzieje kiedy zapisujesz nową instancję encji Post. W tym celu dodajemy do application.yml:

logging.level.org.hibernate.SQL: DEBUG

Po stworzeniu nowego Post-a widzimy w konsoli:

org.hibernate.SQL: select post0_.id as id1_0_0_, post0_.author as author2_0_0_, ... 
org.hibernate.SQL: insert into post (author, text, id) values (?, ?, ?)

Zaraz, Hibernate robi dodatkowego SELECTa, przed każdym INSERTem nowego obiektu do bazy… Dlaczego to robi? Otóż gdy wywołujemy metodę save() z encją, której id nie jest nullem, JPA „nie wie”, czy ma już dane o obiekcie w bazie. Dlatego nie może zdecydować, czy powinien użyć polecenia INSERT, czy UPDATE. Na szczęście możemy zapobiec temu dodatkowemu INSERTowi, przejmując na siebie ciężar odpowiedzialności za ustalenie, czy obiekt encji jest nowy. W tym celu implementujemy interfejs Persistable<T>:

public interface Persistable<ID> {
    @Nullable
    ID getId();
    boolean isNew();
}

Dzięki metodzie isNew() możemy „powiedzieć” JPA, że jesteśmy pewni, że obiekt encji nie istnieje jeszcze w bazie danych. Zobaczmy przykładową implementację w klasie Post:

@Getter
@NoArgsConstructor(access = PRIVATE)
@Entity
public class Post implements Persistable<UUID>{

    @Id
    private UUID id;
    @Transient
    private boolean isNew;
    private UUID author;
    private String text;

    public static Post newInstance(UUID author, String text) {
        Post post = new Post();
        post.id = UUID.randomUUID();
        post.isNew = true;
        post.author = author;
        post.text = text;
        return post;
    }

}

I gotowe, Lombok utworzył getter isNew(), wypełniając kontrakt interfejsu. Pole oznaczone adnotacją @Transient nie jest zapisywane ani odczytywane z bazy, a jeśli nie inicjujemy pola boolean to będzie zawsze miało domyślną wartość false. Czyli isNew() zwróci true tylko, jeśli obiekt pochodzi z metody statycznej newInstance().

Po stworzeniu posta widzimy w logach:

org.hibernate.SQL: insert into post (author, text, id) values (?, ?, ?)

Hibernate nie wykonał dodatkowego zapytania. Wprawdzie wzrost wydajności może być różny w zależności od przypadku, ale koszt jego zastosowania jest właściwie zerowy, więc to świetny tip do optymalizacji JPA 🙂

Używaj właściwej strategii generowania id

Dla id zachowujących sekwencję, które muszą być generowane przez bazę danych ważną kwestią dla wydajności jest strategia ich generowania. Dostępne strategie są zdefiniowane w enumie GenerationType:

IDENTITY – generowanie id przez kolumnę IDENTITY w tabeli. Jest okej, chyba że chcemy używać JDBC batching, na który ta strategia nie pozwala.
TABLE – generowanie id przez oddzielną tabelę, definiowaną specjalnie do tego celu. Niestety, zakłada oddzielne połączenie do bazy tylko po to, aby pobrać kolejne id.
SEQUENCE – do generowania id zakłada sekwencję bazodanową. Trochę bardziej skomplikowane niż IDENTITY, jednak bardziej elastyczne. Domyślnie również zakłada nowe połączenie, aby pobrać nowe id. Oferuje jednak optymalizacje, które pozwalają pobrać kilka id za jednym razem, redukując liczbę zapytań. Pobieranie zapasu nowych id pozwala też na JDBC batching (patrz następną wskazówkę).

Optymalna strategia generowania id

Załóżmy, że w encji Post zaimplementowaliśmy id generowane przez Hibernate:

 @Id
 @GeneratedValue(strategy = GenerationType.TABLE)
 private Long id;

Przy włączonym logowaniu SQL w Hibernate utwórzmy nowy Post i zajrzyjmy w logi:

org.hibernate.SQL: select tbl.next_val from hibernate_sequences tbl where tbl.sequence_name=? for update
org.hibernate.SQL: update hibernate_sequences set next_val=?  where next_val=? and sequence_name=?
org.hibernate.SQL: insert into post (author, text, id) values (?, ?, ?)

Czyli przy strategii TABLE wykonujemy aż DWA dodatkowe zapytania do bazy, kiedy dodajemy do niej nową encję. Za to po zamienieniu strategii na IDENTITY logi wyglądają już tak:

org.hibernate.SQL: insert into post (id, author, text) values (null, ?, ?)

Tutaj, baza używa do generowania id specjalnej kolumny IDENTITY i nie potrzebuje dodatkowych zapytań.

Tylko IDENTITY? Cóż, nie zawsze

Przyjrzyjmy się jeszcze ostatniej strategii, czyli SEQUENCE. Pozwala ona na dalsze optymalizacje JPA, jak np. batching, co opisałem w kolejnym punkcie. Po podmianie strategii w klasie Post, logi po utworzeniu nowego posta wyglądają tak:

org.hibernate.SQL: call next value for hibernate_sequence
org.hibernate.SQL: insert into post (author, text, id) values (?, ?, ?)

Niestety, znowu mamy dodatkowe zapytanie do bazy o id, poza tym nazwa hibernate_sequence nie brzmi zbyt unikalnie – nie chcemy chyba, aby id dla innych tabel były generowane przez ten sam sequence 😉 Gdzie tu optymalizacja JPA? Ewidentnie potrzeba tutaj trochę więcej konfiguracji:

@Id
@GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "post_sequence")
@SequenceGenerator(name = "post_sequence", allocationSize = 5)
private Long id;

Tutaj już poprawiliśmy nazwę sekwencji. Poza tym, jeśli użyjemy allocationSize większego niż 1 to aplikacja zacznie pobierać po kilka id naraz, używając tzw. pooled optimizer. Więcej do poczytania o tym, jak działają optimizery i jakie są ich rodzaje, poczytasz tutaj.

Żeby zobaczyć efekty naszych zmian, będziemy musieli utworzyć kilka postów. W tym celu napiszmy test:

@SpringBootTest
@AutoConfigureMockMvc
class JpaTipsDemoApplicationTests {

    @Autowired
    private MockMvc mockMvc;

    private String userId = UUID.randomUUID().toString();

    @Test
    void shouldCreateTenPosts() throws Exception {
        for (int i = 0; i < 10; i++) {
            this.mockMvc.perform(
                    post("/posts")
                            .header("userId", userId)
                            .content(String.format("{\"text\": \"Sample post %d\"}", i))
                            .contentType(MediaType.APPLICATION_JSON));
        }
    }
}

Powyższy test utworzy 10 postów, a po jego wykonaniu widzimy w logach:

org.hibernate.SQL: call next value for post_sequence
org.hibernate.SQL: call next value for post_sequence
org.hibernate.SQL: insert into post (author, text, id) values (?, ?, ?)
org.hibernate.SQL: insert into post (author, text, id) values (?, ?, ?)
org.hibernate.SQL: insert into post (author, text, id) values (?, ?, ?)
org.hibernate.SQL: insert into post (author, text, id) values (?, ?, ?)
org.hibernate.SQL: insert into post (author, text, id) values (?, ?, ?)
org.hibernate.SQL: insert into post (author, text, id) values (?, ?, ?)
org.hibernate.SQL: call next value for post_sequence
org.hibernate.SQL: insert into post (author, text, id) values (?, ?, ?)
org.hibernate.SQL: insert into post (author, text, id) values (?, ?, ?)
org.hibernate.SQL: insert into post (author, text, id) values (?, ?, ?)
org.hibernate.SQL: insert into post (author, text, id) values (?, ?, ?)

Czyli sequence optimizer pobiera sobie z bazy danych 5 kolejnych id, i za każdym razem, gdy te 5 zapasowych id zostanie „naruszone”, pobiera sobie dodatkowe 5. Widać, że znacznie zmniejsza to liczbę połączeń do bazy. Oprócz tego sprawia, że aplikacja dysponuje teraz konkretną pulą id do wykorzystania, dzięki czemu może wysyłać kolejne INSERTy w grupach (batchach).

Używaj JDBC batch processing

Kolejna mała optymalizacja JPA to JDBC batch processing. Ta technologia pozwala na wysyłanie modyfikujących zapytań do bazy danych w grupach. Znacznie przyspiesza to działanie aplikacji. Można batchować nie tylko zapytania INSERT, ale tutaj właśnie na nich się skupimy. Żeby poruszyć JDBC batch processing najpierw musimy zrozumieć, czym jest persistence context – jest co coś w rodzaju „nakładki” na bazę danych, którą widzi aplikacja i spełnia dwie role:

jest formą cache, do którego wpadają wszystkie obiekty, które podnieśliśmy z bazy danych w danej sesji – jest to cache pierwszego poziomu. Więcej o cache w Hibernate możesz poczytać w tym artykule.
przechowuje obiekty, które chcieliśmy zapisać do bazy danych i dokonuje zapisu w momencie, gdy transakcja, w ramach której funkcjonuje, jest zsynchronizowana (czyli najczęściej na jej końcu). Domyślnie w aplikacji Spring Boot transakcja bazodanowa jest tworzona na okres od początku zapytania do zwrócenia odpowiedzi i w takim zakresie działa JDBC batching.

Żeby zaobserwować batching zapytań dodajmy uproszczoną możliwość oznaczania innych użytkowników w postach:

@Service
@RequiredArgsConstructor
public class PostService {

    private final PostRepository postRepository;
    private final NotificationRepository notificationRepository;

    public UUID createPost(UUID userId, CreatePostDto dto) {
        final Post post = Post.newInstance(userId, dto.getText());
        final UUID postId = postRepository.save(post).getId();

        if (dto.getMentionedUsers() != null && !dto.getMentionedUsers().isEmpty()) {
            final List<Notification> notifications = dto.getMentionedUsers().stream()
                    .map(user -> new Notification(user, "You are mentioned in a post!",
                            String.format("https://localhost:8080/posts/%s", post.getId())))
                    .collect(Collectors.toList());
            notificationRepository.saveAll(notifications);
        }

        return postId;
    }

    // …

}

Jak widać, wyciągamy po prostu oznaczonych użytkowników z CreatePostDto i tworzymy dla nich powiadomienia z linkiem do posta. Tak wygląda klasa Notification:

@Entity
@RequiredArgsConstructor
class Notification {

    @Id
    @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "notification_sequence")
    @SequenceGenerator(name = "notification_sequence", allocationSize = 5)
    private Long id;
    private final UUID userId;
    private final String message;
    private final String url;
    
}

Jeśli nie wiesz, dlaczego użyliśmy takiej strategii generowania id, zobacz poprzedni punkt. Napiszmy teraz test, w którym dodamy nowy post i oznaczymy w nim kilku użytkowników:

@Test
void shouldCreatePostWithMentionedUsers() throws Exception {
    this.mockMvc.perform(
            post("/posts")
                    .header("userId", userId)
                    .content("""
                            {"text": "Sample post",
                            "mentionedUsers": [
                                "5d6101d3-d7b2-4eab-aedf-9cacf19713bb",
                                "90d32548-b10d-4746-bbfe-8494217e504d",
                                "1ed15d33-74b3-4271-80f0-231762158790",
                                "9ce98893-71fb-4061-ba63-4bbd5bcb5aab"
                            ]}
                            """)
                    .contentType(MediaType.APPLICATION_JSON));
}

Niestety, logi z Hibernate nie wystarczą, żeby zaobserwować działanie batchowania naszych INSERTów. Aby to zrobić, musimy zaimportować dodatkową bibliotekę udostępniającą możliwość zdefiniowania proxy śledzącego użycie DataSource:

<dependency>
    <groupId>net.ttddyy</groupId>
    <artifactId>datasource-proxy</artifactId>
    <version>1.4.1</version>
</dependency>

Aby użyć naszego nowego importu i opakować DataSource w proxy, możemy użyć customowy BeanPostProcessor, który jest świetnym sposobem na złapanie zainicjalizowanego DataSource i jego modyfikację.

@Component
public class DatasourceProxyBeanPostProcessor implements BeanPostProcessor {
    
    @Override
    public Object postProcessBeforeInitialization(final Object bean, final String beanName) throws BeansException {
        return bean;
    }

    @Override
    public Object postProcessAfterInitialization(final Object bean, final String beanName) throws BeansException {
        if (bean instanceof DataSource dataSourceBean) {
            return ProxyDataSourceBuilder.create(dataSourceBean)
                    .name("BatchLogger")
                    .asJson().countQuery()
                    .logQueryBySlf4j(SLF4JLogLevel.INFO).build();
        }
        return bean;
    }
    
}

Teraz odpalmy napisany test i zajrzyjmy w logi:

n.t.d.l.l.SLF4JQueryLoggingListener: {"name":"BatchLogger", [...] "batch":false, "querySize":1, "batchSize":0, "query":["insert into post ...
n.t.d.l.l.SLF4JQueryLoggingListener: {"name":"BatchLogger", [...] "batch":false, "querySize":1, "batchSize":0, "query":["call next value for notification_sequence"] ...
n.t.d.l.l.SLF4JQueryLoggingListener: {"name":"BatchLogger", [...] "batch":false, "querySize":1, "batchSize":0, "query":["call next value for notification_sequence"] ...
n.t.d.l.l.SLF4JQueryLoggingListener: {"name":"BatchLogger", [...] "batch":false, "querySize":1, "batchSize":0, "query":["insert into notification ...
n.t.d.l.l.SLF4JQueryLoggingListener: {"name":"BatchLogger", [...] "batch":false, "querySize":1, "batchSize":0, "query":["insert into notification ...
n.t.d.l.l.SLF4JQueryLoggingListener: {"name":"BatchLogger", [...] "batch":false, "querySize":1, "batchSize":0, "query":["insert into notification ...
n.t.d.l.l.SLF4JQueryLoggingListener: {"name":"BatchLogger", [...] "batch":false, "querySize":1, "batchSize":0, "query":["insert into notification ...

Zapytania nie są batchowane, za każdym razem jest do bazy wrzucane jedno Notification. Przez to jest generowane dużo niepotrzebnego ruchu między aplikacją a bazą – postarajmy się to zmienić. Mając już właściwą strategię generowania id w Notification, dodajmy do application.yml konfigurację:

spring.jpa.properties.hibernate.jdbc.batch_size: 5

Logi po powtórnym odpaleniu wcześniej napisanego testu:

n.t.d.l.l.SLF4JQueryLoggingListener: {"name":"BatchLogger", [...] "batch":true, "querySize":1, "batchSize":1, "query":["insert into post ...
n.t.d.l.l.SLF4JQueryLoggingListener: {"name":"BatchLogger", [...] "batch":false, "querySize":1, "batchSize":0, "query":["call next value for notification_sequence"] ...
n.t.d.l.l.SLF4JQueryLoggingListener: {"name":"BatchLogger", [...] "batch":false, "querySize":1, "batchSize":0, "query":["call next value for notification_sequence"] ...
n.t.d.l.l.SLF4JQueryLoggingListener: {"name":"BatchLogger", [...] "batch":true, "querySize":1, "batchSize":4, "query":["insert into notification ...

Widać, że teraz zapytania dodające nowe Notification są już batchowane, zamiast kilku oddzielnych zapytań został wysłany do bazy danych jeden batch.

Podsumowanie

Mam nadzieję, że te trzy tipy pozwoliły Wam chociaż trochę rozszerzyć wiedzę z JPA. Mimo, że nie zawsze stosowalne, często mogą prowadzić do sporych zysków w wydajności aplikacji. Optymalizacja JPA to często najłatwiejsza droga optymalizacji całej aplikacji.

16 maja, 2021 0 comment

Optymalizacja Persystencja

Jak działa cache w Hibernate? (praktyczne przykłady)

by Grzegorz Sowa 8 maja, 2021

written by Grzegorz Sowa

Popołudniowy pik użytkowników, Twoja apka potrzebuje coraz więcej czasu na odpowiedź. Sytuacja powtarza się codziennie, prosta diagnostyka pokazuje, że bottleneckiem jest baza danych. Jeśli jeszcze nie używasz Hibernate Cache, to może być najlepszy moment, aby o tym pomyśleć 🙂

Kod wykorzystany w tym artykule zawiera to repozytorium

Poziomy cache w Hibernate

Cache w Hibernate przechowuje ostatnio zwrócone obiekty w pamięci, gdzie są szybko i łatwo dostępne bez ponownego odpytywania bazy danych. Must-have w aplikacjach obsługujących duży ruch, w których obciążenie bazy zaczyna być problemem. Są 2 poziomy cache w Hibernate, istnieje też trzeci rodzaj cache, Query Cache. Gdy aplikacja żąda zasobu o danym id, Hibernate sprawdza najpierw L1 cache, potem L2 cache (jeśli istnieje), i dopiero jeśli w nich nie znajdzie zasobu, odpytuje bazę danych. Przy bardziej złożonym query Hibernate zajrzy do Query Cache, które mapuje zapytania na id obiektów, które będą ich wynikami.

L1 Cache

Z pierwszego poziomu cache korzystamy często, nawet o tym nie wiedząc – jest domyślnie włączony przez Hibernate i nie da się go wyłączyć. Wyniki zapytań żyją tu dokładnie tyle, co sesja Hibernate i są przechowywane w obiekcie EntityManagera. W aplikacji opartej na Spring Boot, sesja jest domyślnie tworzona przez mechanizm OSIV (Open Session In View). Sesja trwa od początku do końca requestu.

Załóżmy, że nasza apka to prosty portal społecznościowy. Udostępnia operacje tworzenia i edycji postów:

@RestController
@RequestMapping("/posts")
@RequiredArgsConstructor
public class PostController {

    private final PostService postService;
    private final SecurityService securityService;

    @PostMapping
    public ResponseEntity<String> createPost(
            @RequestHeader UUID userId,
            @RequestBody CreatePostDto dto) {

        final UUID postId = postService.createPost(userId, dto);
        return ResponseEntity.status(CREATED).body(postId.toString());
    }

    @PutMapping("/{postId}")
    public ResponseEntity<Void> editPost(
            @RequestHeader UUID userId,
            @PathVariable UUID postId,
            @RequestBody EditPostDto dto) {

        securityService.checkPostEditAccess(userId, postId);
        postService.editPost(postId, dto);
        return ResponseEntity.ok().build();
    }
    // …
}

Przyjrzyjmy operacji edycji. SecurityService musi odczytać Post z bazy danych, aby sprawdzić czy użytkownik jest jego właścicielem.

@Service
@RequiredArgsConstructor
public class SecurityService {

    private final PostRepository postRepository;

    public void checkPostEditAccess(UUID userId, UUID postId) {
        Post post = postRepository.findById(postId)
                .orElseThrow(NotFoundException::new);
        if (!post.getAuthor().equals(userId)) {
            throw new InvalidAccessException();
        }
    }

}

PostService odpytuje o Post o tym samym ID:

@Service
@RequiredArgsConstructor
public class PostService {

    private final PostRepository postRepository;

    public void editPost(UUID postId, EditPostDto dto) {
        final Post post = postRepository.findById(postId)
                .orElseThrow(NotFoundException::new);
        post.edit(dto.getText());
        postRepository.save(post);
    }
    // …
}

Czy to znaczy, że gdy PostService zażąda posta do edycji, Hibernate znów odpyta bazę danych?

Dzięki L1 cache, nie odpyta (jeśli obie operacje będą w tej samej sesji). Ale żeby nie być gołosłownym – przetestujmy to! W tym celu dodajmy logowanie zapytań sql w application.yml:

logging.level.org.hibernate.SQL: DEBUG

W naszym teście utwórzmy nowy post a potem spróbujmy go edytować:

@SpringBootTest
@AutoConfigureMockMvc
public class TestingWebApplicationTest {

    @Autowired
    private MockMvc mockMvc;

    private String userId = UUID.randomUUID().toString();

    @Test
    public void shouldEditPost() throws Exception {

        final String postId = this.mockMvc.perform(
                post("/posts")
                        .header("userId", userId)
                .content("{\"text\": \"Sample post\"}")
                .contentType(MediaType.APPLICATION_JSON))
                .andReturn().getResponse().getContentAsString();

        this.mockMvc.perform(
                put("/posts/" + postId)
                        .header("userId", userId)
                        .content("{\"text\": \"Edited post\"}")
                        .contentType(MediaType.APPLICATION_JSON))
                .andExpect(status().isOk());
    }
}

Po wykonaniu testu zajrzyjmy w logi:

org.hibernate.SQL: insert into post (author, text, id) values ...
org.hibernate.SQL: select post0_.id as id1_0_0_, post0_.author...
org.hibernate.SQL: update post set author=?, text=? where id=?

Jak widać, Hibernate odpytał bazę o post tylko raz. Spróbujmy więc skonfigurować aplikację tak, żeby metoda checkPostEditAccess() dostała inną sesję Hibernate, niż metoda editPost(). Wtedy encja Post powinna przestać być cache’owana pomiędzy tymi dwiema operacjami. Aby to osiągnąć, wyłączmy mechanizm OSIV dodając w application.yml:

spring.jpa.open-in-view: false

Teraz musimy już tylko dodać adnotację @Transactional nad definicjami każdej z tych metod, aby zdefiniować nowe konteksty persystencji, w których będą funkcjonowały oddzielne sesje Hibernate.

Odpalmy test jeszcze raz i zajrzyjmy w log:

org.hibernate.SQL: insert into post (author, text, id) values ...
org.hibernate.SQL: select post0_.id as id1_0_0_, post0_.author...
org.hibernate.SQL: select post0_.id as id1_0_0_, post0_.author...
org.hibernate.SQL: update post set author=?, text=? where id=?

I udało się, widzimy 2 zapytania select, jedno w checkPostEditAccess(), a drugie w editPost().

L2 Cache

Żeby dalej zoptymalizować zapytania w naszej apce, włączmy cache drugiego poziomu. Wrzucamy konfigurację do application.yml:

spring.jpa.hibernate.cache.use_second_level_cache: true

Teraz nad klasą encji Post, której obiekty chcemy cache’ować dodajemy adnotacje:

@Cacheable
@Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
public class Post implements Persistable<UUID> {
// …

Możemy wybrać z kilku wartości CacheConcurrencyStrategy:

READ_ONLY – przy próbie edycji, cache wyrzuca wyjątek. Dlatego używamy go do encji, które nigdy się nie zmieniają.
NONSTRICT_READ_WRITE – update cache’a następuje, gdy zakończy się transakcja zmieniająca dane. Zapewnia słabą spójność danych pomiędzy bazą a cache. Poza tym, pomiędzy zapisem do bazy a aktualizacją cache są serwowane nieaktualne dane.
READ_WRITE – na czas trwania update zakłada na obiekt w cache soft lock. To znaczy, że każde zapytanie o tak zablokowany obiekt będzie omijało cache. Dzięki temu zostanie zapewniona mocna spójność danych.
TRANSACTIONAL – każdy update cache odbywa się w rozproszonej transakcji z bazą danych. Zapewnia największą spójność, za to największym kosztem.

Tutaj użyliśmy opcji CacheConcurrencyStrategy.READ_ONLY – więcej o tej strategii możesz przeczytać tutaj.

Ponieważ Hibernate sam nie dostarcza L2 Cache, a jedynie definiuje interfejs, musimy jeszcze zaimportować providera. Dla potrzeb prezentacji najłatwiej będzie użyć EhCache:

<dependency>
	<groupId>org.ehcache</groupId>
	<artifactId>ehcache</artifactId>
	<version>3.6.3</version>
	<scope>runtime</scope>
</dependency>

Istnieją też inni providerzy, np. jeśli chcemy, aby nasza aplikacja była skalowalna poziomo, możemy użyć redisson-hibernate, który zezwala na przechowywanie cache w bazie Redis.

Odpalmy nasz test jeszcze raz, żeby zobaczyć efekt działania cache. Widzimy w logach:

org.hibernate.SQL: insert into post (author, text, id) values ...
org.hibernate.SQL: update post set author=?, text=? where id=?

A więc pomiędzy insertem a updatem nie odpytaliśmy bazy ani razu! Post został zapisany do cache i stamtąd podniesiony w celu edycji. Cache drugiego poziomu najwyraźniej działa.

Query Cache

Hibernate Query Cache przydaje się, gdy nasza aplikacja bardzo często wykonuje pewne query, przy czym encje, o które odpytujemy bazę, nie powinny zmieniać się zbyt często. Każda zmiana w tabeli, którą odpytujemy, unieważnia nasz cache – nawet, gdy aktualizowana encja nie znajduje się w wyniku zapytania.

Query Cache nie przechowuje obiektów – mapuje tylko zapytania na listy id obiektów które są jego wynikiem. Aby Query Cache miało więc sens, powinniśmy użyć też L2 Cache.

Aby włączyć Query Cache dodajemy do application.yml:

spring.jpa.properties.hibernate.cache.use_query_cache: true

Musimy też oznaczyć query, którego wynik chcemy cache’ować:

public interface PostRepository extends JpaRepository<Post, UUID> {

    @QueryHints({@QueryHint(name= HINT_CACHEABLE, value = "true")})
    List<Post> findAll();

}

Napiszmy też prosty test, który będzie symulował pobieranie wszystkich postów kilka razy:

    @Test
    public void shouldGetAllPosts() throws Exception {

        this.mockMvc.perform(
                post("/posts")
                        .header("userId", userId)
                        .content("{\"text\": \"Sample post\"}")
                        .contentType(MediaType.APPLICATION_JSON));

        for (int i = 0; i < 4; i++) {
            this.mockMvc.perform(
                    get("/posts"))
                    .andExpect(status().isOk());
        }

    }

Logi testu:

org.hibernate.SQL: insert into post (author, text, id) values (?, ?, ?)
org.hibernate.SQL: select post0_.id as id1_0_, post0_.author as author2_0_, post0_.text...

Mimo, że test odpytuje o wszystkie posty 4 razy, w logach widzimy tylko jeden select. Jeśli wyłączymy Query Cache, select na pewno pojawi się 4 razy.

Podsumowanie

Hibernate Cache może bardzo zmniejszyć ilość zapytań do bazy danych i zoptymalizować zużycie zasobów naszej aplikacji. Powinniśmy jednak zawsze pamiętać, że nie ma nic za darmo i za oczywiste zyski z używania cache płacimy cenę w postaci zużycia zasobów i ryzyka operowania na przestarzałych danych. Aby podejmować świadome decyzje o używaniu cache, warto monitorować jego działanie, np. za pomocą odpowiednich metryk.

8 maja, 2021 0 comment