모든 for문 stream으로 변경, 벌크 작업 리팩토링
Closed this issue · 3 comments
모든 for문 stream으로 변경, 벌크 작업 리팩토링
벌크 작업 리팩토링
기존에는 퀴즈를 업데이트 하는 로직을 하드코딩 하여 작성했습니다.
Why?
그렇다면 왜 이렇게 쌩 쿼리를 StringBuilder로 로직을 구성했는지 궁금하실 수 있습니다.
만약 JPA에서 제공하는 Dirty Checking을 통해 벌크 업데이트 작업을 하면 업데이트 할 데이터의 개수만큼 업데이트 쿼리가 나가게 됩니다. 그렇게 되면 만약 업데이트 건이 100만건이면 쿼리가 100만건이 나가는 셈입니다.
또한 제가 작성한 쿼리는 union을 사용하는데 이는 JPA에서 지원하지 않는 기능입니다.
이렇게 쿼리를 구성한 이유는 다음과 같습니다.
- 업데이트를 해야하는 건수가 몇개든 상관없이 딱 한번의 요청으로 한번에 처리하기 위해서
- 퀴즈같은 경우는 변경되는 퀴즈의 데이터만 요청이 들어오기 때문에
맨 처음에 보셧던 이미지와 같이 로직을 구성했을 시에 다음과 같은 문제가 있습니다.
- 자기 자신조차도 이해하기 힘든 가독성 떨어지는 하드코딩
- 추후에 변경사항이 있을 시 어려움이 있을 가능성이 농후함
- 만약 사용하는 DB의 종류가 바뀌었는데 문법이 다르면 문제가 생김
JPA에서는 union을 지원하지 않아 이를 querydsl을 통해 리팩토링을 진행하려고 합니다.
영상에서 우연히 보게 되었는데요. 전공자인 제가 허탈해질 정도로 참 많은 걸 하고 계신 것 같습니다.
대단하십니다. 건승하세요.
헉 아닙니다. 아직은 기본이 많이 부족합니다 ㅠㅠ
좋게 봐주셔서 감사합니다 😊
리팩토링 과정에서 왜 굳이 union을 고집해서 update해야 하지? 하는 생각에 mysql에서 사용할 수 있는 다양한 방법의 update를 테스트 진행했습니다.
제가 테스트 한 update 방식은 다음과 같습니다.
- union을 이용한 update
- when case을 이용한 update
- insert duplicate을 이용한 update
총 데이터의 개수가 1000개 기준으로 1000개의 데이터를 한번에 업데이트하는데 소요된 시간입니다.
유의미한 시간 차이를 못느껴, 데이터를 극단적으로 늘려 다시 테스트를 진행해 볼 계획입니다.