◆ Partition Table


우리가 테이블을 생성할 때 그 안에 들어갈 데이터의 양이 적으면 문제가 되지 않으나, 양이 굉장히 많을때는 파티션 테이블을 고려해야 한다.
예를 들어 직원이 20명 있는 회사의 사원 테이블은 일반 테이블로 만들어도 상관없으나, 판매 테이블 같은 경우는 파티션 테이블로 만들어야 좋다. (즉, 데이터의 양을 고려해서 잘 설계해야 한다.)
파티션 테이블은 확장이 가능하다.
위 그림의 테이블은 2000년도부터 2010년까지의 10년치 판매 데이터를 저장하고 있는 대용량 테이블이다. 그 테이블에서 2005년도 1월달 데이터만 찾고 싶을때, 보통 인덱스를 쓰면 빠르다고 생각할지 모르나 2만건 정도 되는 어마어마한 양의 데이터는 인덱스를 못 읽고, 옵티마이저가 풀스캔이 더 빠르다고 생각한다. 그래서 하드디스크 전체를 풀로 읽어버린다.
하지만 년도별로 테이블에 파티션을 나누어 관리하면 2005년도 파티션에서만 읽으면 되고, 또 필요시에 년도마다 각 개월로 서브파티션을 다시 나눌 수도 있기 때문에 관리가 편하다.


◆ Cluster
클러스터 또한 파티션 테이블과 마찬가지로 대용량 처리를 위해서 나온 개념이다.
파티션 테이블과 다른 점은 예를 들어 생각해보자.
유명한 학원 강사의 강의가 20명의 정원으로 수업이 진행되는데, 너무 인기가 좋아서 추가인원을 더 받고자 한다. 이때 첫번째 방법은 바로 옆 강의실과의 벽을 허물고 합치는 것과, 두번째 방법은 강의장을 다른 지점에 하나 더 개설하는 것이 있을 수 있다. 둘 중에 어느 방법이 더 좋은 방법일까? 물론 첫번째 방법이 더 좋을 것이다.
클러스터의 단점은 위 예 중 두번째 방법과 같다. 확장이 되지 않는다는 것이 클러스터의 단점이다.
클러스터는 데이터가 많을 경우에는 확장이 안되기 때문에 굉장히 불리하다. 그래서 거의 쓰지 않는 개념이다.


◆ IOT(Index-Organized Table)
보통 인덱스를 사용하여 테이블을 읽는 경우는 먼저 인덱스를 읽고, 그 다음 해당 테이블에 가서 필요한 데이터를 꺼내오는 방식이기 때문에 속도가 IOT에 비해서 느리다. 또한 인덱스로 인한 저장소의 낭비도 있다.
그래서 인덱스와 테이블을 결합시킨 개념이 등장했는데 그게 IOT이다.
IOT의 장점은 인덱스와 테이블이 합쳐있기 때문에 select 속도가 굉장히 빠르다.
단점은 DML시 굉장히 느리다는 것이다. IOT는 인덱스의 장단점을 그대로 담고 있다. update가 많이 일어나는 테이블을 IOT로 설계하면 끝장난다.
보통 제품코드 같은 경우는 자주 변경되는 데이터가 아니므로 IOT를 고려해볼 만 하다.

'오라클 > Admin' 카테고리의 다른 글

[Admin] ASSM(Automatic Segment Space Management)  (0) 2010.09.01
[Admin] Database Block  (0) 2010.09.01
[Admin] Temporary Tablespace  (0) 2010.08.30
[Admin] Tablespace and Datafiles  (0) 2010.08.30
[Admin] Redo Log File  (0) 2010.08.28
Posted by 겨울섬
,