code refactoring([feat] querydsl)

[celinaym]

:bulb: 이슈 내용

• 코드 개선

:white_check_mark: 작업 내용

• [x] Entity field 추가
• [ ] Test code 작성

:rotating_light: 주의 사항

• 진행 시 원본 copy한 후 진행

[celinaym]

각 order number당 주문한 item이 nested로 들어가게끔 개선 완료. JpaRepository findAll -> FetchType.Lazy로 설정했기 때문에 전체 조회를 했을 때 나오는 select문은 다음과 같다(3개의 order가 DB에 들어가있는 상황). select orders -> member -> orderHasitem -> item. 지연로딩 + stream을 사용하였기 때문에 orders, orderHasItem, member, item이 여러개라면 최대 1+N+N+N+N개의 select query가 나갈 수도 있는 상황이므로 개선 필요.

[celinaym]

• JpaRepository findAll vs queryDsl customRepository findAll compare 필요

[celinaym]

Jpa가 제공하는 findAll() 사용하지 않고(select문 많이 나갔던 문제점이 있었음) JPA에 customized된 getAllOrder()을 추가함으로써 select문이 한번만 나가도록 튜닝 완료

[celinaym]

findOne select문 한번만 나가도록 튜닝 완료

[celinaym]

가게 입장 -> orders pageable 기능을 이후에 추가할 경우 joinFetch(one-to-many) 걸어놓은 부분 변경 필요

[celinaym]

orderservice store joinfetch 삭제 *expected results -> 1) store select query 안나감 2) 상점, 유저 입장에서의 강한 결합상 끊어냄(ERD에서 item-store 연관관계 삭제할 예정)

[celinaym]

모의면접 때 멘토님이 피드백 주신 @BatchSize 사용하는 것으로 paging 처리 가능하게끔 하였습니다. 고려사항 1) application.properties에 global batch size를 우선 100으로 설정하였는데 DB에서 application 단으로 데이터를 전송할 때 DB가 부하를 얼마나 견딜 수 있냐에 따라 size 설정은 변동될 수 있습니다. 2) fetchJoin으로 모든 데이터를 다 끌어오는 것보다는 select query가 더 많이 나가지만 orderHasItem에서 item을 불러올 때 in절로 정보들을 한번에 불러오고 DB에서 아예 정보들이 최적화되어 app 단으로 가기 때문에 어떤 방법이 성능 최적화에 도움이 될지는 측정해봐야 할 것 같습니다.

[celinaym]

dummy datas가 DB에 다 들어가지는 대로 측정해봐야 할 것(순서)들은 다음과 같습니다. 1) JPA가 제공하는 findAll test -> main branch 2) customized findAll test -> main branch 3) store 연관관계 끊어놓은 것 test -> querydsl branch(PR 필요) 4) batch-fetch-size로 refactor한 findAll test -> orderRefactor branch(PR 필요) -> 우선 orders와 관련된 refactor는 여기까지만 진행하고 이후 성능 보고 필요하다면 추가적인 최적화 방안 생각해보도록 하겠습니다. @Puri12 @irupa94