앞글에서 이야기한바와 같이 서버커서 선택의 제 1조건은 결과셋의 크기와 결과 셋에서 정말 사용할 비율이다.
이중 결과셋의 크기는 정상인 사람이 인터페이스를 고민하였다면 문제되는 바가 아니고 보다 중요한 것은 결과셋에서 실제 사용할 - 화면에 뿌릴 - 비율이다.
그렇다면 이렇게 생각해보자. 만약 애초에 정확히 사용할 데이타만을 결과셋으로 선택할 수 있다면 - 그렇게 쿼리를 작성할 수 있다면 - 굳이 서버 커서를 사용할 필요가 있을까?
일단 ForwardOnly와 Anonymous 종류는 커서의 이동이 안되고
Static과 Anonymous는 네트워크의 패킷 통신이 비효율적이며 서버의 메모리 자원을 많이 소모한다.
그리고 서버 커서 모두 연결 정리 작업을 이후에 해줘야 하는 단점이 있다.
클라이언트 커서 모델은 위와 같이 커서정보가 클라이언트에 있는 모델을 말한다. (당연히 기존의 커서는 커서가 모두 서버에 위치하였다.)
1. 쿼리 실행을 요청한다.
2. 쿼리를 실행하여 모든 결과 셋을 클라이언트에게 전송한후 연결을 끊는다.
3. 자신의 메모리에 로드된 결과셋을 사용한다.
클라이언트 커서의 주요 장점은 2단계에 있다. 결과셋을 가능한 모아서 던지며 모두 전송한후 클라이언트와 연결을 끊을 수 있다. (실제로는 이 과정을 soft close라고 하는데 실제로 바로 끊는게 아니라 언제든 자동으로 끊어 질수 있는 단계라고 생각하면 된다. 바로 끊어버리지 않는 이유는 clob이나 text등의 lob 객체는 결과셋 전송시 같이 이루어지지 않고 다시 요청이 오면 앞의 inner connection을 재연결해서 실제 데이타를 가져와야 하기 때문이다. 모든 DB는 lob 데이타를 다루는데 이러한 address 방식을 사용하기 때문에 모델링시 신중하게 결정해야 한다. 만약 자신의 환경이 이런 lob 데이타를 하나의 결과셋에 많이 포함하는 특수한 구조라면 서버커서도 마찬가지이니 이에 해당하는 클라이언트 커서 모델을 별도로 고려해보는게 좋다.)
일단 전송이 완료되면 클라이언트에 있는 결과셋은 기존의 서버에 있던 결과셋의 일종의 복제이므로 커서의 컨트롤 방식은 같고 커서의 전후진과 absolute 이동이 가능하다는 장점이 있다. 또한 보통의 경우 메모리 자원이 많이 요구되는 DB의 메모리를 보다 절약할 수 있기 때문에 자원의 균형적인 사용에도 도움이 된다.
이 방식의 유일한 단점은 앞서 말한바와 같이 정확히 사용할 데이타만을 결과셋으로 선택할 수 있는 SQL 쿼리 능력을 갖추는 일이다. 극한 성능을 위해 좀더 정확한 selection을 원한다면 쿼리가 좀 복잡하지만 만약 주로 앞부분의 데이타가 사용되는 페이징 인터페이스라면 단순히
(v_pageNo : 페이지 번호, v_listNum : 페이지당 리스트건수)
select columns
from
(select columns, rownum rnum from table where condition and rownum <= v_pageNo * v_listNum ) base
where rnum between v_listNum * (v_pageNo - 1) + 1 and v_pageNo * v_listNum and rownum <= v_listNum
로 정도로 사용(만약 MSSQL이라면 TOP N 형식으로는 N을 동적으로 사용할 수 없기 때문에 Set rowcount 를 이용해야 한다. ) 해도 기존의 서버 커서모델보다는 빠르니 그다지 미리 걱정할 필요는 없다. (클라인언트 커서 방식일때 좀 더 빠른 이유는 네트워크의 효율적 전송과 다중 사용자 환경에서 DB 서버의 메모리를 더 작게 그리고 더 적은 시간동안 사용하기 때문이다. )
클라이언트 커서 모델은 어쩌면 낳설게 들릴지 모르지만 이전의 POJO방식의 인터페이스의 기본 바탕이 되는 모델이다. 다만 OR-Mapping 프레임워크나 EJB에서는 row 단위 억세스가 일어나기 때문에 클라이언트 커서의 장점이 거의 나타나지 않는다. 이 블로그의 DB Framework는 클라이언트 커서 모델을 기반으로한 DB Framework이기 때문에 결과셋인 Rows는 클라이언트 커서를 사용한다.
'Framework > Database' 카테고리의 다른 글
DB Framework 2.0 Short Explain (3) | 2010.03.09 |
---|---|
Framework Cursor (cursor in MySql) (1) | 2010.02.24 |
Framework - 커서의 선택 .. and (0) | 2009.03.24 |
프로시저 vs SQL (0) | 2009.03.23 |
Framework - 커서(Anonymous) (0) | 2009.03.19 |