[Discuss] 구성한 배치 잡에 대한 의견을 나누고 싶습니다.

[Ilisha29]

배치 잡을 구성할때 아래의 두 가지 방법을 떠올렸습니다.

[방법 1]

방법 1은 중간 연산을 저장하기 위한 필드를 만드는 방법이며, 여기서 생각할 수 있는 장점은 데이터를 메모리에 저장하지 않고 있는 장점이 있다고 생각하지만 단점으로는 DB 커넥션이 많아진다는 단점이 생각났습니다.

[방법 2]

방법 2는 JobExecutionContext에 맵과 리스트를 활용하여 중간 연산을 저장하는 방법이며, 장점은 커넥션 횟수가 적지만 단점으로는 인메모리에 저장을 하여 메모리를 많이 사용하는 점이 생각이났습니다.

그래서 저는 이중에서 불필요한 필드를 생성하는 방법 1보다는 방법 2가 더 효율적이라고 생각해서 방법2로 구현을 했는데 만약 제가 놓치고 있는 부분이나 혹은 더 나은 방법이 있다면 개발이 더 진행되기 이전에 수정을 하고자 선택한 방법이 괜찮은것인지 의견을 듣고 싶습니다.

[hyukjin-lee]

각각을 스텝으로 나누는 것보다 1step : reader(select) proccessor(convert ranking data) writer(save) 로만 구성해도 될 것 같은데 스텝으로 다 쪼개신 이유가 있을까요?

[Ilisha29]

우선은 saveRanking이라는 잡 처리되기 위해서 어떠한 스텝을 거치는지 다른 사람이 봤을 때 과정을 좀더 분명하게 하기위해서 위해서 쪼개게 되었습니다. 제가 스텝의 개념을 잘 못 이해하고 있는 것일지도 모르겠네용ㅎ..

그리고 기능적인 측면에서는 하나의 스텝으로 구성한다면 예를 들어 100개의 데이터가 존재하고 20개의 chunkSize로 처리를 한다면 map에 저장하고 정렬를하는 과정이 5번 실행될텐데 20개의 데이터가 저장될때 처음, 20개가 추가되어 40개가 되었을때 두번째 ... 100개가 채워지고 마지막으로 정렬을 또한다는건 불필요한 연산이라고 생각이 들었습니다.

[Ilisha29]

제가 생각한 기능적인 측면에서의 문제를 정리해보았습니다. 이해하시는데 도움되시길 바라겠습니다.

[hyukjin-lee]

select 쿼리에서 ordering 해서 가져오고 processor 에서 ranking 으로 변환만 해주면 되지 않나 해서요

[Ilisha29]

grass가 일별 기준이고 PK가 날짜 + 유저 ID여서
유져별로 모든 날에서 활동한 activity를 합해서 Map으로 저장했어야했는데

쿼리로 유저가 활동한 모든 activity 활동의 합을 계산하고 ordering해서 가져오라는 말씀이신가요??

오... 그렇다면 스텝하나로 처리 할 수 있을 것 같습니다