데이터베이스들은 신규 버전이 출시될 때마다 데이터 마이그레이션에 효과적으로 사용할 수 있는 아키텍쳐를 선보였다. 데이터베이스 마이그레이션은 업무에 맞는 최적의 아키텍쳐와 전략을 수립하여 수행해야만 우리가 원하는 성능을 보장 받을 수 있을 것이다. 이와 같은 전략과 아키텍쳐 없이 데이터 마이그레이션을 수행한다면 데이터 마이그레이션은 실패하게 된다.

데이터 마이그레이션을 수행하기 위해서는 많은 방법을 사용할 수 있을 것이다. 다양한 데이터 마이그레이션 방법 중 최적의 방법을 사용하기 위해서는 그에 맞는 데이터베이스 아키텍쳐로 구성되어 있어야 한다. 이와 같이 데이터베이스 아키텍쳐를 중심으로 데이터 마이그레이션을 수행하는 전략이 수립된다면 데이터의 양이 아무리 많더라도 우리는 성공적으로 데이터 마이그레이션을 완료할 수 있을 것이다. 이처럼 대용량 데이터의 최적화된 데이터 마이그레이션을 수행하기 위해서는 최적화된 아키텍쳐와 치밀한 전략이 반드시 필요하다. 그럼에도 불구하고 수 많은 곳에서 아키텍쳐와 전략에 대한 고려 없이 데이터 마이그레이션을 수행하고 있으며 이런 과정에서 작업 시간 지연과 그 외의 많은 문제점을 발생시키는 것이 현실인 것 같다. 이제는 이러한 문제를 더 이상 발생시키지 말아야 할 것이다. 그러기 위해서 대용량 데이터에 대한 최적의 마이그레이션을 수행할 수 있는 아키텍쳐를 확인해 보자.

파티션(Partition) 아키텍쳐를 이용하자.

파티션 아키텍쳐는 오라클에서 지원해 주는 대용량 데이터베이스의 문제를 해결하기 위한 중요한 아키텍쳐 중 하나이다. 많은 사람들이 파티션 아키텍쳐와 데이터 마이그레이션 사이에 무슨 연관 관계가 있는가에 대해 의문을 가질지도 모른다. 하지만 파티션 아키텍쳐는 대용량의 데이터 마이그레이션에서도 효과적으로 이용할 수 있다는 것을 명심하길 바란다. 오히려 대용량 데이터 마이그레이션에서 파티션 아키텍쳐는 반드시 필요한 아키텍쳐이다.

파티션 아키텍쳐는 테이블을 파티션 테이블로 구성하는 것을 의미한다. 오라클에서 지원해 주는 파티션 테이블에는 범위(Range) 파티션, 해쉬(Hash) 파티션 및 리스트(List) 파티션이 존재한다. 각각의 파티션 아키텍쳐는 아래와 같은 특징을 가진다.

n 범위 파티션 ？ 특정 컬럼을 기준으로 범위로 데이터를 분리하여 별도의 공간에 저장하는 파티션 아키텍쳐이다. 별도의 공간에 저장되는 각각의 파티션들은 하나의 테이블과 같은 성격을 가지게 된다.

n 해쉬 파티션 ？ 특정 컬럼을 기준으로 해쉬 함수를 적용하여 동일한 값이 추출되는 데이터를 동일한 공간에 저장하는 파티션 아키텍쳐이다. 해쉬 파티션 또한 구분된 공간에 저장되는 각각의 파티션들은 하나의 테이블과 같은 성격을 가지게 된다.

n 리스트 파티션 ？ 특정 컬럼을 기준으로 동일한 값을 가지는 데이터를 분리하여 별동의 공간에 저장하는 파티션 아키텍쳐이다. 이 또한 다른 파티션과 동일하게 별도로 구분된 공간에 저장되는 각각의 파티션들은 하나의 테이블과 같은 성격을 가지게 된다.

이와 같은 파티션 아키텍쳐를 어떻게 데이터 마이그레이션 아키텍쳐로 사용할 수 있는 가를 확인해 보자.

하나의 대용량 테이블에 대해 데이터 마이그레이션을 수행하고자 한다면 해당 테이블을 처음부터 마지막까지 엑세스해야 할 경우가 발생하게 될 것이다. 이와 같은 경우 데이터 마이그레이션은 두 가지의 문제점이 발생한다.

첫 번째로 전체 데이터를 마이그레이션 하는 경우 과다한 데이터 엑세스에 의한 I/O로 증가로 성능 저하가 발생할 수 있다. 예를 들어, 100GB의 테이블 데이터에 데이터 마이그레이션을 수행한다면 이는 데이터 마이그레이션이 문제가 아니라 100GB의 데이터를 엑세스하는 것이 더 큰 문제일 것이다. 100GB의 데이터를 마이그레이션하기 위해서는 100GB의 데이터를 반드시 엑세스해야 한다. 과연, 100GB의 데이터를 어떻게 엑세스할 것인가

