1. 개요
대용량 데이터를 처리할 때 내가 잘못 알고있는 부분이 있었다. 이를 정정하기 위해 이어서 기록한다.
2. 대용량 데이터를 처리하기 위한 접근 방향 설정
대용량 데이터를 처리할때 기본적으로 bulk collect와 같은 데이터 리스트를 불러오는 작업이 수반된다.
대용량 처리 시 성능까지 고려하다보니 인덱스 재정렬만 생각하였고, 이를 피하기 위해 반복문과 row 특정을 활용한 대용량 처리를 생각하였으나 접근 방법부터 틀렸다.
일단, 대용량 데이터를 처리하기 위해 로직을 어떻게 구성하느냐를 살펴보아야 한다.
- java의 반복문으로 처리할 수 있는 수준일 경우 : 애초에 성능적으로 이슈가 될 사안이 아니므로, 오류없이 데이터 분할처리를 가능하게 하는 것에 중점을 둔다.
- batch, bulk collect를 활용하여 처리가 필요할 경우 : 데이터 처리와 더불어 성능 이슈를 고려한다.
따라서 내가 진행했던 데이터 처리 방식은 리스트를 불러와서 bulk collect로 처리하기 하지만, 성능적인 고려사항이 없었으므로 정확한 데이터 처리에 집중하였다.
하지만 성능을 고려해야 할 경우, 이때는 인덱스 등의 제약사항을 고려해야 하지만 공부한 바에 의하면 생각보다는 복잡하게 생각할 정도는 아닌 것 같았다.
3. 대용량 데이터 처리에 대한 생각이 바뀌게 된 배경
일단 생각을 고치게 된 계기가, DBA께서는 어떻게 생각하고 계실지 여쭤보았는데 그 답변이 내가 너무 복잡하게 고려하고 있다는 생각이 들었기 때문이다.
몇가지 답변을 정리하면
- bulk insert 자체가 대용량데이터 처리를 하기 위해 고안된 것이고, 여기에 bulk collect가 포함된다.
- 인덱스 재정렬이라는 것은 bulk collect, 즉 select하는 컬럼이나 조건이 인덱스를 타느냐 full scan하느냐에 따라 달라진다. 무조건적으로 인덱스 재정렬이 일어나지는 않는다.
- 인덱스를 탈 경우 그것을 기준으로 재정렬되어 bulk 처리를 진행한다. 따라서 처리 순서가 중요하다면 order by를 명시해서 사용하고, 성능적인 이슈가 걱정된다면 차라리 bulk 처리를 할때 인덱스 재정렬 순서를 변경하라.
4. 정리
대용량 데이터 처리할 때 생각을 바꿔서 접근하자.
- bulk collect, bulk insert 자체가 대용량 데이터 처리를 위해 나온 것이다.
- 1번에 최대한 많은 양의 데이터를 보내어 부하 및 네트워크 처리 횟수 자체를 줄이되, db에 가해지는 한계점을 잘 확인한다(나의 경우 subList 100건으로 한계점을 확인).
- 대용량 데이터 처리를 할 경우 인덱스 재정렬, commit과 같은 작업은 나중에 진행한다.
5. 참고자료
bulk insert1 - https://xggames.tistory.com/m/78
bulk insert2 - https://velog.io/@horang12/2.-%EC%8A%A4%ED%94%84%EB%A7%81-%EB%B0%B0%EC%B9%98-%EC%82%AC%EC%9A%A9%ED%95%98%EA%B8%B0
