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

- 테이블과 인덱스의 분리형

테이블과 인덱스가 별도로 분리되어 있는 구조는 관계형 데이터베이스의 가장 일반적인 데이터 저장형식이다.

비록 장점에 못지 않게 많은 단점을 가지고 있지만 대용량 데이터를 관리하기 위해서는 이 구조가 가장 

타당하기 때문이다. 

테이블스페이스(Tablespace)란 논리적인 저장공간을 말한다. 

마치 '내 소유의 토지', '종합복지시설을 신축하기 위해 마련해 놓은 부지' 를 표현하는 경우와 흡사하다.

이들은 위치와 크기, 종류가 서로 다른 것들을 결합하여 구성할 수 있다.

테이블스페이스는 물리적인 데이터파일(Datafile)로 구성 된다.

이렇게 구성된 테이블스페이스를 용도별로 나눌 수 있는데 이것을 세그먼트(Segment)라고 부른다.

세그먼트에는 데이터 오브젝트(Object)가 들어올 수 있다.

파티션이 발생한 테이블이나 인덱스는 각각의 파티션이 단위 오브젝트가 된다.

데이터파일의 식별자를 전체에 유일한 절대번호가 아닌 테이블스페이스 내에서 상대적인 번호를 붙이더라도 

하나의 오브젝트 내에서는 충분히 유일하게 식별될 수 있다.

이것은 로우식별자(Rowid)를 보다 짧게 구성할 수 있도록 하는 매우 중요한 의미를 가진다.

ROWID는 테이블에 존재하는 것이 아니라 인덱스에 존재한다.

ROWID의 오브젝트 번호와 데이터파일 번호를 통해 물리적인 저장위치를 찾아서 거기에 있는

블록번호를 찾아가면 슬롯이 나온다.

기존의 주소지에 연락처를 남겨두고 다른 곳으로 이사간 상태를 로우의 이주(Migration)이라 부른다.

이러한 이주현상은 로우나 테이블을 삭제하고 다시 생성해야만 치유할 수 있다.

클러스터링 (Clustering Factor)

인덱스의 컬럼값으로 정렬되어 있는 인덱스 로우의 순서와 테이블에 저장되어 있는 데이터 로우의 위치가

얼마나 비슷한 순서로 저장되어 있느냐에 대한 정도를 나타내는 것을 '클러스터링 팩터' 라고 표현한다.

분리형 테이블의 구조가 가지는 최대의 특징은 바로 데이터의 값에 전혀 무관하게 '임의의 위치'에 저장 된다는 

것이다. 이는 우리가 원하는 값을 찾으려면 필연적으로 여러 곳을 찾아보아야 한다는 것을 의미한다.

관계형 데이터베이스에서는 어떠한 경우에라도 최소한 하나의 블록은 엑세스 되어야 한다.

비록 우리는 로우를 액세스하지만 실제로는 블록이 액세스 된다.

그러므로 만약 이미 액세스해 두었던 블록에서 원하는 로우를 찾을 확률이 높다면 물리적으로

액세스할 블록의 량은 분명히 줄어들 것이다.

인덱스 전략이란 어떤 의미에서 보면 반드시 인덱스의구성 형태에 대한 전략을 수립한다는 의미 보다는 

그 테이블에서 발생할 수 있는 각종 액세스 형태의 특징을 감안하여 최적의 액세스를 할 수 있도록

하는 가장 이상적인 인덱스 구성전략을 수립하는 것을 말한다.

이러한 의미에서 분리형 테이블 구조에서 자장할 컬럼 순서를 결정하는 일은 당연히 종합적인 전략 차원에서

판단되어야 할 것이다.

넓은 범위의 액세스 처리에 대한 대처방안

대부분의 RDBMS 에서는 사용자가 부탁한 데이터 처리를 메모리 내에서만 처리하고 최종 목적지인 디스크에는

여유가 있을 때에 옮겨다 두는 지연기록(Differed write) 방식을 취하고 있다.

- 소형 테이블

 : 대부분의 소형 테이블이 중대한 액세스 형태에 속한다고는 볼 수 없으므로 특별한 경우가 아니라면 다른

조치를 하지 않아도 무방하다.

- 중형 테이블

 : 비록 등록시에는 부담이 되더라도 좋은 액세스를 위해서는 찾기 좋은 형태로 저장해 두는 것이 바람직해 

보인다. 그러나 특정한 위치에 저장해 두는 방법을 적용하더라도 그 형태는 한가지일 수 밖에 없는 것이므로

특정 컬럼값으로 찾을 때만 정돈된 것처럼 보일 뿐이라는 점을 간과해서는 안된다.

다른 컬럼의 입장에서 보면 제멋대로 흩어져 있을 수도 있다는 사실이다.

우리가 아무리 클러스터링 팩터를 향상시키기 위해 특정한 저장구조를 선택했다 하더라도 이미 분리형 구조는

필연적으로 존재할 수 밖에 없다는 것을 명심해야 한다.

- 대형 테이블

 : 인덱스를 전략적으로 구성하고 SQL의 실행계획을 최적화시키는 방법이 가장 중요하다.

