1. 문제인식프로젝트를 진행중 Reservation 엔티티와 Review 엔티티는예약을 한 사용자만 리뷰를 작성할 수 있도록 일대일 관계로 매핑되어있습니다.@Entity@Getterpublic class Reservation extends BaseEntity { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) @Column(name = "reservation_id") private Long id; ... @OneToOne(mappedBy = "reservation") private Review review; } @Entity@Getter@Table(name = "rental_home_review")p..
1. 고민의 시작기존의 계층형 구조의 프로젝트는 단순히 하나의 도메인에 대한 기능제공을 넘어 여러 도메인에서 다양한 기능을 제공하기 시작하면수많은 클래스 파일과 도메인이 얽히고 설켜 유지보수에 소요되는 비용이 점점 커지게 됩니다.특정한 기능과 연관된 기능들을 수정하기에 어디서부터 손을 대야할지 난감하기도 합니다.그래서 도메인 기반의 디렉토리 구조로 프로젝트를 변경하며 적용하는 과정을 기록해보려고 합니다. 2. 디렉토리 구조2.1 계층형 구조 가장 기본적이며 각 계층을 패키지로 표현하여 어플리케이션의 구조가 직관적으로 나타납니다.하지만 프로젝트의 규모가 조금만 커져도 패키지 내의 파일수가 겉잡을수 비대해지고특정한 도메인의 메서드를 찾기가 여간 수고롭지 않습니다. 2.1 도메인 기반 폴더 구조프로젝트를 이루..
현재 aws의 프리티어 등급의 EC2(1gb ram, 30gb ssd)와 RDS(MySql, 1gb ram, 2gb storage)그리고 ElastiCache(Redis, 0.5 gb ram)을 사용하여 springboot 프로젝트를 배포하고 있습니다. 대상으로 하는 조회 엔티티는 다음과 같습니다. 1. 현상현재 Repository 클래스에서 join을 통해 review의 평균점수, 개수를 기준으로 정렬하여 데이터를 조회하고 있는데아래는 데이터 20만건을 조회하였을때 평군 3초의 로딩시간이 소요되는것을 확인했습니다. 2. 워밍업 - 상속/구현을 사용하지 않고 querydsl 사용하기이전에 querydsl을 사용할 때에는 다음과같이 별도의 ~RepositoryCustom이라는 인터페이스를 생성하고해당..
aws에 spring boot로 만든 프로젝트를 배포 후에 생각지 못한 현상을 발견하게 되었습니다.첫번째 응답에서 매우 느린 응답 지연현상을 발견했기 때문입니다. 처음에 이유는 분명 어딘가에서 쿼리 결과를 캐싱하고 있다고 생각했습니다. (이제와서 다시보니 캐싱되었다고 보기에는 3초의 시간은 너무 느리네요ㅎㅎ..)현재는 따로 쿼리 결과를 Redis에 캐싱하지 않고 있어 어디에서 캐싱을 하고 있는지 알아내려고 했습니다. 1. 데이터베이스(Mysql) 쿼리 캐싱Mysql 8.0 버전 이상부터는 쿼리 캐싱이 제거되었다고 합니다. 따라서 8.0 버전을 쓰고 있는 저에게는 해당 사항이 없습니다. 2. JPA의 1차 캐싱Jpa의 1차 캐싱은 같은 트랜잭션 내에서 유효합니다.API를 여러번 호출 했을 때, 각 호출은 ..
