당연히 Java로 만든 배치가 DB프로시져의 성능을 뛰어넘기는 힘듭니다.
Java로 만든 배치는 DB 서버 밖에서 호출되니 네트워크 호출비용도 있고, 같은 서버에서 돌리더라도 JDBC 드라이버의 콜스택을 거쳐야하므로 성능에 불리합니다.
그러나 Java배치나 스프링배치가 가지는 장점도 많은데
1. 버전관리, 배포를 웹어플리케이션과 같은 방식으로 할 수 있습니다.
2. 부분적으로 테스트하기에 편합니다. 스프링배치처럼 구조가 나누어져 있지 않다면 읽는 부분만 따로 테스트, 쓰는 부분만 따로 테스트하기가 정말 힘듭니다. batch에서의 testablility는 생산성과 직결되는 문제인 거 같다라구요.
3. 꼭 DB서버가 하지 않아도 되는 작업은 다른 서버로 분리해서 DB서버의 자원을 조금이나마 절약하는 의미도 있습니다. DB서버는 분할해서 구성하는 비용이 크므로 대용량시대에는 가장 아껴야할 자원인데, 어플리케이션서버는 상대적으로 여러대로 늘이는 구성이 어렵지 않습니다. 스프링배치에서도 여러서버를 써서 분산처리하는 구성도 가능합니다.
4. 스프링배치를 쓴다면 배치 모듈을 세분화해서 추후에 기능을 추가하거나 에러를 재현하기 쉬운 구조로 유도합니다.
DB프로시져로도 잘 짠다면 유지보수성에 문제가 없을수도 있지만, 레거시 중에 몇천라인이 넘어가서 담당자외에는 손댈수가 없는 DB프로시져가 많습니다.
그리고 스프링배치은 생산성은 유사한 job을 모아서 factoryBean을 만들 때부터 나옵니다. FactoryBean을 잘 만들면 같은 유형의 Job이면 설정 1~2개만 바꿔서 새로운 job을 만들수가 있죠. 일종의 추상화의 틀로서 SpringBatch+나름대로의 FactoryBean이면 맨땅에서 만드는 것보다 훨씬 편합니다. 실제로 자사 배치는 서비스 코드만 바꿔치기하면 같은 배치 프로그램으로 다른 원천사의 배치가 처리됩니다.
반응형