인프런 커뮤니티 질문&답변
작성한 질문수
더티체킹을 통한 수정과 delete() 메서드를 통한 삭제에 대한 질문입니다.
20.10.18 01:26 작성
·
399
1
안녕하세요 김영한 강사님.
기본편부터 Querydsl까지 강의를 듣고, 덕분에 예전부터 만들고 싶었던 사이드 프로젝트를 진행 중입니다.
진행 중에 기본적인 CURD를 하던 중, 기본편부터 말씀하신대로 수정은 더티체킹을 통해서 하고 있습니다.
여기서 궁금한게 더티체킹을 하기 위해 엔티티를 영속화시키려면 클라이언트에서 넘어온 id로 findById() 메서드를 통해 DB에 select를 꼭 한번 해주어야 하는건가요? 마찬가지로 삭제할 때도 클라이언트에서 넘어온 id로 엔티티를 조회 후 em.remove() 메서드에 인자로 넘겨주어야 하는건지 궁금합니다.
(제가 알고 있는 영속화 시키는법: em.persist, em.find)
기존에 개발하던 방식은 update문, delete문을 통해 한 번만 통신을 하였는데, 뭔가 select를 한 번 더 하자니 손해보는? 느낌입니다 ㅋㅋㅋ
아니면 상황마다 다르게 해도 되는지요? 예를 들면 실무에서 관리자 사이트 같은 실시간 트래픽이 많지 않은 곳은 더티체킹을 하고, 실시간으로 수정이 빈번하게 일어나는 고객 서비스에서는 update문을 직접 날리는 방식으로 하는 것처럼요.
그리고 실무에선 엔티티에 Setter 메서드를 웬만하면 사용하지 않고 의미있는 메서드명을 만들어서 사용한다고 하셨는데, 그럼 예를 들어서 Member 엔티티를 더티체킹을 통해 수정하려면 changeMember(String username, int age) 같은 메서드를 만들어서 사용하시는 건가요?
강의를 들을 땐 뭔가 다 이해가 되는 기분이였는데, 막상 실제로 개발을 시작하니 기존과 다른 개발 방식이 낯서네요 ㅋㅋㅋㅋ
그래도 덕분에 개발에 대한 새로운 눈이 띄여지는 것 같습니다.
답변 1
1
2020. 10. 18. 19:17
안녕하세요. Dobby님 좋은 질문입니다.
저도 처음 JPA를 사용할 때 이 부분이 딱 마음에 걸리더라구요. 역시 개발자는 성능 최적화에 민감합니다. ㅎㅎ
이 부분은 크게 걱정하지 않으셔도 되는데 그 이유를 설명드릴께요.
먼저 대부분의 애플리케이션은 조회가 9, 변경이 1정도 비율로 발생합니다. 그리고 성능 이슈의 대부분은 조회 중에서도 리스트처럼 여러 데이터를 조회할 때 발생하고, PK로 데이터 한 건을 직접 찍어서 조회하는 경우에는 성능 이슈가 거의 발생하지 않습니다.
결국 성능 관점에서 중요한 것은 암달의 법칙입니다. 애플리케이션 전체 성능 관점에서 볼 때, 90% 이상의 성능 이슈는 조회 중에서도 복잡한 리스트 조회에서 발생합니다. 그리고 데이터의 변경은 전체 애플리케이션 성능에 영향을 미치는 비율이 정말 작습니다. 거기에 PK로 데이터 한 건 조회하는 로직이 추가된다고 해도 받는 영향은 매우 미미합니다.
실제 제가 개발하고 운영했던, 하루 수백만의 쓰기, 변경 트랜잭션이 발생하는 여러 시스템들도 이것 때문에 성능에 문제가 되었던 적은 없습니다. 반면에 지연로딩으로 얻을 수 있는 이점은 매우 크지요.
추가로 질문하신 부분은 changeMember는 예이고, 비즈니스 의미가 듬뿍 담겨 있는 이름을 사용하는 것이 가장 좋습니다.
도움이 되셨길 바래요^^