14강. 반복문 의존증

1. 내부적으로는 반복문 사용

• 반복문에 익숙한 개발자들은 레코드에 하나씩 접근하고 호스트 언어(절차형 언어)에서 반복 처리를 구현하는 경우가 간혹 있음
  • 온라인 처리에서 화면에 명세를 출력하고자 레코드 하나씩 접근하는 SELECT 구문 반복 사용
  • 배치 처리에서 대량의 데이터 처리할 때 레코드를 하나씩 호스트 언어에서 처리하고 테이블에 갱신

15강. 반복계의 공포

1. 반복계의 단점: 성능 저하

• 반복계 성능 <<< 포장계 성능

  • cf. 포장계: 여러 행을 한꺼번에 처리
  • 처리하는 레코드 수가 많아질수록 차이가 점점 더 벌어짐
  • 반복계 처리 시간: (처리 횟수)*(한 회에 걸리는 처리 시간) ← 선형 증가
  • 포장계 처리 시간: 완만한 곡선

• SQL 실행의 오버헤드

  SQL 실행 과정:

  1. 전처리

     1. SQL 구문을 네트워크로 전송

     2. 데이터베이스 연결

     3. SQL 구문 파스

     4. SQL 구문의 실행 계획 생성 또는 평가

  2. 후처리

     5. 결과 집합을 네트워크로 전송
  • 오버헤드 영향이 큰 것은 3) & 4)
  • 특히 SQL 파스는 DBMS마다 하는 방법도 미묘하게 다르고 종류도 굉장히 많음. 또한 DB가 SQL을 받을 때마다 실행되므로, 작은 SQL을 여러 번 반복하는 반복계에서는 오버헤드가 높아질 수 밖에 없습니다.

• 병렬 분산 어려움

  반복계는 반복 1회마다의 처리를 굉장히 단순화

  → 따라서 리소스를 분산해서 병렬 처리하는 최적화가 안 됨

  → CPU의 멀티 코어로 분산 처리를 할 수 없는 것은 물론 저장소의 분산 효율이 낮음

• 데이터베이스 서버 저장소는 대부분 RAID 디스크로 구성되어 I/O 부하를 분산

  → 하지만 반복계에서 실행하는 SQL 구문은 대부분 단순해서 1회의 SQL 구문이 접근하는 데이터양이 적으므로, I/O 병렬화 어려움

• DB의 진화로 인한 혜택 X

  • DBMS의 업데이트 목적은 **'대규모 데이터를 다루는 복잡한 SQL 구문'**을 빠르게 하려는 것.

    → 단순한 SQL 구문과 같은 '가벼운' 처리를 빠르게 만드는 것은 중요X.

    → So, 반복계는 미들웨어 또는 하드웨어의 진화에 따른 혜택을 거의 받을 수 없음

2. 반복계를 빠르게 만드는 방법은 없을까?

• 반복계를 포장계로 다시 작성

  : 어플리케이션 수정. 실제로 잘 쓰이지 않음

• 각각의 SQL을 빠르게 수정

  : 반복계에서 사용하는 SQL구문은 너무 단순하여 실제론 튜닝 가능성이 제한됨

• 다중화 처리

  : CPU 또는 디스크와 같은 리소스에 여유가 있고, 처리를 나눌 수 있는 키가 명확하게 정해져 있을 때만 가능

→ 반복계 튜닝은 선택지가 매우 한정적

3. 반복계의 장점

• 실행 계획의 안정성
  • 실행 계획이 단순하다 = 변동 위험 거의 없다
  • 반대로 말하면, 이는 포장계의 단점 (실행 계획의 변동 가능성 큼)
• 예상 처리 시간의 정밀도