데이터이야기

DB 노하우, 데이터직무, 다양한 인터뷰를 만나보세요.

지금 우리에게 필요한 것은 데이터베이스 성능 최적화이다 (4부)

데이터 이야기
작성자
dataonair
작성일
2015-03-08 00:00
조회
5651


지금 우리에게 필요한 것은 데이터베이스 성능 최적화이다 (4부)



디스크 I/O 분산에서 DBA의 역할은 매우 중요하다.


디스크 업체 및 OS 담당자에 의해 파일 시스템가지 최적으로 구성되었다고 가정하자. DBA의 역할을 이해하기 위해서는 최적의 디스크 구성을 위한 기본 원칙을 이해해야 할 것이다.

최적화된 디스크 구성은 하나의 테이블을 엑세스하는 경우 데이터베이스를 구성하는 모든 디스크를 엑세스할 수 있는 확률이 만들어져야 한다. 이를 좀더 구체화하여 데이터베이스의 모든 테이블과 인덱스를 모든 디스크로 분산하여 저장한다면 하나의 테이블을 엑세스하는 순간 모든 디스크를 엑세스할 수 있을 것이다. 디스크 I/O 분산은 확률의 게임이라고 한다. 이는 디스크 구성하는 경우 해당 테이블을 엑세스하여 모든 디스크를 엑세스할 수 있도록 확률을 만들어야 한다는 것이다.

예를 들어, 위의 디스크 그림에서 A 테이블을 /oradata1에만 저장한다면 A 테이블을 엑세스하는 순간 /oradata1을 구성하는 디스크만 작동하게 될 것이다. 결국, 이와 같이 구성한다면 A 테이블을 엑세스하는 순간 모든 디스크가 엑세스될 수 있는 확률은 만들어지지 않게 된다. 하지만, A 테이블을 /oradata1, /oradata2, /oradata3 및 /oradata4에 나누어 저장한다면 이는 모든 디스크를 엑세스할 수 있는 경우의 수를 만들게 되는 것이다. 이와 같이 구성하는 것이 항상 쉽지 만은 않을 것이다.

최적화된 디스크 I/O 분산의 핵심인 특정 테이블의 데이터를 엑세스하는 경우 모든 디스크가 작동하게 하기 위해서는 DBA의 역할인 세그먼트 스크라이핑이 반드시 필요하다.

150309_datastory_01.jpg

위와 같이 오라클의 세그먼트 스트라이핑을 이용한 디스크 구성을 확인해 보자. 위의 예제에서 생성하는 A 테이블은 익스텐트 크기가 10MB 단위라고 가정하자. 여기서 익스텐트는 테이블에 데이터를 저장하기 위해 오라클이 내부적으로 할당하는 공간을 의미한다. 오라클의 데이터 파일을 각각의 파일 시스템에 미리 할당한다면 위와 같이 4개의 데이터 파일이 할당될 것이다.

이와 같이 데이터 파일만 미리 할당해 놓는다면 오라클은 자동으로 세그먼트 스트라이핑을 수행하게 된다. 위의 예제에서 A 테이블을 생성하게 되면 가장 먼저 생성된 데이터 파일인 Test01.dbf 데이터 파일에 첫번째 익스텐트인 0번 익스텐트를 할당하게 된다. 해당 익스텐트의 크기는 앞에서 가정한 것과 같이 10MB이며 OS 담당자의 역할이 수행되었다면 해당 10MB의 익스텐트는 /oradata1 파일 시스템을 구성하고 있는 8개의 디스크로 스트라이핑되어 저장될 것이다.

해당 10MB의 공간에 데이터가 저장된 후 추가적인 공간이 필요하다면 오라클은 Test01.dbf에 새로운 익스텐트를 추가하는 것이 아니라 새로운 데이터 파일인 Test02.dbf 데이터 파일에 새로운 공간을 할당하게 된다. 이는 무엇을 의미하는가 각각의 파일 시스템에 데이터 파일을 생성하기만 하면 오라클은 자동으로 데이터 파일 순으로 공간을 할당하게 되며 이와 같이 구성된다면 위의 예제에서는 4개 이상의 익스텐트가 할당되는 순간 A 테이블은 전체 디스크로 분산된다는 것을 의미한다. 이것이 바로 세그먼트 스트라이핑이다.

결국, 세그먼트 스트라이핑에서 DBA가 수행해야 할 작업은 서로 다른 디스크로 분산될 수 있도록 데이터 파일을 미리 할당해야 한다는 것이다. 이와 같은 작업이 어렵지만은 않을 것이다. 하지만, 위와 같은 단순한 작업 하나만으로 하나의 테이블이 전체 디스크로 분산될 수 있다는 것이 놀랍지 않은가 이와 같이 간단한 작업임에도 불구하고 해당 작업이 선행되지 않는다면 데이터가 저장된 후에는 위와 같이 디스크 구성을 변경하는 것은 매우 어려운 일이다. 그렇기 때문에 최적화된 디스크 I/O 분산을 위해서 DBA의 역할의 중요성을 반드시 인식해야 할 것이다.



세그먼트 스크라이핑를 최대한 이용하자.


