인용하는 그림은 다양한 곳에서 가져왔음을 밝힙니다
5. 반복된(절차 지향형의 속박)
ch 14. 반복문 의존증
- RDB는 관계 전체를 조작의 대상으로 삼기 때문에 설계상에서 반복을 제외했다
ch 15. 반복계의 공포
- record at a time 사고 방식
- 반복계의 장점은 생각하기 쉽고 단순하다는 것
1) 반복계의 단점
- 성능
(1) SQL 실행의 오버헤드
- 전처리
- a. sql 구문을 네트워크로 전송
- b. DB 연결
- c. sql 구문 파스
- d. sql 구문의 실행 계획 생성 또는 평가
- 후처리
- e. 결과 집합을 네트워크로 전송
- a, e는 동일한 본체에 있거나 분리되어 있어도 고만고만함
- b는 요즘에 커넥션 풀이라는 기술로 오버헤드를 감소시킴
- c와 d가 주된 오버헤드이다. 그중에서도 c가 성가시다
- c는 db가 sql을 받을때 마다 실행하므로 반복계에서는 오버헤드의 비중이 커진다
(2) 병렬 분산이 힘들다
- 반본계는 하나씩만 처리하기 때문에 병렬처리가 힘들다
- 저장소의 분산 효율이 낮다(하나씩 처리하다보니 한번에 처리하는 데이터가 얼마안됨)
(3) 데이터 베이스의 진화로 인한 혜택을 받을 수 없다
- 대규모의 데이터를 효율적으로 다루기 위해 진화하고 있으나, 반복계를 사요하면 그 혜택을 받을 수 없다
- 포장계 sql이 반복계에 비해 복잡하므로 튜닝을 잘해야 하는 단점도 있는 반면 제대로만 튜닝하면 현격한 성능차이가 발생한다
- 반복계는 단순해 튜닝포인트도 적다
2) 반복계를 빠르게 만드는 방법은 없다
(1) 반복계를 포장계로 다시 작성
- 애플리케이션의 수정을 의미
(2) 각각의 sql을 빠르게 수정
- 너무 단순해 튜닝한 건덕지가 없음
(3) 다중화 처리
- 리소스 여유가 있고, 처리를 나눌 수 있는 키가 있고, 순서가 중요하지 않다면 다중화 가능
3) 반복계의 장점
- sql이 단순하다
(1) 실행 계획의 안정성
- 실행계획이 바뀌어 느려지는 경우가 없다
(2) 예상 처리 시간의 정밀도
(3) 트랜잭션 제어가 편리
ch 16. sql에서는 반복을 어떻게 표현할까?
1) 포인트는 CASE식과 윈도우 함수
|
|
|
|
현재 레코드에서 1개 이전부터 1개 이전까지의 레코드 범위 지정
상관 서브쿼리 : 서브쿼리 내부에서 외부 쿼리와의 결합 조건을 사용하고 해당 결합키로 잘라진 부분을 조작하는 기술
2) 최대 반복수가 정해진 경우(경우별로 분기 가능)
- 우편 변호와 가장 인접한 지역찾기 문제
(1) 윈도우 함수를 사용한 스캔 횟수 감소
- 인전 순위의 최소값을 서브쿼리에서 찾기 때문에 테이블 스캔이 2회 발생
- 인덱스 온리 스캔 : SELECT 모두에 인덱스가 있을 때 사용
3) 반복 횟수가 정해지지 않은 경우(경우별로 분기불가)
(1) 인접 리스트 모델과 재귀쿼리
- 이사 이력을 관리할때 포인터 체인을 사용
- 절차적으로 생각할때 가장 오래전에 살았던 주소를 찾는 방법은 재귀 공통 테이블식(recursion common table expression)이다. 계층 구조 찾는 법과 비슷하다
- 굉장히 유연하고, 꽤 효울적이지만 최근기능이라 지원안할 수도 있다.
(2) 중첩 집합 모델
sql 에서 계층 구조를 나타내는 방법은 크게 3가지
- 인접리스트 모델
- 중첩 집합 모델
- 경로 열거 모델 : 갱신이 거의 발생하지 않을 때 효율적
새로운 데이터가 생길때 마다 원 안에 추가하는 방법
ch 17. 바이어스(절차지향적)의 공죄
- RDB에서 고성능을 실현하고자 한다면 절차 지향적인 바이어스에서 자유로워저라!