015. 반복계의 공포 - llighter/database GitHub Wiki

SQL 레벨업

성능

반복계와 포장계의 처리 시간

예제 그래프

• 반복계의 <처리 시간> = <처리 횟수> * <한 회에 걸리는 처리 시간> (처리 횟수에 비례)

SQL을 실행할 때 이뤄지는 다양한 처리

• 전처리

1. SQL 구문을 네트워크로 전송
2. DB 연결
3. SQL 구문 파스
4. SQL 구문의 실행 계획 생성 또는 평가

• 후처리

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

1, 5 는 DB와 애플리케이션이 같은 본체에 있다면 발생하지 않고 만약 다르더라도 같은 데이터센터 내부의 LAN 위에 있으므로 전송 속도 자체는 고속인 만큼 오버헤드가 딱히 일어나지 않는다.

2 또한 마찬가지로 애플리케이션에서 미리 연결을 일정 수 확보해서 이런 오버헤드를 감소시키는 커넥션 풀(Connection Pool)이라는 기술을 사용.

3, 4 가 오버헤드에 영향을 가장 많이 미친다. 특히 3같은 경우 종류에 따라 느린 부분은 0.1초~1초정도 걸린다. 또한 파슨느 DB가 SQL을 받을 때 마다 실행되므로 작은 SQL을 여러 번 반복하는 반복계에서는 오버헤드가 높아질 수 밖에 없다.

SQL은 실행 시간과 관계없이 일정한 오버 헤드가 필요

예제 그림 넣을 것

반복계는 반복 1회마다의 처리를 굉장히 단순화 한다. 따라서 리소스를 분산해서 병렬 처리하는 최적화가 안 된다.

• DB가 처리해야하는 데이터양이 급격히 증가하면서 DBMS 벤더, 하드웨어 벤더들도 인식하는 문제
• SSD 등의 매체가 활성화 되면서 저장소 넥(storage neck)에 시달리던 DB세계에 지각변동이 예고되고 있음
• 이러한 노력의 중심은 대규모 데이터를 다루는 복잡한 SQL 구문 을 빠르게 하려는 데 있다.
• 따라서 반복계와 같이 단순한 처리를 빠르게 하는 것과는 관련이 없다.
• 반복계는 단지 느리기만 한 것이 아니라 느린 구문을 튜닝할 수 있는 가능성도 거의 없다.

• 애플리케이션 수정을 의미
• 현장에서는 이런 '제안'은 현실적으로 사용할 수 없는 경우가 많다.(개발 일정)

• '티끌 모아 태산' 이면 좋겠지만 이미 단순한 구문이라 '티끌 모아 티끌' 이다.

• 가장 희망적인 선택지
• 처음부터 다중도를 설정할 수 있게 애플리케이션을 구성했다면 코드를 변경하지 않고도 확장 가능하다.
• 데이터를 분할할 수 있는 명확한 키가 없거나, 순서가 중요한 처리, 병렬화했을 때 물리 리소스가 부족하다면 이러한 방법은 불가하다.

• 실행 계획이 단순하다는 것은 해당 실행 계획에 변동 위험이 거의 없다라는 것을 나타낸다.
• SQL 구문 내부에서 결합을 사용하지 않아도 된다.
• 반대로 포장계는 SQL 구문이 복잡한 만큼 실행 계획의 변동가능성이 굉장히 크다.

<처리 시간> = <처리 횟수> * <한 회에 걸리는 처리 시간>

• 트랜잭션의 정밀도를 미세하게 제어할 수 있다.
• 예) 특정 이유로 배치를 잠시 중단해야 할 때도 해당 지점 근처에서 다시 처리를 실행할 수 있다.