세그먼트 스트라이핑을 구현하는 과정에는 많은 응용이 가능하다. 앞에서는 단지 데이터 파일을 미리 분산하여 생성함으로써 오라클에서 자동으로 세그먼트를 분산시키는 과정을 확인해 보았다.

여기에 좀더 고급 수준의 세그먼트 스트라이핑을 확인해 보자. 예를 들어, 어느 회사에 거래내역 테이블이 존재한다고 가정하자. 해당 테이블은 주로 20대 및 30대가 주로 사용하며 그 외 연령의 고객 데이터는 존재하지만 많이 사용되지 않는다고 가정하자. 최적화된 디스크 구성은 하나의 테이블을 엑세스하는 경우 데이터베이스를 구성하는 모든 디스크를 엑세스할 수 있어야 한다고 언급했다. 여기서 하나의 테이블이 아닌 특정 데이터로 집합을 좁혀 보자.

테이블에는 모든 연령의 데이터가 존재하지만 실제로는 20대 및 30대가 주로 사용하게 된다. 해당 거래내역 테이블을 앞서 언급한대로 구성한다면 거래내크에는 20대 및 30대의 데이터가 존재하지 않을 수도 있다. 따라서, 20대 및 30대에 대한 엑세스만 계속 수행된다면 전체 디스크를 엑세스할 수 있는 경우의 수는 만들어지지 않게 될 것이다.

위와 같은 경우 과연 어떻게 해야 하는가 이와 같은 경우에는 파티션 테이블을 이용할 수 있다. 거래내역 테이블을 연령별로 파티션 아키텍쳐를 적용한다면 20대 파티션, 30대 파티션 등 연령별 파티션이 생성될 것이다.

파티션은 일반 테이블과 같은 특성을 가진다. 이 뜻은 각각의 파티션은 세그먼트 스트라이핑을 수행한다는 의미가 된다. 이는 마치 20대 테이블 및 30대 테이블이 각각 존재하는 것과 같다.

그러므로 파티션 테이블을 이용하여 연령별로 데이터가 별도로 저장되고 각각의 파티션은 각각 세그먼트 스트라이핑을 수행하게 되므로 모든 20대 데이터는 모든 디스크에 나뉘어 저장된다. 또한, 30대의 데이터도 모든 디스크에 나뉘어 저장된다.

이와 같이 구성한다면 우리는 많은 경우에 최적의 디스크 I/O 분산을 수행할 수 있을 것이다. 세그먼트 스크라이핑 방법을 보다 효과적으로 사용하기 위해 함께 사용할 수 있는 아키텍쳐는 파티션 테이블이다.



디스크 분산의 잘못된 사실을 버리자.


지난 호에서도 언급했지만 많은 사이트에서 인덱스와 테이블을 서로 다른 디스크에 저장하는 경우가 많다. 이와 같이 구성한다면 어떠한 현상이 발생하는가

■ 인덱스만 엑세스하는 경우 - 전체 디스크를 엑세스할 확률 없음
■ 테이블만 엑세스하는 경우 - 전체 디스크를 엑세스할 확률 없음
■ 인덱스와 테이블을 동시에 엑세스하는 경우 - 전체 디스크를 엑세스할 확률 존재

위와 같이 3가지 엑세스의 경우 중 한가지 만이 전체 디스크를 엑세스할 수 있는 확률이 존재하게 된다. 인덱스와 테이블을 구분하여 저장하지 않았다면 모든 경우에 전체 디스크를 엑세스할 수 있는 확률이 존재하게 될 것이다. 테이블과 인덱스가 많으면 많을수록 인덱스와 테이블을 구분하여 서로 다른 디스크에 저장하는 것은 더욱 어렵게 된다.

이러한 구성은 세그먼트 별로 전체 디스크로 분산하는 것에 비해 엄청난 성능 저하를 발생시키게 된다. 어느 사이트에서 SQL은 최적화하지 않고 중요 테이블만 전체 디스크로 분산되도록 세그먼트 스트라이핑 방법을 적용했을 경우 해당 테이블을 엑세스하는 서비스는 3배 정도가 성능이 향상되었다.

테이블 또는 인덱스 별로 세그먼트 스트라이핑을 이용하여 전체 디스크를 엑세스하게 하는가 아닌가는 이와 같이 3배 이상의 성능 차이를 발생시키게 된다. 이제부터는 최적의 디스크 I/O 분산을 위해 어느 방법을 선택하겠는가

이제 더 이상 인덱스와 테이블의 디스크를 별도로 구성하여야 성능을 보장할 수 있다는 잘못된 사실을 버리길 바란다. 대용량 데이터베이스라면 반드시 세그먼트 스크라이핑을 이용하여 전체 디스크를 엑세스할 수 있는 확률을 만들 수 있는 디스크 구성을 수행해야 한다. 디스크 구성에 대한 잘못된 사실을 버리고 새로운 사실을 수용해야만 대용량 데이터의 시대를 극복할 수 있을 것이다. 다음 호에서는 데이터 연결에 대한 성능 관련 잘못된 사실에 대해 확인해 보자.






출처 : 한국데이터베이스진흥원

제공 : 데이터 전문가 지식포털 DBguide.net