인덱스 구조를 개선하는 일이나 SQL을 수정하거나 실행계획을 바꾸는 일은 상대적으로 쉽게 개선해 갈 수 있다.

하지만 테이블의 구조에 대한 문제는 내 마음대로 바꾸는 것이 쉽지 않기 때문이다.

클러스터링 팩터 향상 전략

분리형 구조와 같이 정해지지 않는 순서로 데이터가 저장 된다는 것은 의도적으로 우리에게 유리한

형태로 저장하는 것도 가능하다는 의미 이며 이것은 우리가 얼마나 전략적으로 접근하느냐에 따라 의외의 

효율을 얻을 수도 있음을 뜻한다.

분리형 구조는 저장 시에 우리가 강제로 좋은 클러스터링 팩터를 가질수 있도록 제어 할 수 있는 방법이 없다.

가능한 방법은 이미 저장되어 있는 데이터의 응집도를 높여 주는 수 밖에 없다.

이 말은 주기적으로 테이블을 재생성시켜 주는 방법을 사용하자는 것이다.

사실 이 방법은 대부분의 경우 응집도를 높이기 위한 목적이 아니라체인을 감소시키고 블록 내 데이터의 저장률

을 높여 불필요한 I/O를 줄이기 위해 사용하고 있다.

테이블을 재생성할 때 주의해야 할 것이 있다. 테이블에 데이터를 저장할 때 관련된 인덱스를 모두 제거하거나

비활성시키는 것이 좋다. 인덱스를 생성한 채로 대량의 데이터를 저장하면 테이블의 저장 속도가 크게

저하될 뿐만 아니라 인덱스에 많은 분할이 발생하여 인덱스 저장 밀도가 매우 나빠진다.

이것은 저장공간의 낭비뿐만 아니라 인덱스의 효율을 크게 떨어뜨린다.

- 인덱스 일체형 테이블

테이블과 인덱스가 일체형으로 되어 있다는 것은 인덱스와 다른 일반 컬럼들이 모두 같은 위치에 저장되는 

형태를 말한다. 그러므로 인덱스만 액세스하면 따로 테이블을 액세스할 필요도 없다.

하지만 무릇 지나치게 강한 결합은 그들 간에는 매우 우호적이지만 또 다른 쪽에서 보면 유연하지 못하고 배타

적이다. 일체형 구조는 커다란 장점에도 불구하고 많은 단점을 가지고 있기 때문에 정확한 이해를 바탕으로 활용

하여야 할 것이다.

일체형 테이블은 기존의 B-Tree 인덱스와 달리 ROWID를 가지고 있지 않다. 

테이블과 인덱스를 모두 가지고 있기 때문에 B-Tree 인덱스처럼 인덱스를 찾고 거기에 기록된 ROWID를 가지고

테이블의 데이터를 액세스할 필요가 없다.

기존의 B-Tree 인덱스로 해결하던 다양한 액세스 형태들 중에서 기본키 액세스를 좀더 향상시키려는 의도였다면

이 구조를 채택하는 것은 바람직하지 않다. 그런 경우에 가장 적절한 선택은 해쉬 클러스터를 활용하는 것이다.

우리가 아직도 이 구조를 많이 활용하지 않는 주된 이유 중의 하나는 로우의 길이의 변화에 따라 발생할 수 있는

오버플로우를 두려워하기 때문이다. 사실 B-Tree 인덱스는 대부분의 경우 나중에 NULL 값이 채워진다거나 

길이가 크게 변하는 일이 적기 때문에 이러한 걱정은 별로 하지 않는다.

B-Tree의 모든 노드는 2/3정도만 키값 들로 채워지므로 만약 그 이상의 키값이 채워져야 할 경우에는 키값 들은 두 개의 노드로 

분할되어진다. 이러한 논리적 한계 때문에 일체형 테이블은 영구적인 물리적인 어드레스를 가질 수 없다.

일체형 구조는 다음과 같은 경우에만 적용하는 것이 바람직하다.

◎ 전자 카탈로그나 키워드 검색용 테이블

◎ 코드성 테이블

◎ 색인 테이블

◎ 공간 정보 관리용 테이블

◎ 대부분 기본키로 검색되는 테이블

◎ OLAP의 디멘션 테이블

◎ 로우의 길이가 비교적 짧고, 트랜잭션이 빈번하게 발생되지 않는 테이블

우리가 일체형 테이블을 생성할 때 부여한 이동에 대한 임계치(PCTTHRESHOLD)에 도달하면 INCLUDING절에서 

지정한 컬럼 이후의 컬럼들은 모두 오버플로우 영역에 저장된다. 그러므로 테이블 생성 시에 컬럼을 지정할 때 순서를 

잘 결정할 필요가 있다. 

전략적으로 인덱스 영역과 오버플로우 영역을 나눌수 있는 가장 쉬운 방법은 현재 및 향후의 액세스 패턴을 분석하는 방법이다.

다시 말해서 사용되는 SQL을 분석해 보는 것이 가장 확실히다. 

