Strona główna » Optymalizacja
Category:

Optymalizacja

JavaOptymalizacjaSecurity

JWT w Spring Security

by Grzegorz Sowa
written by Grzegorz Sowa

Jeśli rozmawiamy o autoryzacji, zawsze przychodzi na myśl JWT w Spring Security. Ale dlaczego właśnie JWT? Spring Security przecież świetnie sobie radzi z Session Cookie, w dodatku jest to domyślna metoda autoryzacji w tym frameworku. Spróbujmy sobie więc odpowiedzieć, czym jest JWT i jakie korzyści daje nad ciasteczkiem sesji. Na koniec spróbujmy w prosty sposób zaimplementować JWT w aplikacji opartej na Spring Boot.

Kod zawarty w tym artykule znajdziecie tutaj. Nie zapomnijcie przejrzeć innych branchy, zawierających kod odpowiadający kolejnym sekcjom artykułu.

JWT w teorii

sekcje jwt

JWT, czyli JSON Web Token to otwarty standard bezpiecznego transferu informacji o uprawnieniach, opisany w rfc7519. Każdy token jest ciągiem znaków, składających się z 3 części: nagłówka (Header), danych (Payload) i podpisu (Signature). Header zawiera takie informacje, jak typ tokenu i algorytm wykorzystany do podpisu. Payload natomiast zawiera dane zależne od aplikacji, część z nich jest opisana w standardzie:

  • iss (Issuer) – aplikacja wydająca token.
  • sub (Subject) – odbiorca tokenu.
  • aud (Audience) – lista podmiotów, w komunikacji z którymi token powinien być używany.
  • exp (Expiration Time) – timestamp momentu w przyszłości, po którym token nie powinien być akceptowany.
  • nbf (Not Before) – timestamp momentu w przyszłości, przed którym token nie powinien być akceptowany.
  • iat (Issued At) – timestamp momentu, w którym token został wydany.
  • jti (JWT ID) – unikalny identyfikator tokenu.

Wszystkie te parametry są opcjonalne, powstały tylko po to, aby developerzy mieli pewien punkt zaczepienia, definiując najczęściej używane w tokenach rzeczy.

Zarówno Header, jak i Payload są w tokenie w formie enkodowanej w Base64 i w takiej formie są składnikami do podpisu, który jest ostatnią częścią tokena. Do podpisu jest też używany sekret, który zna tylko serwer go wydający. W zależności od potrzeb JWT może być podpisywane algorytmem symetrycznym (wtedy zweryfikować go może tylko aplikacja-wydawca) lub asymetrycznym (wtedy część klucza jest dostępna publicznie i każdy może zweryfikować poprawność podpisu).

JWT w praktyce

JWT jest bardzo często używany jako standard nadawania uprawnień, również w implementacji innych frameworków jak OAuth2 czy Device Cookie. Przekazywanie tokena JWT w nagłówku zapytania ma kilka przewag nad standardowym Session Cookie:

  • O wiele lepiej się skaluje, gdyż aby zweryfikować JWT aplikacja nie musi wykonywać kosztownych zapytań do bazy danych.
  • Nie dotyczą go ataki CSRF, przez co jest jedynym sensownym wyborem dla Single Page Application, gdzie trudno jest przekazać token CSRF z backendu.
  • Zapewnia prawdziwie bezstanową komunikację, w przeciwieństwie do Session Cookie.

JWT w Spring Security

jwt w spring security

Teraz zobaczmy, jak zmienić standardowy sposób autoryzacji w Spring Security na JSON Web Token.

Implementacja użytkowników

Ponieważ standardowa implementacja danych użytkownika w Spring Security nie posiada ID, musimy zrobić własną, implementującą interfejs UserDetails:

@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PACKAGE)
public class AppUser implements UserDetails {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String username;
    private String password;

    @Convert(converter = AuthoritiesToStringConverter.class)
    private Set<Authority> authorities;

    public static AppUser newInstance(String username, String password, Authority... authorities) {
        final AppUser user = new AppUser();
        user.username = username;
        user.password = password;
        user.authorities = Set.of(authorities);
        return user;
    }

    @Override
    public boolean isAccountNonExpired() {
        return true;
    }

    @Override
    public boolean isAccountNonLocked() {
        return true;
    }

