SQL 레벨업 5장 반복문 (1)

 

- SQL에는 반복문이 없습니다. 

-> SQL은 일부러 반복문을 언어 설계에서 제외했는데,

    바로 '반복문은 필요 없잖아?'라는 생각 때문입니다. 

 

- 반복이 없으면 프로그램의 생산성 향상 외에도 큰 장점이 생깁니다.  

-> 반대로 말하면 반복계 코드에서 발생하는 큰 단점이 있습니다. 

 

 

15강 반복계의 공포

 

- 반복계 해답의 가장 '좋은 점'은 SQL을 잘 모르더라도 사용할 수 있다는 것입니다. 

-> 반복계가 가지는 몇몇 장점 중 하나가 바로 SQL 처리를 단순화할 수 있다는 것입니다.

-> 반대로, 여러 행을 한꺼번에 처리하는 SQL을 포장계라고 부릅니다.  

 

1. 반복계의 단점

- 반복계의 단점은 한 마디로 설명한다면 '성능'입니다.  

-> 같은 기능을 구현한다고 가정하면, 반복계로 구현한 코드는 

    포장계로 구현한 코드에 성능적으로 이길 수가 없습니다. 

 

- 처리하는 레코드 수가 적을 때는 반복계와 포장계에 큰 차이가 없습니다. 

-> 하지만 처리하는 레코드수가 많아지면 많아질수록 차이가 점점 더 벌어집니다.  

 

- 반복계의 처리 시간은 <처리 횟수>*<한 회에 걸리는 처리 시간>이므로,

  선형으로 증가합니다. 

-> 반대로 포장계의 경우, SQL의 패턴이 다양하므로,  

     완전히 이러한 대수 함수의 곡선이 된다고 단언할 수 없습니다.

-> 다만 인덱스를 사용한 접근이고, 실행 계획 변동이 없다고 한다면

    대부분 완만한 커브를 그리게 됩니다.  

 

1-1) SQL 실행의 오버헤드

 

- SQL을 실행할 때는 데이터를 검색하거나 연산하는 실제의 SQL 처리 이외에도 

  다양한 처리가 이루어집니다.

-> 대충 나열해본다면 다음과 같습니다.  

 

전처리

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

2) 데이터베이스 연결

3) SQL 구문 파스

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

 

후처리

5) 결과 집합을 네트워크로 전송

 

- 오버헤드 중에서 가장 영향이 큰 것은 3) 또는 4)입니다. 

-> 특히 SQL 파스는 DBMS마다 하는 방법도 미묘하게 다르고 종류도 굉장히 많습니다.

-> 또한 파스는 데이터베이스가 SQL을 받을 때마다 실행되므로,  

    작은 SQL을 여러 번 반복하는 반복계에서는 오버헤드가 높아질 수 밖에 없습니다. 

 

1-2) 병렬 분산이 힘들다

 

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

-> 따라서 리소스를 분산해서 병렬 처리하는 최적화가 안됩니다. 

-> CPU의 멀티 코어로 분산 처리를 할 수 없는 것은 물론 저장소의 분산 효율이 낮습니다.

 

- 데이터베이스 서버 저장소는 대부분 RAID 디스크로 구성되어 

  I/O 부하를 분산할 수 있게 되어 있습니다.

-> 하지만 반복계에서 실행하는 SQL 구문은 대부분 단순해서  

    1회의 SQL 구문이 접근하는 데이터양이 적습니다. 

-> 따라서 I/O를 병렬화하기 힘들다는 단점이 있습니다. 

 

1-3) 데이터베이스의 진화로 인한 혜택을 받을 수 없다

 

- 데이터베이스 처리해야 하는 데이터양은 최근 급격히 증가하고 있으며,  

  그에 따라 DBMS 벤더(vendor)는 어떻게 해야 SQL을 빠르게 할 수 있을지 

  계속 연구하고 있습니다. 