이러한 문제를 해결하기 위해 파티션 아키텍쳐를 이용할 수 있다. 100GB의 테이블에 대해 10개의 파티션으로 테이블을 구성하였다고 가정하자. 그렇다면, 100GB의 테이블은 대략 10GB 크기의 10개의 파티션으로 구성될 것이다. 앞서 각각의 파티션은 테이블과 유사한 성격을 가진다고 언급했다. 따라서, 10개의 파티션으로 테이블을 구성한다면 한번에 10개의 파티션을 엑세스할 필요는 없으며 필요한 파티션만을 엑세스할 수 있게 된다. 10GB 크기의 데이터를 10번 엑세스하면 우리가 원하는 100GB를 모두 엑세스할 수 있을 것이다. 여기서 100GB의 데이터를 한번에 엑세스하는 것과 10GB씩 분리하여 10번을 엑세스하는 것에 어떤 차이가 있는지에 대해 의아해 할 수 있을 것이다.

테이블을 10GB씩으로 분리된 10개의 테이블을 엑세스하는 것은 100GB로 구성된 테이블을 한번에 엑세스하는 것 보다 손쉽게 작업을 수행할 수 있다. 100GB로 구성된 테이블은 순서대로 한번씩 엑세스해야 하지만 테이블이 파티션 아키텍쳐를 적용하여 10GB 크기로 10개로 구성되어 있다면 한번에 여러 파티션을 동시에 엑세스할 수 도 있을 것이다. 이와 같은 이유에서 대용량 테이블에 대해서는 파티션으로 테이블을 구성하여 데이터 마이그레이션을 수행하는 것이 성능적인 면에서 유리할 것이다.

두 번째로 100GB의 데이터 중 20GB의 데이터만을 엑세스하여 데이터 마이그레이션을 수행한다고 가정하자. 그렇다면 어떻게 데이터를 마이그레이션해야 하는가 일반 테이블로 구성되어 있다면 100GB의 데이터를 모두 엑세스한 후 80GB의 데이터를 버리고 나머지 20GB의 데이터를 취해서 데이터 마이그레이션을 수행해야 할 것이다. 또는 인덱스를 이용하여 20GB의 데이터를 엑세스해야 할 것이다. 여기서 엑세스하고자 하는 데이터는 전체 데이터의 1/5에 해당된다. 이와 같은 경우에는 인덱스를 이용하면 랜덤 엑세스의 증가로 성능은 더욱 저하된다. 그렇다고 테이블을 전체 스캔하기에는 100GB라는 크기가 부담되지 않을 수 없을 것이다. 결국, 100GB의 테이블에서 20GB의 데이터 만을 엑세스하여 데이터 마이그레이션을 수행하고자 한다면 인덱스를 이용하는 것도 어렵고 테이블을 전체 스캔하는 방식도 어렵다.

위와 같은 경우에 대해 파티션 아키텍쳐를 적용했다고 가정하자. 이 경우에 테이블은 엑세스하고자 하는 데이터를 기준으로 반드시 파티션을 분리해야 한다. 100GB의 테이블을 10GB 크기로 10개의 파티션으로 구성했다고 가정하자. 해당 파티션은 엑세스하는 컬럼을 기준으로 구성한 것이라고 가정했으므로 20GB의 데이터를 엑세스한다면 2개의 파티션만을 엑세스하면 된다. 따라서, 10개의 파티션 중 2개의 파티션을 엑세스한다면 우리가 원하는 데이터를 모두 추출할 수 있으므로 해당 데이터로 데이터 마이그레이션을 수행할 수 있을 것이다. 이와 같은 경우에 인덱스를 엑세스하는 것이 아니라 필요한 2개의 파티션만을 전체 스탠하면 되므로 100GB의 데이터 중 20GB의 데이터만을 엑세스하게 된다. 이와 같이 수행한다면 우리는 20GB의 데이터를 손쉽게 성능을 보장 받으면서 데이터 마이그레이션을 수행할 수 있게 된다.

결국, 테이블의 전체 데이터를 마이그레이션 하거나 또는 테이블의 일부 데이터를 마이그레이션 하는 경우 대용량 테이블에서는 파티션으로 구성하여 파티션 단위로 작업을 수행한다면 파티션 아키텍쳐 하나만으로도 데이터 엑세스에 대해 10배 이상의 성능 향상을 기대할 수 있을 것이다. 이제 데이터 마이그레이션과 파티션 아키텍쳐를 별개로 생각하지 말고 파티션 아키텍쳐를 적용한 최적의 데이터 마이그레이션 아키텍쳐를 고려해야 할 것이다.