    @Override
    public boolean isCredentialsNonExpired() {
        return true;
    }

    @Override
    public boolean isEnabled() {
        return true;
    }
}

Dlaczego AppUser a nie User? Nazwa User mogłaby sprawiać problemy w zapytaniach do bazy danych. Natomiast użyty w klasie enum Authority musi implementować interfejs GrantedAuthority:

public enum Authority implements GrantedAuthority {
    USER, ADMIN;

    @Override
    public String getAuthority() {
        return this.name();
    }
}

Teraz pozostał już tylko serwis odpowiedzialny za użytkowników, implementujący interfejs UserDetailsService.

@Component
@RequiredArgsConstructor
public class AppUserService implements UserDetailsService {

    private final AppUserRepository repository;
    private final PasswordEncoder passwordEncoder;

    public AppUser createUser(String username, String password) {
        return repository.save(AppUser.newInstance(username, passwordEncoder.encode(password), Authority.USER));
    }

    public AppUser createAdmin(String username, String password) {
        return repository.save(AppUser.newInstance(username, passwordEncoder.encode(password), Authority.USER, Authority.ADMIN));
    }

    @Override
    public AppUser loadUserByUsername(String username) throws UsernameNotFoundException {
        return repository.findByUsername(username)
                .orElseThrow(() -> new UsernameNotFoundException("No user with such username!"));
    }
}

PasswordEncoder zdefiniujmy w oddzielnej klasie konfiguracyjnej:

@Configuration
public class PasswordHandlingConfiguration {

    @Bean
    public PasswordEncoder passwordEncoder() {
        return new BCryptPasswordEncoder();
    }

}

Mając to, możemy stworzyć kilku przykładowych użytkowników do testów, na starcie aplikacji:

@Component
@RequiredArgsConstructor
public class AddExampleUserRunner implements CommandLineRunner {

    private final AppUserService userService;

    @Override
    public void run(String... args) {
        userService.createUser("user", "pass");
        userService.createUser("user2", "pass");
        userService.createAdmin("admin", "pass");
    }

}

Konfiguracja

Następnie przechodzimy do konfiguracji Spring Security, na początek musimy podpiąć stworzony UserDetailsService oraz PasswordEncoder:

@Configuration
@RequiredArgsConstructor
public class WebSecurityConfiguration extends WebSecurityConfigurerAdapter {

    private final PasswordEncoder passwordEncoder;
    private final AppUserService userService;

    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth.userDetailsService(userService)
                .passwordEncoder(passwordEncoder);
    }
    // more..
}

Dalej w konfiguracji mamy do zrobienia jeszcze kilka rzeczy:

  • wyłączyć mechanizm tworzenia sesji, ustawiając go na wartość STATELESS,
  • podłączyć filtr, który będzie „rozpakowywał” token JWT jeszcze zanim Spring sprawdzi tożsamość użytkownika,
  • podłączyć AuthenticationSuccessHandler, który będzie tworzył nowy token JWT.
    private final AccessTokenProvider accessTokenProvider;

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
                .addFilterBefore(new AccessTokenPreAuthorizationFilter(accessTokenProvider), UsernamePasswordAuthenticationFilter.class)
                .authorizeRequests()
                .antMatchers(GET, "/posts/**").permitAll()
                .anyRequest().authenticated()
                .and()
                .formLogin()
                .successHandler(new AccessTokenAuthenticationSuccessHandler(accessTokenProvider, userService))
                .and()
                .exceptionHandling()
                .authenticationEntryPoint((req, resp, ex) -> resp.setStatus(UNAUTHORIZED.value()))
                .and()
                .sessionManagement().sessionCreationPolicy(STATELESS)
                .and()
                .csrf().disable();
    }

AccessTokenPreAuthorizationFilter

Filtr odczytuje nagłówek Authorization i wyciąga z niego token JWT, aby potem zamienić go na obiekt Authentication i wstawić go w SecurityContext sesji. Do operacji na JWT używa on AccessTokenProvider, który zdefiniujemy później.

@Slf4j
@RequiredArgsConstructor
public class AccessTokenPreAuthorizationFilter extends OncePerRequestFilter {

