분산 파티션 뷰(Distributed Partitioned Views) 사용 하기 | MS-SQL

확장성을 기대하던 사용자들에게 SQL Server 2000의 분산 파티션 뷰(DPVs) 기능이 희소식으로 다가왔다. 이 기능은 데이터를 여러 부분으로 나눈 다음 여러 개의 서버와 데이터베이스에 분산시키지만 실제로는 하나의 데이터 베이스인 것처럼 보이게 한다. SQL Server 7.0에서는 Select 문에 대해서만 이와 같은 기능을 제공했지만 SQL Server 2000에서는 Select를 비롯하여 Insert, Update 시에도 사용할 수 있게 되었다.

이와 같은 형태의 확장성은 저렴한 여러 개의 컴퓨터를 사용하는 수평적 확장으로 16개의 프로세서가 장착된 고가의 컴퓨터를 사용하는 수직적 확장과는 상대적인 개념이다. Scaling Out(수평적 확장) 기능 덕분으로 마이크로소프트는 가장 최근의 벤치 마크 테스트에서 트랜잭션 당 비용 측면에서 오라클을 능가하는 기록을 달성하였다. Scaling Up(수직적 확장)의 단점은 프로세서의 구입에 많은 비용이 소요될 뿐 아니라 프로세서를 추가할수록 성능이 그에 비례하여 선형적으로 향상되지 못한다는 것이다. 결과적으로 프로세서 증가에 따른 성능 변화를 표시하는 확장 곡선이 점점 수평선에 가까와 지면서 나중에는 새로운 프로세서를 추가 해도 성능 향상은 극히 미미하게 나타나게 된다. 가장 좋은 것은 위의 두 가지 방법을 모두 사용하는 것이다.

이 기술의 핵심은 데이터를 여러 개의 노드에 저장한 다음 Linked Server를 사용하여 각각의 노드에게 다른 노드의 정보를 알려주는 데 있다. DPVs는 쿼리 옵티마이저(Query Optimizer)가 지능적으로 노드를 선택할 수 있도록 동적 파티션 제거(Dynamic Partition Elimination) 기능을 사용한다. 이를 사용하면 하나의 서버만을 필요로 하는 쿼리는 그 서버만을 사용하도록 하며 사용자가 찾고자 하는 데이터를 가지고 있지 않은 서버는 쿼리 대상에서 제외된다.

파티션 뷰를 만드는 첫번 째 단계는 데이터를 분류하는 기준이 되는 키(Key)를 찾는 일이다. 예를 들면, CustomerID가 고객(customers) 테이블에서 데이터를 분류하기에 가장 좋은 컬럼이라고 한다면, A 서버에는 1-19,999 사이의 고객을 저장하고, B 서버에는 20,000에서 40,000 사이의 고객을 저장할 수 있다. 요점은 데이터를 분류하기 전에 이와 같이 미리 계획을 세워야 한다는 것이다. 그 다음에는 아래와 같이 파티션 테이블의 CustomerID에 CHECK 조건을 설정한다.

A 서버:
CustomerID INTEGER PRIMARY KEY
CHECK (CustomerID BETWEEN 1 AND 19999),

B 서버:
CustomerID INTEGER PRIMARY KEY
CHECK (CustomerID BETWEEN 20000 AND 40000),

만약 전체 데이터가 이미 A 서버에 존재하고 있다면 CHECK 조건에 따라 데이터를 B 서버로 옮기기 위해서는 DTS 패키지를 만들어야 한다. 예를 들면, 위의 테이블의 경우에는 20,000~40,000에 해당하는 레코드를 B 서버로 옮겨야 한다.
다음 단계는 각 서버에 다른 노드의 정보를 알려주는 것이다. A 서버는 B 서버에 대한 Linked Server를 가지게 되고 B 서버도 A 서버에 대한 Linked Server를 가지게 된다. 만약 이들 서버의 Collation이 일치한다면Linked Server로부터 최고의 성능을 이끌어 내기 위해서 Collation Compatible 체크 버튼을 체크해야 한다.

마지막 단계는 실제로 DPVs를 만드는 것이다. 각 서버는 자신의 데이터와 다른 서버의 데이터를 반영하는 뷰(View)를 만들어야 한다. 이는 조인된 테이블과도 원활하게 동작한다. UNION ALL 절을 사용하여 DPVs를 만드는 구문은 아래와 같다.

A 서버:
CREATE VIEW Customers AS
SELECT * FROM DatabaseName.TableOwner.Customers_a
UNION ALL
SELECT * FROM ServerB. DatabaseName.TableOwner.Customers_b

B 서버:
CREATE VIEW Customers AS
SELECT * FROM DatabaseName.TableOwner.Customers_b
UNION ALL
SELECT * FROM ServerA. DatabaseName.TableOwner.Customers_a

DPVs를 사용하여 조회 할 때에는 쿼리 옵티마이저가 각 노드의 CHECK 조건을 검사하여 그 테이블을 검색할 필요가 있는지를 결정한다. 만약 조건이 맞는다면 검색을 하고 그렇지 않으면 무시한다. Insert, Update, Delete의 경우에도 같은 방법으로 동작한다.

이미 예상했겠지만 가장 중요한 것은 스키마(Schema) 변경 문제이다. 이제부터는 뷰 뿐 아니라 모든 서버의 스키마도 관리해야 한다. 뷰를 변경하게 되면 시스템상의 각 노드에 영향을 끼치게 된다. DPVs는 SQL Server가 보다 확장된 노드로 가기 위한 시발점이고 할 수 있다. 쿼리를 실행하면 쿼리가 적절한 노드로 보내져서 처리된 다음 결과는 처음 명령을 낸 곳에서 취합 된다. 이와 같은 방법으로 모든 서버가 최적화된다.