- 클러스터링 테이블

분리형은 대량의 데이터를 범위처리해야 하는 경우에 많은 랜덤을 발생시키는 부담이 있었다.

일체형은 특정한 액세스에서는 랜덤이 없어졌지만 다양한 액세스 형태가 나타나면 오히려 더 많은 부담을 가져오므로 대용량의 

데이터에서는 적용하기 어렵다.

클러스터링이란 용어는 관계형데이터베이스에서 뿐만 아니라 기존의 데이터베이스나 O/S 에서도 자주 사용된다. 

그러나 여기서 말하는 클러스터링은 그것들과는 전혀 다른 의미를 가지고 있다.

클러스터는 테이블이나 인덱스처럼 저장공간을 가지고 있는 하나의 오브젝트(Object)이다.

클러스터는 클러스터링할 컬럼으로 생성된 클러스터 인덱스를 가진다.

단일테이블 클러스터링이란 지정된 클러스터에 하나의 테이블만 생성시키는 것을 말한다.

단일 테이블 클러스터링은 대량의 범위를 처리하더라도 랜덤 액세스를 현저하게 줄이고 스캔을 극대화 함으로써 일반 인덱스 

스캔에 비해 매우 효율적인 액세스가 가능하다.

다중테이블 클러스터링이란 단위 클러스터에 두 개 이상의 테이블을 함께 저장하는 것을 말한다.

각각의 테이블을 별도로 액세스할 수 있음은 물론이고, 각 테이블은 자신의 고유한 인덱스를 생성할 수 있다.

최대의 장점은 두 개의 테이블이 조인할 때의 효율이다.

조인할 대상이 같은 클러스터 내에 있다는 것은 연결을 위한 추가적인 액세스를 하지 않으므로 매우 효율적인 조인이 가능하다.

다중 테이블 클러스터링은 정규화 작업에 의해 어쩔 수 없이 분할된 테이블을 마치 하나의 테이블처럼 만들어 주는데 매우 

유용하게 사용할 수 있다.

클러스터링은 독자적으로 도입여부를 판단해서는 안 된다. 먼저 해결해야 할 애겟스 형태를 모두 수집하고, 보다 적은 비용이

드는 인덱스로 해결할 수 있는 방안을 강구해 보아야 하며, 이들 간에 역할의 중복으로 인한 투자의 낭비가 발생하지 않도록

적절한 역할분담을 해야 할 것이다.  물론 클러스터링으로 인한 부하의 부담도 충분히 고려되어야 한다.

클러스터링의 부하

클러스터링 테이블에 데이터를 입력하게 되면 정해진 위치를 찾아서 저장되어야 하므로 일반 테이블에 비해 추가적인 부하가 

발생할 수 밖에 없다.

클러스터링 테이블에 있는 컬럼값을 수정하는 경우의 부하는 두 가지로 나누어 생각해 볼 수 있다.

한 가지는 클러스터키 컬럼의 값을 수정시키는 겨웅이고, 다른 하나는 그 외의 일반 컬럼을 수정하는 경우이다.

수정이 빈번하게 발생하는 컬럼을 클러스터키 컬럼으로 지정하는 것은 좋지 않다. ( 클러스터링 팩터가 나빠 지기 때문에 )

클러스터링 테이블에서의 로우를 삭제시킬 때 추가적인 처리가 발생되는 것은 없다.

하지만 테이블 삭제 (Drop) 은 전혀 다르다. 일반 테이블의 DROP 은 DDL 이므로 롤백을 하지 않고, 각각의 로우를 찾아

삭제시키는 것이 아니라 Data Dictionary 의 정보를 삭제시키고 할당된 공간을 해제시키기만 하므로 매우 빠르다.

그러나 클러스터링 테이블을 삭제시키면 내부적으로는 DELETE 를 수행하게 된다.

불필요하게 된 과거의 데이터는 테이블을 삭제하는 것보다 클러스터를 삭제하는 것이 좋다.

아래와 같이 DROP 이나 TRUNCATE 명령을 사용하면 신속한 삭제가 가능하다.

DROP CLUSTER cluster_name

INCLUDING TABLES

CASCADE CONSTRAINTS;

TRUNCATE CLUSTER cluster_name REUSE STORAGE;

해쉬 클러스터링은 어떤 의미에서 보면 클러스터링이라고 하기 보다는 일종의 인덱스를 대신하는 개념으로 볼 수 있다.

테이블에 데이터를 정해진 위치에 저장한다는 입장에서 보면 클러스터링의 개념이고, 우리가 원하는 값을 찾아간다는 입장에서

보면 일종의 인덱스 개념이라 할 수 있다.

해쉬 클러스터는 활용범위가 아주 특정한 겨우에 한정된다.

해쉬 클러스터링의 활용 범위

· 특별한 경우가 아니라면 지속적으로 대량의 데이터가 증가하는 테이블에서는 적용하지 않는 것이 좋다.

· 각종 코드를 관리하는 소형 테이블이나, 우편번호, 시스템 사용자 정보를 관리하는 테이블에서 활용할 수 있다.