    private final AccessTokenProvider accessTokenProvider;

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException {
        String authorizationHeader = request.getHeader(AUTHORIZATION);
        if (authorizationHeader != null && authorizationHeader.startsWith("Bearer ")) {
            String token = authorizationHeader.substring("Bearer ".length());
            SecurityContextHolder.getContext()
                    .setAuthentication(accessTokenProvider.extractAuthentication(token));
        }
        filterChain.doFilter(request, response);
    }

}

AccessTokenAuthenticationSuccessHandler

Teraz zdefiniujmy AuthenticationSuccessHandler, który po pomyślnym uwierzytelnieniu wygeneruje dla usera Access Token i przekaże go w nagłówku. On również do operacji na JWT używa obiektu AccessTokenProvider.

@RequiredArgsConstructor
public class AccessTokenAuthenticationSuccessHandler implements AuthenticationSuccessHandler {

    private final AccessTokenProvider accessTokenProvider;
    private final AppUserService userService;

    @Override
    public void onAuthenticationSuccess(HttpServletRequest request, HttpServletResponse response, Authentication auth) {
        final AppUser user = (AppUser) auth.getPrincipal();
        final String accessToken = accessTokenProvider.getAccessToken(
                userService.loadUserByUsername(user.getUsername()).getId().toString(),
                user.getAuthorities().stream()
                        .map(GrantedAuthority::getAuthority)
                        .collect(Collectors.toList()));
        response.setHeader("access_token", accessToken);
    }

}

AccessTokenProvider

Interfejs AccessTokenProvider zawiera tylko dwie metody, używane do tej pory przez klasy obsługujące flow JWT:

public interface AccessTokenProvider {

    String getAccessToken(String userId, List<String> roles);

    Authentication extractAuthentication(String token);

}

Aby go zaimplementować, potrzebujemy biblioteki obsługującej JWT. Ja wybrałem na potrzeby tego przykładu implementację od auth0:

<dependency>
	<groupId>com.auth0</groupId>
	<artifactId>java-jwt</artifactId>
	<version>3.18.1</version>
</dependency>

Obsługując tokeny JWT warto skupić się na minimum, definiując tylko „sub” (Subject) w postaci id użytkownika, „exp” (Expiration Time), po upłynięciu którego biblioteka automatycznie odrzuci token, oraz role użytkownika w polu „roles”.

@Component
public class JwtAccessTokenProvider implements AccessTokenProvider {

    private final JwtAccessTokenProperties properties;
    private final Algorithm algorithm;
    private final JWTVerifier verifier;

    public JwtAccessTokenProvider(JwtAccessTokenProperties properties) {
        this.properties = properties;
        this.algorithm = Algorithm.HMAC256(properties.getSecret().getBytes(StandardCharsets.UTF_8));
        this.verifier = JWT.require(algorithm).build();
    }

    @Override
    public String getAccessToken(String userId, List<String> roles) {
        return JWT.create()
                .withSubject(userId)
                .withExpiresAt(new Date(System.currentTimeMillis() + properties.getTokenLifespanSeconds() * 1000))
                .withClaim("roles", roles)
                .sign(algorithm);
    }

    @Override
    public UsernamePasswordAuthenticationToken extractAuthentication(String token) {
        DecodedJWT jwt = verifier.verify(token);
        return new UsernamePasswordAuthenticationToken(
                jwt.getSubject(),
                null,
                jwt.getClaim("roles").asList(String.class).stream()
                        .map(SimpleGrantedAuthority::new)
                        .collect(Collectors.toList())
        );
    }
}

Kontrola dostępu

Zdefiniujmy teraz kontroler, w którym użytkownik może tworzyć własne wpisy i przeglądać wpisy innych. Ponadto, oddajmy w ręce użytkowników opcję usuwania wpisów.

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

    private final PostService postService;

    @GetMapping("{postId}")
    public Post getPost(@PathVariable Long postId) {
        return postService.getPost(postId);
    }

    @PostMapping
    public ResponseEntity<Void> createPost(@RequestBody CreatePostDto dto) {
        postService.createPost(dto.content);
        return ResponseEntity.status(CREATED).build();
    }

    @DeleteMapping("{postId}")
    // …
    public ResponseEntity<Void> deletePost(@PathVariable Long postId) {
        postService.deletePost(postId);
        return ResponseEntity.status(NO_CONTENT).build();
    }

    @Data
    public static class CreatePostDto {
        private String content;
    }
}

