Skip to main content

대용량 DB 솔루션 - 데이터 저장구조와 특징

1.1 테이블과 인덱스의 분리형​

테이블 - 데이터를 저장 인덱스 - 특정 데이터를 찾기 위한 경로로 사용되는 테이블과는 다른 별개의 객체

관계형 데이터베이스 이전에는 키와 데이터가 밀접한 관련이 있었다. 저장된 데이터에서 특정한 범위를 선별해서 조회 시, 키의 도움이 필수적 -> 데이터의 저장은 키에 의존적이었다.

분리형 테이블의 구조​

데이터가 저장된 블록 상태

  • 한번도 사용되지 않았던 블록
  • 일정량 이상의 빈 공간이 확보된 재사용 허용 블록
  • 잔여 공간이 일정 이하라 재사용 미허용 블록

활용 가능한 블록은 사용 목록(Free List)에 기록되었다가 데이터를 저장할 때, 사용할 블록으로 제공된다. 한 개의 Row가 한 조각 안에 모두 위치되도록 하기 위해, Row의 데이터가 끊어지지 않고 들어갈 수 있는 공간이 없다면 전체 블록의 Row 위치를 재배치한다.

블록 하단의 FREE SPACE는 이미 포함되어있는 Row들의 길이 변화시 사용하는 공간으로 테이블 정의 시에 파라미터로 지정할 수 있다.

인덱스 - ROWID​

인덱스의 ROWID - 오브젝트 번호 + 데이터 파일 번호(테이블마다의 일련 번호 + 블록 번호 + 슬롯 번호로 구성, 데이터 파일의 절대번호는 미포함

하나의 블록을 벗어나지 않는 경우​

블록 내에서 Row의 위치가 변경되더라도 ROWID는 변경되지 않음

집계한 여유 공간이 있더라도 이어진 조각이 없어 저장이 불가능해지면, 자동으로 블록의 Row를 재구성하는 응축 작업이 진행된다. if 여유 공간을 적게 지정 시, 빈번한 응축 작업이 발생하여 부하의 원인이 될 수도 있다. Row 길이가 증가할 확률이 높지 않더라도 수정이 빈번하게 발생할 가능성이 높다면 충분하게 여유 공간(PCTFREE)을 지정해주는 것 또한 하나의 처리 효율성을 위한 전략이다.

추가적인 블록을 사용하는 경우​

여유 공간을 충분하게 부여하더라도 기존 Row들의 길이가 너무 길어져서 응축을 하더라도 사용할 여유공간이 부족하게되면 다른 블록으로 부족한 공간을 메울 수 밖에 없다. Row가 다른 블록으로 이동은 ROWID의 변경을 의미한다. ROWID를 변경시키지 않는 방법에는 과거의 ROWID로 조회 시 변경된 ROWID를 넣어두는 방식이 있다. 해당 방식의 경우, 인덱스의 ROWID를 변경시키지 않는 대신 데이터 엑세스시 여러 블록을 읽어야하는 오버헤드가 존재한다.

Row Migration​

Row가 기존 블록에서 추가적인 외부의 블록으로 데이터를 옮기는 상태를 Row의 이주(Migration)이라 부른다. 해당 상태는 Row나 테이블을 삭제하고 재생성시 제거 가능하다.

Chain​

여러 블록에 걸쳐 데이터가 존재한다는 점은 Migration과 유사하다. 특정 Row의 길이가 한 블록을 넘는다면 어떤 방법을 사용하더라도 하나의 블록 내에는 존재할 수가 없는데 해당 상황에서 필요한 공간만큼 블록을 연결해서 저장하는 것을 '체인이 발생했다.' 라고 말한다.

블록 내부의 Row​

블록내에 존재하는 Row는 가변길이로 존재한다. NULL값이 존재한다면 나중에 값이 들어올 때, Row의 길이는 영향을 받고, 분할 저장되지 않기 위해 위치 이동이 발생할 수도 있다. Row의 이동에 의해 인덱스가 영향을 받지않으려면, 과거의 ROWID에 변경된 ROWID를 넣어두는 방식으로 인덱스가 관리되어야한다.