데이터이야기
DB 노하우, 데이터직무, 다양한 인터뷰를 만나보세요.
어플리케이션 파티션과 데이터 파티션은 동시에 이루어 져야 한다. 어플리케이션 파티션과 데이터 파티션은 분리해서 생각할 수 없다. 각각을 최적화하여 RAC를 최적화할 수 없게 된다. 결국, 데이터 파티션만을 적용하여 해당 RAC를 최적화할 수 없으며 어플리케이션 파티션을 통해서만 해당 시스템을 최적화할 수는 없다. 두 가지 항목이 조화를 이룰 때 최적의 성능을 기대할 수 있게 된다. 그렇다면 어플리케이션 파티션과 데이터 파티션은 무엇을 의미하는 것인가 각각의 정으부터 확인해 보자. 첫 번째로 어플리케이션 파티션을 확인해 보자. 동일한 조건의 값을 가지는 SQL이 A 서버와 B 서버에서 수행된다면 해당 어플리케이션은 데이터 이전 현상을 발생시키게 될 것이다. 아래와 같은 경우를 확인해 보자. ==================================================================== SQL> SELECT 거래일자, 사용자명, 거래금액 FROM 거래내역 WHERE 고객번호 = ‘1111’; SQL> SELECT 거래일자, 사용자명, 거래금액 FROM 거래내역 WHERE 고객번호 = ‘1112’; ==================================================================== 고객번호 값에 따라 첫 번째 SQL은 A 서버에서 두 번째 SQL은 B 서버에서 수행된다면 해당 SQL만 고려한다면 데이터 이전 현상은 발생하지 않게 된다. 결국, 서버 별로 WHERE 조건의 값에 따라 분리한다면 해당 SQL들은 데이터 이전이 발생하지 않을 수 있을 것이다. 이와 같이 하나 하나의 SQL에 대해 수행될 서버를 어떻게 선정할 지가 어려운 문제일 수 있다. 하지만 조금만 더 깊게 생각한다면 이도 어려운 일은 아닐 것이다. 이는 뒤에서 예제로 확인해 보도록 하자. 어플리케이션 파티션은 위와 같은 형태 말고도 아래와 같이 구현할 수 도 있을 것이다. 어떤 카드 회사의 승인 정산 업무를 수행하는 시스템을 예로 들어보자. 해당 시스템에서 승인 업무는 A 서버에서 수행하고 정산 업무는 B 서버에서 수행할 수 있게 구성하는 것이다. 이와 같이 구성한다면 완전히 업무가 서버 별로 분리되어 어플리케이션 파티션이 구현되게 된다. 어플리케이션 파티션은 이와 같이 WHERE 조건의 값에 의해 분리할 수도 있고 업무를 서로 다른 서버에 배치하여 어플리케이션 파티션을 구현할 수 있다. 어느 방법을 선택해도 괜찮다. 중요한 것은 어느 방법을 선택했을 경우 데이터 파티션과 조화를 이룰 수 있는지를 고려하여 최적의 구성을 구현해야 할 것이다. 두 번째로 데이터 파티션에 대해 확인해 보자. 서로 다른 서버에서 서로 다른 데이터 블록을 엑세스하게 만드는 것이 데이터 파티션의 주된 목적이다. 결국, 블록 별로 A 서버에서 엑세스되는 블록은 계속 A 서버에서만 엑세스되게 하고 B 서버에서 엑세스되는 블록은 B 서버에서만 엑세스되게 하는 것이 데이터 파티션의 목적이다. 이와 같은 데이터 파티션을 구현하기 위해서는 여러 가지 데이터베이스 아키텍쳐를 적용해야 할 것이다. 앞서 언급한 어플리케이션 파티션과 결합하여 데이터 파티션을 확인해 보자. WHERE 조건으로 어플리케이션을 구분한 경우에는 데이터 파티션은 아래와 같이 3가지 정도의 아키텍쳐를 사용할 수 있다. 클러스터 팩터 최적화를 먼저 확인해 보면 클러스터 팩터는 어떤 컬럼으로 동일한 값을 가지는 데이터를 모아서 저장하는 것을 의미한다고 지난 호에 언급했다. 따라서, 거래내역 테이블을 고객번호로 클러스터 팩터를 최적화한다면 어떻게 되겠는가 앞서 언급한 두개의 SQL은 테이블의 동일한 블록을 엑세스할 확률은 거의 없어지게 된다. 물론, ‘1111’번 고객 데이터와 ‘1112’번 고객 데이터가 동시에 저장되는 하나의 블록 정도는 두 서버에서 동시에 엑세스할 수도 있을 것이다. ‘1111’번 고객 데이터와 ‘1112’번 고객 데이터가 동시에 저장되는 현상은 클러스터 팩터 최적화를 수행하면서 하나의 블록에서만 발생할 수 있게 된다. 이와 같이 어플리케이션 파티션의 첫 번째 방법을 사용하며 해당 컬럼으로 클러스터 팩터를 최적화하는 작업을 수행한다면 데이터 이전이 완전히 제거되지는 않지만 많은 부분에서 데이터 이전은 감소하게 될 것이다. 파티션 테이블을 사용하게 되면 어떤 현상이 발생하게 되는가 예를 들어, A 서버에서는 1로 시작하는 고객만이 엑세스되고 B 서버에서는 2로 시작하는 고객만이 엑세스된다고 가정하자. 해당 테이블을 고객번호 컬럼을 기준으로 범위 파티션으로 구성한다면 어떻게 되겠는가 물론, 파티션 테이블은 고객번호 컬럼의 값이 ‘1’로 시작하는 데이터는 PART_1 파티션으로 고객번호 컬럼의 값이 ‘2’로 시작하는 데이터는 PART_2로 저장하게 만든다고 가정하자. 위와 같이 파티션 테이블을 구성한다면 PART_1 파티션은 ‘1’로 시작하는 고객번호 컬럼의 값으로 데이터를 엑세스하는 A 서버에서만 데이터를 조회하게 되며 PART_2 파티션의 데이터는 ‘2’로 시작하는 고객 데이터를 엑세스하는 B 서버에서만 조회하게 된다. 이와 같이 구성한다면 A 서버에서 엑세스하는 데이터와 B 서버에서 엑세스하는 데이터는 중복될 수 없을 것이다. 따라서 거래내역 테이블을 조회하는 어플리케이션은 데이터 파티션에 의해 데이터 이전이 발생하지 않게 된다. 테이블 정규화는 어떠한가 A 서버와 B 서버에서 조회하는 테이블을 분리하여 서로 데이터 이전이 발생하지 않게 구성하는 것이 테이블 정규화 방법이다. 물론, 테이블을 정규화하므로 경우에 따라서는 모든 데이터를 엑세스할 수 있게 뷰로 제공해야 할 경우도 발생하게 된다. 어플리케이션 분산과 데이터 분산을 구현하자. 하나의 예제를 통해 데이터 분산과 어플리케이션 분산을 확인해 보자. 아래와 같이 가정을 하자. 위와 같은 업무 조건에 대해 RAC를 이용하여 어떻게 데이터 파티션을 처리할 수 있을 까 위의 조건을 통해 데이터 파티션 뿐만 아니라 해당 어플리케이션의 성능을 고려하여 아키텍쳐를 구성해 보자. 우선 어티션을 고려하여 어플리케이션 아키텍쳐를 구현한 각각의 서버에는 500만 고객이 엑세스할 수 있도록 분리하는 것이 유리하다. 물론, 500만의 고객이 평균적으로 균등한 통화내역 데이터를 엑세스한다고 가정하자. 이와 같다면 파티션 아키텍쳐만 적용해도 데이터 파티션은 충분할 것이다. 통화내역 테이블을 고객번호 컬럼을 기준으로 500만씩 분리하여 2개의 파티션으로 구성하는 것이다. 이와 같이 구성한다면 각각의 서버에서는 하나의 파티션 만을 집중적으로 엑세스하게 된다. 그러므로 해당 통화내역 테이블에 대해서 데이터 이전은 발생하지 않을 것이다. 또한, 통화내역 조회를 수행하는 순간 함께 조인을 수행하게 되는 고객 테이블의 경우에도 위와 마찬가지로 고객번호 컬럼 값으로 2개의 파티션으로 구성한다면 해당 테이블 또한 각각의 서버에서 각각의 파티션만을 엑세스하게 되므로 데이터 이전 현상은 발생하지 않게 된다. 여기까지만 구성하여도 우리는 데이터 이전에 의한 성능 저하는 발생하지 않게 될 것이다. 또한, 번호 별로 엑세스하는 어플리케이션의 성능을 고려하여 고객번호 컬럼으로 클러스터 팩터를 최적화할 수 있을 것이다. 이와 같다면 데이터 이전이 발생하지 않을 뿐더러 하나의 고객번호 값으로 조회하는 통화내역 조회는 클러스터 팩터 최적화로 탁월한 성능을 기대할 수 있게 된다. 추가로 통화내역 테이블에 대해 보관 주기를 관리해야 한다면 어떻게 되겠는가 이미 해당 테이블은 범위 파티션을 이용하여 고객번호 컬럼으로 2개의 파티션을 구성하였다. 하지만, 보관 주기를 관리해야 한다면 우리는 또 한번의 어려움에 부딪히게 된다. 이와 같은 경우 우리는 어떻게 해야 하는가 해당 테이블을 정규화하여 두 개의 테이블로 생성하는 것이다. 각각의 테이블은 500만 고객을 관리하게 되며 해당 테이블들을 각각 보관 주기를 관리하는 일자 컬름으로 범위 파티션을 구성한다면 우리는 보관 주기도 관리하면서 테이블에 대한 데이터 이전도 제거할 수 있게 된다. 물론, 전체 데이터를 엑세스해야 한다면 두 테이블을 합한 뷰를 제공할 수도 있을 것이다. 이 얼마나 간단하면서도 강력한 방법인가 이번에는 서버에서 고객번호 컬럼의 값으로 구분하지 않는 경우에는 어떠한가 이 경우에는 모든 고객번호가 어느 서버에서나 엑세스될 수 있다는 가정이다. 이와 같다면 각각의 서버에서 어떤 고객번호의 데이터를 엑세스하게 될지 예측할 수 없게 된다. 이와 같은 경우에는 클러스터 팩터만을 최적화한다면 데이터 이전에 대해 많은 부분이 해결될 수 있다. 예를 들어, 하나의 고객 데이터가 A 서버에서 엑세스되고 다른 고객의 데이터가 B 서버에서 엑세스된다면 둘 간에는 데이터 이전이 거의 발생하지 않게 된다. 이는 해당 통화내역 테이블을 고객번호 컬럼으로 클러스터 팩터를 최적화했기 때문에 하나의 블록에는 서로 다른 고객번호 값을 가지는 데이터가 여러 개 저장되기 힘들기 때문이다. 이와 같이 구성한다면 A 서버에서 ‘111’번 고객의 통화내역 테이블을 조회한 후 바로 B 서버에서 해당 고객번호의 데이터를 엑세스하는 경우에만 데이터 이전이 발생하게 된다. 결국, 해당 테이블은 RAC의 성능 저하의 원인인 데이터 이전 현상이 감소하게 된다. 이와 같은 데이터 이전의 감소로 우리는 성능 향상을 기대할 수 있을 것이다. RAC에서 데이터 이전은 성능에 있어 매우 중요한 요소이다. 시대가 변하면서 더 많은 사이트에서 RAC를 이용하게 될 것이다. 또한 데이터는 대용량 데이터베이스로 변하고 있는 것이 현실이다. 이와 같은 상황에서 어플리케이션 파티션과 데이터 파티션을 고려하지 않는다면 어떠한 방법으로도 성능 향상을 기대하기는 힘들 것이다. 이제 시스템을 구축함에 있어 이와 같은 어플리케이션 파티션과 데이터 파티션에 주의하여 구축해야 할 것이다. 이것이야 말로 RAC를 효과적으로 사용하는 방법이 될 것이다.생각의 전환이 데이터베이스를 최적화 시킨다. - 8부