Tutaj pojawia się zagadnienie Ownership-based Access Control, ponieważ użytkownik powinien móc usunąć tylko własny wpis. Poza tym, administrator, którego wcześniej stworzyliśmy, powinien być w stanie usunąć każdy wpis (Role-based Access Control). To drugie zagadnienie załatwimy, dodając nad deletePost() adnotację @PreAuthorize("hasAuthority('ADMIN')"). To jednak nie wszystko, musimy jeszcze włączyć ten mechanizm, dodając nad klasą konfiguracyjną @EnableGlobalMethodSecurity(prePostEnabled = true). Ownership-based Access Control jest już trudniejszy, musimy zdefiniować komponent, który będzie mógł wyciągnąć wpis z bazy i sprawdzić, czy id jego autora jest takie samo jak to, które przyszło w JWT.

@Component
@RequiredArgsConstructor
public class AuthorChecker {

    private final PostService postService;

    public boolean check(Long postId) {
        final Post post = postService.getPost(postId);
        final Object principal = SecurityContextHolder.getContext().getAuthentication().getPrincipal();
        return post.getAuthorId().equals(principal);
    }

}

Teraz musimy jeszcze użyć metody check() w adnotacji @PreAuthorize. Gotowa metoda delete będzie wyglądała tak:

    @DeleteMapping("{postId}")
    @PreAuthorize("hasAuthority('ADMIN') or @authorChecker.check(#postId)")
    public ResponseEntity<Void> deletePost(@PathVariable Long postId) {
        postService.deletePost(postId);
        return ResponseEntity.status(NO_CONTENT).build();
    }

JWT vs Session Cookie

Zajrzyjmy jeszcze do zapytań do bazy żeby zobaczyć, jak dużą przewagę ma JWT nad Session Cookie. Niestety nie odnotujemy wewnętrznych zapytań robionych przez Springa na poziomie Hibernate, musimy zejść poziom niżej. W tym celu pobieramy bibliotekę zdolną założyć proxy na DataSource:

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

Teraz musimy jeszcze zapakować oryginalny DataSource w nasze proxy i sprawdzić, aby był używany w całej aplikacji. Idealnie nadaje się do tego BeanPostProcessor, który pozwala modyfikować beany po ich zainicjalizowaniu:

@Component
public class DatasourceProxyBeanPostProcessor implements BeanPostProcessor {

    @Override
    public Object postProcessBeforeInitialization(final Object bean, final String beanName) {
        return bean;
    }

    @Override
    public Object postProcessAfterInitialization(final Object bean, final String beanName) {
        if (bean instanceof DataSource dataSourceBean) {
            return ProxyDataSourceBuilder
                    .create(dataSourceBean)
                    .name("DataSourceProxyLogger")
                    .listener(new QueryLoggingListener())
                    .build();
        }
        return bean;
    }

}

@Slf4j
public class QueryLoggingListener implements QueryExecutionListener {

    @Override
    public void afterQuery(ExecutionInfo executionInfo, List<QueryInfo> list) {
        for (QueryInfo queryInfo: list) {
            log.info("Query: " + queryInfo.getQuery());
        }
    }
    // …
}

Zobaczmy więc, co nasz logger powie, jeśli użytkownikowi uda się usunąć wpis:

QueryLoggingListener: Query: select post0_.id as id1_1_0_, post0_.author_id as author_i2_1_0_, post0_.content as co[...]
QueryLoggingListener: Query: delete from post where id=?

Tyle, dwa zapytania – wyjmij wpis, usuń wpis. Dla porównania skonfigurowałem tę aplikację, żeby korzystała z sesji zapisywanej w JDBC. Oto wynik jednej operacji usunięcia wpisu:

QueryLoggingListener: Query: SELECT S.PRIMARY_ID, S.SESSION_ID, S.CREATION_TIME, S.LAST_ACCESS_TIME, S.MAX_INACTIVE[...]
QueryLoggingListener: Query: select post0_.id as id1_1_0_, post0_.author_id as author_i2_1_0_, post0_.content as co[...]
QueryLoggingListener: Query: delete from post where id=?
QueryLoggingListener: Query: UPDATE SPRING_SESSION SET SESSION_ID = ?, LAST_ACCESS_TIME = ?, MAX_INACTIVE_INTERVAL [...]
QueryLoggingListener: Query: SELECT S.PRIMARY_ID, S.SESSION_ID, S.CREATION_TIME, S.LAST_ACCESS_TIME, S.MAX_INACTIVE[...]

