• 카테고리

    질문 & 답변
  • 세부 분야

    백엔드

  • 해결 여부

    미해결

many to many entity 생성관련 질문

21.05.08 22:06 작성 조회수 136

0

안녕하세요 spring / jpa 관련해서 김영한님 강의 수강하면서 공부중인 대학생입니다!
querydsl 강의의 절반정도 까지 들은 시점에서 궁금증이 생겨 처음으로 질문남깁니다.

Member, Product 엔티티들의 다대다 관계를 설명해주는
MemberProduct  엔티티가 존재한다고 생각했을때,
MemberProduct 엔티티를 새로 생성해 Member 와 Product의 관계를 하나 만들어 주는 과정에서 성능관련 질문이 있습니다.

지금까지 배운 내용으로는 실제 서비스에서 아래의 5단계를 통해 관계를 생성한다고 이해하고 있습니다.

1. MemberProduct  엔티티를 생성하기 위해 특정한 post 메서드의 api 실행

2. api의 parameter 로 Member id, Product id (혹은 id가 아니더라도 엔티티의 유일성을 특정할 수 있는 어떤 값)를 전달받음

3. 전달 받은 memberId 와 productId를 이용해 memberRepository와 productRepository 를 이용
특정한 Member/ Product 엔티티를 가져옴 (이 경우 2번의 db 조회)

4. 가져온 Member / Product 엔티티를 이용하여 new MemberProduct(member, product, 그외 필드) 와 같은 방식으로 MemberProduct 엔티티 생성

5. memberProductRepository.save 이용하여 관계 저장

 이때 3번 단계에서 member 와 product를 findById 같은 메서드를 이용해 찾아오는 과정에서 불필요한 네트워크 호출이 생기는 것이 아닌가 라는 생각이 들어 질문 드립니다.

 productId 를 이용해 product를 조회할때는 디비에 존재하지 않는 product에 대해서 연관관계를 만드는 경우를 대비해서 디비에 존재하는지 확인차 조회해야한다.. 라는 생각이 들지만,
 memberId 같은 경우는 실제 서비스에서는(저는 실무 경험이 없어서 정확하게는 모르겠습니다..) security의 인증을 통해 jwt에서 디코딩해서 전달받거나 혹은 다른 인증방법을 통해 안전하게 전달받는다는 생각이 들어 굳이 member 가 존재하는지를 확인하기 위해 memberRepository를 이용해 디비에서 조회를 해야하나라는 생각이 들었습니다.

 또한 querydsl 을 수강하기 전까지는 MemberProduct에 반드시 Member 타입의 필드가 있어야지 조인의 기준이 정확해져서 쿼리를 날릴때 도움이 되겠다라는 생각도 했지만,
 querydsl 을 이용하면 Member member필드대신  Long memberId 필드를 MemberProduct에 넣어서 테이블 조인의 기준으로 사용해도 어렵지 않을것 같다는 생각이 듭니다.
 물론 Member member필드대신  Long memberId 필드를 이용하고 DDL AUTO 를 사용하면 db에 정합성 문제가 생기겠지만, database는 어차피 둘다 똑같이 bigint 타입의 컬럼으로 인식하기 때문에 직접 ddl을 설정해주면 정합성 문제는 해결될것같습니다.

위와 같은 문제가 실제 서비스에서 고려되는 정도의 성능 문제를 야기하는지, 
만약에 실제 서비스에서 고려되는 문제라서 엔티티 대신 엔티티의 primary key를 필드로 이용해 관계를 만든다면, 어떤 문제가 발생하는지,
그렇게 만든 관계 엔티티에서는 domain driven dev관점에서 어떻게 해야할지가 궁금합니다.

작년 연말에 우아한테크콘서트도 재미있게 봤습니다
긴 질문 읽어주셔서 감사합니다!

답변 2

·

답변을 작성해보세요.

1

헉.. 동일한 내용의 질문이 있었군요.
궁금했던 부분이 명확해졌습니다 감사합니다!

0

안녕하세요. 세현님^^

사실 이런 부분은 애플리케이션 전체로 보면 성능에 영향을 주는 부분이 미미합니다. 대부분의 비즈니스가 조회가 많고 등록 같은 부분은 매우 적기 때문이지요.

그리고 엔티티 하나를 인덱스를 정확하게 찍어서 DB에서 조회하는 경우에도 성능에 영향을 주는 부분은 미미합니다.

그래도 성능상 최적화를 하고 싶으면 프록시를 사용하면 됩니다.

예를 들어서 3번의 경우에도 Member, Product를 조회할 때 프록시로 조회하시면 됩니다. 프록시는 PK(@Id)를 가지고 있기 때문에 PK만 사용한다면 실제 엔티티를 DB에서 조회하지 않습니다.

이렇게 프록시를 사용하면 고민하셨던 성능 문제를 대부분 해결할 수 있습니다.

JPA 강의의 프록시와 다음 내용도 참고해보시면 도움이 되실거에요.

https://www.inflearn.com/questions/204850

감사합니다.