본문 바로가기

Spring Data16

JPA exists 쿼리 성능 개선 Spring Data Jpa를 사용하다보면 해당 조건의 데이터가 존재하는지 확인 하기 위해 exists 쿼리가 필요할때가 많습니다. 간단한 쿼리의 경우엔 아래와 같이 메소드로 쿼리를 만들어서 사용하는데요. boolean existsByName(String name); 조금이라도 복잡하게 되면 메소드명으로만 쿼리를 표현하기는 어렵습니다. 조건문이 3개 이상이거나, 필드명이 너무 길거나 조건문 자체가 복잡하는 등등 그래서 이런 경우엔 보통 @Query 를 사용하는데요. 다만 이럴 경우 JPQL에서 select의 exists 를 지원하지 않습니다. (select exists 문법) 단, where의 exists는 지원합니다. 그래서 exists 를 우회하기 위해 아래와 같이 count 쿼리를 사용합니다. @Q.. 2020. 8. 6.
JPA에서 Reader DB 사용하기 (feat. AWS Aurora) 이전 시간 에 AWS Aurora 환경에서 Spring Batch ItemReader가 Reader DB를 사용 하는 것에 대해서 소개 드렸는데요. 이번엔 일반적인 JPA 기반의 웹 애플리케이션에서 Reader DB는 어떻게 사용할지에 대해서 소개드리겠습니다. AWS Aurora 기반의 환경이라고 하면 아래와 같은 환경을 이야기 합니다.일반적으로 DB의 확장이라고 하면 Write 요청은 Master로만 발생시키고, 나머지 Replica 되고 있는 DB들은 조회용 (ReaderDB) 으로 사용하는 구조인데요. 그렇다면 조회 요청에 한해서 어떻게 ReaderDB로 보낼지, JPA에서 문제는 없는지 알아보겠습니다. 1. 일반적인 사용법 이미 아시겠지만, @Transactional(readOnly=true) 가.. 2020. 8. 4.
[DynamoDB] Spring Data DynamoDB와 Embedded 개발 환경 구축하기 모든 코드는 Github에 있습니다. 이번 시간엔 로컬 개발 환경에서 DynamoDB를 Embedded로 활용하는 방법에 대해서 알아보겠습니다. 이미 도커를 적극적으로 테스트와 개발에 사용하고 계신 분들이라면 LocalStack 으로 구성하셔도 무방합니다. 참고: LocalStack을 활용한 Integration Test 환경 만들기 다만 아직 도커를 사용하고 있지 않거나, 굳이 도커 설치해서 매번 테스트를 돌릴때마다 도커를 실행하는게 귀찮다고 생각하시는 분들은 한번 고려해보셔도 좋을것 같습니다. 0. 들어가며 사용한 의존성은 다음과 같습니다. Spring Boot: 2.2.5 Spring Cloud AWS: 2.2.1 Spring Cloud Dependencies: Hoxton.SR3 Spring Da.. 2020. 3. 8.
[DynamoDB] Spring Data DynamoDB와 JPA 함께 적용후 문제 발생시 해결방법 모든 코드는 Github에 있습니다. Spring Data JPA를 사용중인 기존 프로젝트에 Spring Data DynamoDB 를 바로 적용하면 아래와 같은 문제들이 발생할때가 있습니다. Caused by: java.lang.IllegalArgumentException: Not a managed type: class XXX 혹은 BeanDefinitionOverrideException: Invalid bean definition with name 'XXXRepository' defined in null: Cannot register bean definition 어떨때 이런 문제가 발생하는지, 어떻게 해결하는지 빠르게 확인해보겠습니다. 1. 문제 상황 먼저 JPA만 프로젝트에 추가해서 테스트를 진행해보.. 2020. 3. 7.
Querydsl 에서 Group by 최적화하기 (feat. MySQL) 1. MySQL에선 Group by를 하면 정렬도 수행된다고? 일반적으로 MySQL 에서 Group By를 실행하면 file sort가 필수로 들어갑니다. 별도의 Order by가 쿼리에 포함되지 않았음에도 file sort가 발생하는 것이죠. Group by 실행시 해당 컬럼들을 기준으로 정렬이 되니 좋아보일수 있겠지만, 의도치 않게 성능 저하가 발생하는 이유가 되기도 합니다. 물론 인덱스에 있는 컬럼들로 Group by를 한다면 큰 문제가 되지 않습니다. 인덱스로 인해서 이미 컬럼들이 정렬된 상태이기 때문입니다. 정렬이 필요 없는 Group by 된 결과가 필요한 경우엔 굳이 정렬할 필요가 없겠죠? 이 문제를 해결하는 방법이 바로 order by null 입니다. 아래와 같이 order by null.. 2020. 2. 21.
MultipleBagFetchException 발생시 해결 방법 JPA의 N+1 문제에 대한 해결책으로 Fetch Join을 사용하다보면 자주 만나는 문제가 있습니다. 바로 MultipleBagFetchException 입니다. 이 문제는 2개 이상의 OneToMany 자식 테이블에 Fetch Join을 선언했을때 발생합니다. OneToOne, ManyToOne과 같이 단일 관계의 자식 테이블에는 Fetch Join을 써도 됩니다 이 문제에 대한 해결책으로 보통 2가지를 언급하는데요. 자식 테이블 하나에만 Fetch Join을 걸고 나머진 Lazy Loading로 모든 자식 테이블을 다 Lazy Loading으로 이럴 경우 성능상 이슈가 아무래도 해결되는게 아니다 보니, 좀 더 좋은 방법을 소개드리겠습니다. 모든 코드는 Github에 있습니다. 1. 문제 상황 One.. 2019. 11. 3.