Spring aby usunąć jeden post wykonał aż pięć zapytań. Choć JWT również nie jest bez kosztów, ponieważ wymaga sprawdzenia poprawności podpisu, zdecydowanie wygrywa on w tym starciu. Kod użyty to testu z Session Cookie znajdziecie na branchu session-cookie.

Podsumowanie

JWT w Spring Security to konieczność w większych aplikacjach i technologia, którą na pewno warto znać. W artykule zobaczyliśmy, czym jest JWT i jak skorzystać z niego w Springu, rozwiązując 2 problemy: Ownership-based i Role-based Access Control, a także przewagę wydajnościową, jaką JWT daje nad Session Cookie.

5 komentarzy
1 FacebookTwitterPinterestEmail
HibernateOptymalizacjaPersystencja

Hibernate problem n+1 zapytań

by Grzegorz Sowa
written by Grzegorz Sowa

Często gdy apka zwalnia, obwiniamy bazę. Dokładamy instancji, zakładamy indeksy. Czasem to pomaga, ale w większości przypadków najlepszym wyjściem będzie sprawdzić, co nasz ORM wyprawia gdy nie patrzymy. Problem n+1 zapytań to jeden z najczęstszych błędów wydajnościowych aplikacji. Przyjrzyjmy się więc, na czym polega i jak można sobie z nim radzić.

Kod wykorzystany w tym artykule znajdziecie tutaj

Problem N+1 zapytań o zakupy

Przyjrzyjmy się przykładowej aplikacji, przechowującej historię zamówień ShopOrder użytkownika. Każde zamówienie składa się z kilku pozycji OrderPosition, czyli produktu i jego ilości.

@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PRIVATE)
class ShopOrder {

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

    private UUID clientId;

    @OneToMany(cascade = CascadeType.ALL)
    @JoinColumn(name = "order_id")
    private Set<OrderPosition> positions;

    static ShopOrder newInstance() {
        final ShopOrder shopOrder = new ShopOrder();
        shopOrder.positions = new HashSet<>();
        return shopOrder;
    }

    static ShopOrder of(UUID clientId, OrderPosition... positions) {
        final ShopOrder shopOrder = newInstance();
        shopOrder.clientId = clientId;
        for (OrderPosition position : positions) {
            shopOrder.addPosition(position);
        }
        return shopOrder;
    }

    void addPosition(OrderPosition orderPosition) {
        this.positions.add(orderPosition);
    }

    Set<OrderPosition> getPositions() {
        return Collections.unmodifiableSet(positions);
    }

}

Pozycja w zamówieniu:

@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PRIVATE)
class OrderPosition implements Persistable<UUID> {

    @Id
    private UUID id;
    @Transient
    private boolean isNew;
    private String product;
    private Integer quantity;

    static OrderPosition of(String product, Integer quantity) {
        final OrderPosition position = new OrderPosition();
        position.id = UUID.randomUUID();
        position.isNew = true;
        position.product = product;
        position.quantity = quantity;
        return position;
    }

}

Aby użytkownik mógł pobrać historię swoich zamówień, musimy zdefiniować odpowiednią metodę w repozytorium:

interface ShopOrderRepository extends CrudRepository<ShopOrder, Long> {

    Set<ShopOrder> findAllByClientId(UUID clientId);

}

Oraz endpoint do pobierania zamowień użytkownika:

    @GetMapping("/clients/{id}/orders")
    ResponseEntity<Set<ShopOrderDto>> getOrderWithId(@PathVariable UUID id) {
        final Set<ShopOrderDto> result = repository.findAllByClientId(id)
                .stream()
                .map(ShopOrderDto::of)
                .collect(Collectors.toSet());
        return ResponseEntity.ok(result);
    }

Właśnie tutaj kończy się zabawa a zaczyna problem N+1 zapytań. Hibernate odpytuje bazę najpierw o zamówienia użytkownika X. Gdy otrzyma N zamówień, dla każdego zamówienia odpytuje o jego pozycje, czyli dodatkowe N razy. Stąd bierze się nazwa problemu, tutaj jest N+1 zapytań.

