데이터이야기
DB 노하우, 데이터직무, 다양한 인터뷰를 만나보세요.
생각의 전환이 데이터베이스를 최적화 시킨다. - 3부 많은 곳에서 성능 최적화를 수행하면서 SQL 튜닝만을 수행하려고 하는 경우가 많다. 물론, SQL 튜닝을 통해 성능을 최적화할 수 있는 것은 분명하다. 하지만, 우리가 데이터를 관리하는 데이터베이스의 물리적인 구조를 최적화한다면 SQL의 최적화 없이도 성능을 향상시킬 수 있다. 결국, 성능을 최적화하기 위해서는 SQL 튜닝 뿐만 아니라 데이터의 물리적인 구성 또한 최적화시켜야 할 것이다. 물리적 구성이 최적화되어 있지 않은 경우에 SQL 튜닝으로 10배의 성능이 향상된다고 가정하자. 이와 같다면 물리적 구성을 최적화한 후 SQL을 튜닝한다면 이는 15배 이상의 성능 향상을 기대할 수 있을 것이다. 반드시 15배의 성능 향상은 아니지만 물리적 구성의 최적화 만으로도 우리는 성능 향상을 기대할 수 있게 된다. ■데이터 저장 아키텍쳐- 클러스터 팩터(Cluster Factor) 아키텍쳐 위와 같은 물리적 구성 요소를 통해 우리는 성능을 향상시킬 수 있을 것이다. 우리가 시스템을 구축할 경우 위의 항목들을 항상 고려하는가 위와 같은 항목들은 시스템이 서비스를 개시한 후에는 적용하기 힘들게 된다. 이는 물리적인 구성요소이기 때문이다. 이제부터 각각의 항목에 대해 프로젝트 중에 어떻게 적용해야 하는지 확인해 보자. 여기서 이야기하는 데이터 저장 아키텍쳐는 클러스터 팩터를 의미한다. 그렇다면 클러스터 팩터는 무엇을 의미하는가 클러스터 팩터를 이해하기 위해서는 테이블에서 원하는 데이터를 엑세스하는 유형과 저장되는 데이터에 대한 분석이 필요하다. 생각의 전환이 데이터베이스를 최적화 시킨다. - 3부
많은 프로젝트에서 성능을 향상시키기 위해 SQL 튜닝에 전념하는 사이트들이 많이 있을 것이다. SQL 튜닝을 통해 많은 성능 향상을 기대할 수 있는 것은 사실이다. 예전에는 성능 저하가 발생하는 경우 SQL 튜닝 보다도 해당 시스템의 CPU, 디스크 등의 자원을 증설하는 부분에 초점을 맞추었다. 이와 같이 최적화하는 것보다 SQL을 튜닝하여 성능을 최적화하고자 하는 것은 매우 고무적인 현상임에는 틀림 없다. 그 만큼 관리자들의 생각이 IT 선진화로 가는 것은 아닐까
하지만, 아직도 SQL 튜닝의 성능을 배가 시킬 수 있는 물리적 구성에는 많은 허점이 존재한다. 이제 SQL 튜닝의 효과를 배가 시킬 수 있는 물리적 구성에 대해 자세히 확인해 보자.
성능을 향상시키는 물리적 구성을 이해해라.
필자가 어느 사이트를 지원했을 때의 일이다. 해당 사이트에서는 SQL 튜닝보다는 물리적 구성의 최적화에 초점을 두었었다. 디스크 I/O 분산과 파티션 테이블만을 이용하여 SQL 튜닝을 수행하지 않고 4배의 성능 향상을 확인했었다. 이 얼마나 놀라운 사실인가
여기에 SQL 튜닝까지 수행한다면 10배의 성능이 향상될 SQL의 성능은 그 이상의 성능 향상을 기대할 수 있을 것이다. 이는 절대 놀라운 사실이 아니다. 이와 같은 이유에서라도 우리는 SQL 튜닝과 물리적 구성의 최적화를 병행해야만 할 것이다.
이제는 물리적 구성의 최적화를 간과해서는 안될 것이다. 물리적 구성은 한번 구성되고 나면 추후에는 변경되기 힘든것이 물리적 구성이다. SQL은 하나 하나 최적화를 수행하여 적용하면 될 것이다. 하지만, 물리적 구성은 한번 구성되면 변경하기 위해서는 많은 어려움을 경험해야 할 것이다. 이와 같은 물리적 구성을 이제는 소홀히 여기지 말고 프로젝트 때부터 많은 고려를 해야 할 것이다.
성능을 고려한 최적의 물리적 구성에 대한 정답은 없다. 하지만, 성능을 고려하여 물리적 구성에 대해 많은 고민을 한다면 우리는 성능을 보장할 수 있는 물리적 구성을 구현할 수 있을 것이다. 결국, 항상 생각하고 고민하는 습관이야 말로 해당 시스템을 최적의 시스템으로 구현할 수 있는 최선의 방법일 것이다.
물리적 구성의 최적화는 여러 가지 요소에 의해 구성될 것이다. 그렇다면 어떠한 물리적 구성을 의에 의해 성능은 향상되거나 저하될 수 있는가 아래와 같은 물리적 구성에 의해 우리는 성능 향상을 기대할 수 있을 것이다.
■ 테이블 아키텍쳐- 파티션 테이블, IOT 테이블
■ 인덱스 아키텍쳐- 로컬(LOCAL) 인덱스, 프리픽스(PREFIX) 인덱스
■ 엑세스 아키텍쳐- 병렬 프로세싱(PARALLEL PROCESSING) 아키텍쳐
데이터 저장 아키텍쳐를 고려하자.
예를 들어 보자. 어느 카드사에 거래내역 테이블이 존재한다고 가정하자. 해당 카드사의 카드에 대한 거래가 발생하면 해당 테이블에 거래내역 데이터가 저장된다고 가정하자. 그렇다면 해당 테이블에는 어떻게 데이터가 저장되겠는가 테이블의 데이터는 삭제되는 데이터가 없다면 저장되는 순서대로 데이터가 저장될 것이다. 그렇다면 거래일자에 의해 데이터가 발생하고 저장되므로 해당 테이블에는 거래일자 순으로 데이터가 저장될 것이다. 이는 무엇을 의미하게 되는가
거래내역 테이블의 데이터를 저장하는 블록을 확인해 본다면 하나의 블록에는 동일한 거래일자가 저장된다는 의미일 것이다. 데이터를 저장하는 하나의 블록을 확인해 본다면 해당 블록에 거래일자 기준으로 2008년 4월 30일 데이터가 존재한다면 해당 블록에는 거의 대부분 데이터가 2008년 4월 30일 데이터가 저장되어 있을 것이다. 물론, 해당 블록이 2008년 4월 30일 데이터를 저장하는 처음 블록이라면 2008년 4월 29일 데이터가 같이 저장되어 있을 수도 있다.
여기서 중요한 것은 대부분의 동일한 일자의 데이터는 동일한 블록에 저장이 된다는 것이다.
이는 무엇을 의미하는가 하나의 블록에는 10건의 데이터가 저장된다고 가정하자. 그리고 하루 데이터는 1,000건의 데이터가 발생한다고 가정하자. 그렇다면 해당 1,000건의 데이터는 몇 개의 블록에 저장되어 있겠는가 1,000건의 데이터는 100개의 블록에 저장될 것이다. 이와 같기 때문에 해당 일자의 데이터를 모두 조회한다면 우리는 100개의 블록만 엑세스하여 모든 데이터를 추출할 수 있게 된다.
그렇다면 우리는 불필요하게 엑세스한 블록은 존재하지 않게 되며 또한 하나의 블록에서 대부분의 데이터를 결과로 추출하게 되므로 매우 효율적이라고 할 수 있을 것이다. 그렇기 때문에 우리는 거래내역 테이블은 거래일자 값에 의해 클러스터 팩터가 양호하다고 하게 된다.
그렇다면 해당 테이블에서 거래일자 컬럼이 아닌 다른 컬럼에 대해 확인해 보자. 카드 회사의 가장 기본이 되는 카드번호 컬럼은 어떻게 되는가 거래내역 테이블은 테이블이므로 저장되는 순서에 의해 데이터가 저장될 것이다.
그리고 해당 거래내역 테이블에서 우리는 많은 경우에 카드번호 컬럼의 값으로 데이터를 조회하게 된다. 그렇다면 우리가 ‘111’번 카드번호에 대해 거래내역 데이터를 조회한다고 가정하자. 해당 카드번호에 의해 생성된 거래내역 데이터는 100건이라고 가정하자.
그렇다면 해당 데이터를 엑세스하기 위해 얼마나 많은 블록을 엑세스해야 할 것인가 거래일자는 동일한 데이터에 대해 동일한 블록에 함께 저장될 확률이 매우 높았다. 그 이유는 거래일자 값에 의해 순차적으로 데이터가 저장되기 때문이다.
그렇다면 카드번호는 어떠한가 해당 고객이 하루에 2번씩 사용하여 100번을 사용했다 하여도 각 데이터는 동일한 블록에 저장될 확률은 매우 낮게 된다. 이는 카드를 바로 2번 사용했다고 동일 블록에 저장되기 힘들 것이다. 그 이유는 전국에서 많은 사람들이 동시에 카드를 이용하게 되며 그렇기 때문에 해당 데이터들은 카드번호에 의해서는 동일한 블록에 저장되기 매우 힘들게 된다.
이와 같은 상황에서 해당 카드번호에 대해 조회를 해야 한다면 테이블에서 거의 100개의 블록을 엑세스하게 된다. 결국, 각 블록에 내가 우너하는 데이터는 한건 씩 저장되어 있는 현상이기 때문에 거래내역 테이블에 대해 카드번호 컬럼에 대해서는 클러스터 팩터가 매우 좋지 않다고 이야기 하게 된다.
결국, 내가 조회하는 데이터의 클러스터 팩터가 매우 양호하다면 적은 블록을 엑세스하게 되므로 성능은 향상될 것이다. 내가 조회하는 데이터의 클러스터 팩터가 매우 불량하다면 많은 블록을 엑세스해야 하므로 디스크 I/O의 증가로 성능은 저하될 것이다. 따라서, 우리가 추출하고자 하는 데이터의 클러스터 팩터는 성능에 있어 매우 중요한 역할을 수행하게 된다.