[질문] IOT와 일반테이블 인덱스 스캔 0 3 1,655

by 손형선 [2007.10.25 08:25:33]


액세스 패턴은 주로 select  MEM , SHOP_ID 이고 where 에는 MEM_ID 가 들어간다고 할때, 둘다 MEM + SHOP_ID 를 PK로 가진다고 할때

 

IOT 로 만들면 FAST INDEX SCAN 이며, 블록 액세스가 없고

일반 테이블로 만들면 INDEX SCAN 이며, 블록 액세스가 없다면

 

IOT로 하나, 일반 테이블로 하나, 동일한 성능과 동일한 DML 부하를 가지는지 궁금합니다.


CREATE TABLE ITEM_MEMBERSHIP
(
 MEM_ID   VARCHAR2(10) NOT NULL,
 SHOP_ID  VARCHAR2(10) NOT NULL,
 PRICE   NUMBER  DEFAULT 0 NOT NULL,
 SVC_CODE VARCHAR2(10),
 MEM_NAME VARCHAR2(100),
 REG_DATE  DATE, 
 UPD_DATE  DATE,
 CONSTRAINT ITEM_MEMBERSHIP_PK PRIMARY KEY (MEM_ID, SHOP_ID)
 USING INDEX
 TABLESPACE GXG_IDX02
 STORAGE    (
   INITIAL          2M 
 )
)
 TABLESPACE GXG_DATA05
 STORAGE    ( 
            INITIAL          4M
 );
 
CREATE TABLE ITEM_MEMBERSHIP
(
 MEM_ID   VARCHAR2(10) NOT NULL,
 SHOP_ID  VARCHAR2(10) NOT NULL,
 PRICE   NUMBER  DEFAULT 0 NOT NULL,
 SVC_CODE VARCHAR2(10),
 MEM_NAME VARCHAR2(100),
 REG_DATE  DATE, 
 UPD_DATE  DATE,
 CONSTRAINT ITEM_MEMBERSHIP_PK PRIMARY KEY (MEM_ID, SHOP_ID))
         ORGANIZATION INDEX TABLESPACE GXG_IDX02
    STORAGE    (
   INITIAL          1M 
   )
         PCTTHRESHOLD 50 INCLUDING  SHOP_ID 
         OVERFLOW TABLESPACE GXG_DATA05
     STORAGE    (
   INITIAL          2M 
   );

by sleeper [2007.10.25 00:00:00]
1. access 타입이 =로 발생하여 소량의 데이터만 접근한다면 그다지 차이가 없지만 범위처리( >, < 또는 between)가 일어난다면 IOT가 더 좋은 성능을 냅니다. 아시다시피 b-tree인덱스의 scan시간은 미미하지만 실제로 table에 접근하는 시간이 크기 때문에 넓은 범위의 랜덤액세스가 발생하면 그 만큼 부하가 생기게 됩니다. IOT는 이런 면에 있어 leaf node를 연속적로 스캔만 하면 되기 때문에 힙 테이블에 비해 우수합니다.

2. DML이 IOT에 자주 발생 할 경우는 일반 힙 테이블에 비해서 그 부하가 과중됩니다. 인덱스에 로우 자체가 저장되기 때문에 로우의 길이가 변화가 된다면 체이닝이 되거나 또는 저장 밀도가 나빠져 데이터가 증가할수록 그 부담이 커질 것입니다. 이것을 해결하기 위해서는 OVERFLOW 영역의 적절한 지정과 그 위에 올라갈 컬럼들의 선정이 중요하겠지요. 예시로 든 IOT 테이블의 경우는 단지 MEM_ID와 SHOP_ID만 인덱스에 남아 있고 나머지는 overflow영역에 올라가게 되므로 위의 일반테이블과는 그 부하 정도가 같을 것으로 예상이 됩니다.

3. 다만 제가 추측으로 예상하는 것은, 전체테이블 검색이 발생할 때 일반 힙테이블은 테이블 자체를 스캔하면 되겠지만 IOT는 인덱스 영역과 overflow영역으로 데이터가 분리되어 있기 때문에 각 인덱스 컬럼에 따른 overflow영역의 접근으로 부하가 생기지 않을까 하는 의심을 해봅니다.

by 손형선 [2007.10.25 00:00:00]
답변감사합니다. 3번 케이스는 관리 사이트에서 조회할 경우만 간혹 발생하기 때문에 문제가 없을 것으로 판단해도 되겠죠? 그리고 로우 수는 14개 이구요.. 증가는 일년에 2-3로우 정도입니다. 수정될 일은 거의 없구요.

by sleeper [2007.10.25 00:00:00]
row 수가 14개이고 년에 2~3개만 증가한다면 일반 힙테이블로 구성해도 무방하다고 생각됩니다. db_block_size에 따라 다르겠지만 일반적으로 6블록 이하의 테이블이면 옵티마이져는 인덱스를 사용하기 보다는 테이블을 전체 스캔해버립니다. 인덱스를 타느니 멀티블록 액세스를 해서 읽어들이는 것이 더 빠르기 때문이죠. 한 row의 맥시멈 길이를 고려 하셔서 테이블을 설정하시면 될 것 같습니다.
댓글등록
SQL문을 포맷에 맞게(깔끔하게) 등록하려면 code() 버튼을 클릭하여 작성 하시면 됩니다.
로그인 사용자만 댓글을 작성 할 수 있습니다. 로그인, 회원가입