problem-n-plus-1-zapytań

Testowanie problemu N+1 zapytań

Możemy w prosty sposób przetestować, czy nasza aplikacja nie ma problemów wydajnościowych przy pobieraniu zamówień. Jednak aby sprawdzić liczbę zapytań w teście, potrzebujemy dodatkowej biblioteki, pozwalającej założyć proxy na DataSource:

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

Teraz, za pomocą post-processora musimy „złapać” beana DataSource i owinąć go w proxy. Zdefiniujmy go dla profilu integration-test, żeby nie mieć go już w uruchomionej aplikacji:

@Component
@Profile("integration-test")
@RequiredArgsConstructor
public class DatasourceProxyBeanPostProcessor implements BeanPostProcessor {

    private final CountingQueryExecutionListener queryExecutionListener;

    @Override
    public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
        if (bean instanceof DataSource dataSource) {
            return ProxyDataSourceBuilder.create(dataSource)
                    .listener(queryExecutionListener)
                    .build();
        } else {
            return bean;
        }
    }
}

Jak widać, do proxy jest podłączany listener, który ma na celu zliczać zapytania wysyłane do bazy danych. Oto przykładowy kod takiego listenera, z metodami pozwalającym na pobranie liczby zapytań i reset ich licznika:

@Component
@Profile("integration-test")
@Slf4j
@RequiredArgsConstructor
public class CountingQueryExecutionListener implements QueryExecutionListener {

    @Getter
    private Integer count = 0;

    @Override
    public void beforeQuery(ExecutionInfo executionInfo, List<QueryInfo> list) {

    }

    @Override
    public void afterQuery(ExecutionInfo executionInfo, List<QueryInfo> list) {
        count = count + 1;
    }

    public void resetCount() {
        count = 0;
    }
}

Teraz możemy już napisać test:

@SpringBootTest
@AutoConfigureMockMvc
@ActiveProfiles("integration-test")
class HibernateNPlusOneDemoApplicationTests {

    @Autowired
    private MockMvc mockMvc;

    @Autowired
    private ShopOrderRepository repository;

    @Autowired
    private CountingQueryExecutionListener queryExecutionListener;

    private final UUID clientId = UUID.randomUUID();

    @Test
    void shouldLoadOrdersWithOneQuery() throws Exception {

        clientWithTwoOrders();
        queryExecutionListener.resetCount();

        getOrders()
                .andExpect(status().isOk());

        assertEquals(1, queryExecutionListener.getCount());

    }

// helper methods...
}

W teście generujemy dwa zamówienia dla tego samego klienta oraz wywołujemy endpoint historii zamówień:

    void clientWithTwoOrders() {

        List<ShopOrder> orders = new ArrayList<>();

        orders.add(ShopOrder.of(clientId,
                OrderPosition.of("Milk", 2),
                OrderPosition.of("Butter", 1),
                OrderPosition.of("Egg", 10),
                OrderPosition.of("Paprika", 2),
                OrderPosition.of("Cucumber", 1),
                OrderPosition.of("Banana", 5)));

        orders.add(ShopOrder.of(clientId,
                OrderPosition.of("Beer", 6),
                OrderPosition.of("Crisps", 2),
                OrderPosition.of("Peanuts", 2)));

        repository.saveAll(orders);

    }

    ResultActions getOrders() throws Exception {
        return mockMvc.perform(
                MockMvcRequestBuilders.get(String.format("/clients/%s/orders", clientId))
        );
    }

Test oczywiście nie przejdzie w tym stanie, bo oczekuje on, że aplikacja wykona tylko jedno połączenie do bazy danych – otrzymujemy następujący błąd:

[ERROR]   HibernateNPlusOneDemoApplicationTests.shouldLoadOrdersWithOneQuery:44 expected: <1> but was: <3>

Czyli zamiast jednego zapytania, dla klienta o dwóch zamówieniach poszło ich 3, czyli dokładnie N+1. Zobaczmy teraz, jak sprawić, aby test zabłysnął na zielono. Istnieje kilka rozwiązań tego problemu.

Fix: JPQL Query

    @Query("""
            SELECT o FROM ShopOrder o
            LEFT JOIN FETCH o.positions
            """)
    Set<ShopOrder> findAllByClientId(UUID clientId);