-> 따라서 DBMS의 버전이 오를수록 옵티마이저는 보다 효율적으로 실행 계획을 세우며,  

    데이터에 고속으로 접근할 수 있는 아키텍처를 구현합니다.

 

- 이렇나 모든 노력의 중심은 기본적으로 '대규모 데이터를 다루는 복잡한 SQL 구문'

  을 빠르게 하려는 데 있습니다.

-> 단순한 SQL 구문과 같은 '가벼운' 처리를 빠르게 만드는 것은 안중에도 없습니다.

-> 따라서 반복계는 미들웨어 또는 하드웨어의 진화에 따른 혜택을 거의 받을 수 없습니다. 

 

 - 물론 이러한 비교가 성립하려면 포장계의 SQL이 충분히 튜닝되어 있다는 것이 전제되어야 합니다. 

-> 일반적으로 포장계의 SQL은 반복계에 비해 굉장히 복잡합니다.  

-> 따라서 튜닝되지 않은 상태에서는 반복계에 질 수도 있습니다.  

-> 하지만 포장계의 SQL 구문은 튜닝 가능성이 굉장히 높으므로,  

    제대로 튜닝한다면 처음과 비교해서 현격한 성능 차이가 있을 것입니다.  

 

 

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

 

- 그럼 여러분이 관리하는 시스템에서 반복계로 성능이 제대로 나오지 않는다면 

  어떻게 튜닝하는 것이 좋을까요?  

  선택지는 크게 다음과 같은 세 가지입니다.

 

2-1) 반복계를 포장계로 다시 작성

- 이는 애플리케이션 수정을 의미합니다.

  하지만 실제 상황에서는 이러한 선택지를 사용할 수 없는 경우가 많습니다. 

 

2-2) 각각의 SQL을 빠르게 수정

- 반복계에서 사용하는 SQL구문은 너무 단순합니다.

  따라서 튜닝 가능성이 제한됩니다. 

 

2-3) 다중화 처리 

- CPU 또는 디스크와 같은 리소스에 여유가 있고,

  처리를 나눌 수 있는 키가 명확하게 정해져 있다면,

  처리를 다중화해서 성능을 선형에 가깝게 스케일할 수 있습니다. 

 

- 이렇게 반복계라는 것은 튜닝의 선택지가 굉장히 한정적입니다.

-> 따라서 반복계로 만든 애플리케이션이 느리다면 

    대대적인 애플리케이션 수정을 각오해야 합니다. 

 

 

3. 반복계의 장점

 

3-1) 실행 계획의 안정성

- 실행 계획이 단순하다는 것은 해당 실행 계획에 변동 위험이 거의 없다라는 것을 나타냅니다.

  변동이 일어난다고 해 봤자 겨우 옵티마이저에서 사용하는 인덱스를 바꾸는 정도입니다.

  따라서 실제 운용 중에 갑자기 실행 계획이 바뀌어 느려지는 현상은 일어나지 않습니다. 

 

- 반대로 말하면, 이는 포장계의 단점이라고 할 수 있습니다.

  포장계는 SQL 구문이 복잡한 만큼 실행 계획의 변동 가능성이 굉장히 큽니다.

  물론 옵티마이저가 잘 할 것으로 생각하면 장점이고, 

  위험하다 생각하면 단점이 되는 미묘한 부분입니다. 

 

3-2) 예상 처리 시간의 정밀도

- 실행 계획이 단순하고 성능이 안정적이라는 것은 추가적인 장점을 가져옵니다.

   바로 예상 처리 시간의 정밀도가 높다는 것입니다.  

   반복계의 처리 시간은 다음과 같은 간단한 식으로 표현할 수 있습니다.

        <처리 시간> = <한 번의 실행 시간> x <실행 횟수>

 

3-3) 트랜잭션 제어가 편리

- 반복계의 또 하나의 장점은 바로 기능적 측면입니다.  

  즉, 트랜잭션의 정밀도를 미세하게 제어할 수 있다는 것입니다. 

 

참고

- SQL 레벨업