Teraz test powinien już przejść, nie polegamy tu na generowaniu zapytania przez ORM, a bierzemy stery we własne ręce.

Fix: Entity Graph

Specjalnie do tego celu w JPA 2.1 pojawiło się nowe rozwiązanie – EntityGraph. Jest to chyba najprostsze rozwiązanie, aby osiągnąć nasz cel, jednak nadal niepozbawione ograniczeń. W tym celu dodajemy w repozytorium adnotację:

    @EntityGraph(attributePaths = {"positions"})
    Set<ShopOrder> findAllByClientId(UUID clientId);

To wystarczy, aby metoda nie wykonywała nadmiarowych zapytań przy pobieraniu użytkowników. Rozwiązanie nie powinno też przeszkadzać we wprowadzeniu pagingu. Jednak napotkamy problemy, jeśli nasze zależności staną się wielopoziomowe, gdy encje zależne będą miały swoje kolekcje innych encji. Wtedy musimy zacząć definiować grafy z użyciem @NamedEntityGraph bezpośrednio nad klasą encji. Przy dużej liczbie różnych projekcji bardzo zaciemni to kod klasy encji, utrudni też zastosowanie wzorca CQRS.

Fix: Criteria Query

Criteria query to rozwiązanie wymagające napisania o wiele więcej kodu, jednak pozwalające na całkowite oddzielenie tego kodu od klasy encji, a nawet od standardowego repozytorium. Aby użyć criteria query będziemy musieli stworzyć klasę repozytorium. Aby podłączyć ją pod istniejący interfejs springowy musimy najpierw zdefiniować dodatkowy interfejs z metodą, którą chcemy zaimplementować:

interface ShopOrderCriteriaRepository {
    Set<ShopOrder> findAllByClientId(UUID clientId);
}

Repozytorium, którego już używamy musi rozszerzać nowy interfejs:

interface ShopOrderRepository extends CrudRepository<ShopOrder, Long>, ShopOrderCriteriaRepository {

}

Teraz zaimplementujmy dodaną metodę w klasie, którą opatrzymy adnotacją @Repository:

@Repository
public class ShopOrderCriteriaRepositoryImpl implements ShopOrderCriteriaRepository {

    @PersistenceContext
    private EntityManager entityManager;

    @Override
    public Set<ShopOrder> findAllByClientId(UUID clientId) {
        CriteriaBuilder criteriaBuilder = entityManager.getCriteriaBuilder();

        CriteriaQuery<ShopOrder> query = criteriaBuilder.createQuery(ShopOrder.class);
        Root<ShopOrder> shopOrder = query.from(ShopOrder.class);
        shopOrder.fetch("positions", JoinType.LEFT);
        query.select(shopOrder);

        TypedQuery<ShopOrder> typedQuery = entityManager.createQuery(query);
        return typedQuery.getResultStream()
                .collect(Collectors.toSet());
    }
}

Dzięki adnotacji @PersistenceContext korzystamy zawsze dokładnie z tego EntityManagera, który jest używany w kontekście danej sesji. Dzięki niemu możemy zbudować CriteriaQuery w którym możemy dowolnie zdefiniować zapytanie. Teraz też test powinien przejść, aplikacja wykona tylko jedno zapytanie do bazy danych.

To rozwiązanie jest najbardziej elastyczne z opisanych, pozwala w dość łatwy sposób zrobić paging i multi-poziomowe JOINy. Co więcej, pozwala na definiowanie skomplikowanych reguł filtrowania encji.

Podsumowanie

Budując aplikacje małe i duże, warto być świadomym takich problemów wydajnościowych, jak opisany w artykule. Jeśli natomiast nasze zapytania stają się coraz bardziej złożone, warto też przenieść je w zupełnie inne miejsce w aplikacji, na przykład za pomocą wzorca CQRS. Jeśli chcesz wiedzieć więcej o optymalizacji JPA, zajrzyj do tego artykułu.

0 comment
0 FacebookTwitterPinterestEmail
OptymalizacjaPersystencja

Optymalizacja JPA – 3 praktyczne wskazówki

by Grzegorz Sowa
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.

0 comment
1 FacebookTwitterPinterestEmail
OptymalizacjaPersystencja

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

by Grzegorz Sowa
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.

hibernate cache types

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.

0 comment
2 FacebookTwitterPinterestEmail