DATOR


인덱스 전략 매트릭스 (Index Strategy Matrix) - 1 SQL


 [개요]
 
우리는 Online Transation성 업무 처리에 성능을 보장하기 위해 데이터베이스에 '인덱스'라는 오브젝트를 생성한다. 인덱스에 대한 정의 및 용도는 이미 보편적으로 알고 있다고 가정하기 때문에 해당 내용에서는 제외하겠다. 
이러한 인덱스는 대량의 데이터가 존재하는 테이블에서 소량의 데이터를 검색할 때는 매우 유용하지만, 데이터에 대한 입력 및 수정에 있어서는 동일한 데이터를 다른 곳에 유지해야 한다는 단점이 있다. 그렇기 때문에 가급적 불필요한 인덱스는 제거하고, 최소한의 인덱스로 많은 SQL의 성능을 만족시킬려고 한다. 우리는 이러한 인덱스에 대해 최적화 전략을 세우는 것을 'INDEX OPTIMIZATION'이라고 부르는데 이는 단일 테이블과 해당 테이블과 근접한 테이블들에 대해서 접근한다는 관점만을 가지고 있기 때문에 작업에 대한 우선순위 및 작업 결과에 대한 리포팅이 어렵다는 약점을 가지고 있다.
인덱스 전략 매트릭스(Index Strategy Matirx)는 우리가 대상으로 하는 데이터베이스에 존재하는 테이블들에 대해 중요도를 산정하고, 어떻게 우선 순위를 정할지에 관한 내용이다. 이를 기준으로 테이블에 대한 인덱스를 최적화하는 순서를 정하는 프로세스를 가져가게 된다. 


 [전략적 근거 및 의미]
 
데이터베이스에서는 성능을 측정할 수 있는 기준이 상당히 많이 존재한다. 이 자료를 작성하기 위해 수집된 측정지표로는 아래와 같다.

 - 테이블에 접근하는 SQL의 수
 - 업무 카테고리
 - 중복된 Access Pattern을 제거한 실제 Access pattern(RAP, Real Access Pattern 이라고 부름)
 - 테이블 유형에 대한 분류
 - SQL의 성능정보 : 총 수행시간, 수행횟수, Elaped Time, Cpu Time, Disk 및 Memory I/O 수, Read 된 로우와 출력된 로우의 수
 - 테이블당 인덱스 수

물론 이 말고도 더 많은 요소들을 서로 다른 기준으로 바라보기 때문에 어떤 것이 절대적으로 중요하다고 단정지을 수 없다. 하지만중요한 것은 테이블에 대한 우선 순위를 정하기 위해 각종 측정지표를 통해 이를 산정할 수 있어야 한다는 것이다. 

각 측정지표에 대한 중요성은 아래와 같다.

 1) SQL의 수
  - 해당 테이블에 대한 업무의 중요성을 표현한다. 이를 상대적으로 표현하면 해당 테이블의 접근하는 SQL의 수가 많을수록 업무에서의 중요도가 높을 수 있으며, SQL의 수가 적으면 업무에서의 중요도가 낮을 수 있다.

 2) 업무 카테고리
  - 해당 업무 영역별로 업무의 중요성 및 복잡도를 식별할 할 수 있다. 테이블이 많고 적음에 따라 업무의 중요성을 산정할 수 없지만 업무 카테고리 별로 중요성 및 복잡성을 식별할 수 있다.

 3) 중복된 Access Pattern을 제거한 실제 Access pattern
  - RAP라는 것을 간략하게 설명하면 많은 SQL중에서 SQL의 성능을 결정짓는 Access Pattern에 대해 동일한 Pattern을 하나의 Access Pattern으로 인식하는 것이다. RAP의 구성요소로는 해당 컬럼에 대한 Access 조건만이 아니라, 하나의 RAP에 몇개의 SQL과 관련되어 있는지 숫자도 관리하기 때문에 두개의 변수를 제공한다. 한 테이블의 RAP에 존재하는 SQL의 전체 합은 테이블을 Access하는 SQL의 수와 동일하다. SQL의 수는 많지만 RAP가 상대적으로 적다는 것은 비교적 Access하는 Pattern이 동일하다는 것으로 인덱스 최적화 작업을 하는데 매우 중요한 요소이다. 약점은 이 하나의 수치로만 접근하기 어렵다는 단점이 있다.

 4) 테이블 유형에 대한 분류
  - 테이블의 유형에 따른 분류는 테이블에 대한 성격을 분류하고, 이에 따라 어떠한 데이터 조작 패턴이 존재하는지를 인식하는 것이다. 하지만 이는 데이터 모델링 단계에서 설정하지 않으면 실제 작업상의 많은 시간을 소요하고(불필요하다는 것은 아니다), 실제로 구분하는데 어려움이 존재할 수 있기 때문에 자류하는 작업을 하기 보다는 인덱스를 디자인하는 작업자가 해당 테이블에 대해서 인지하고 있어야 하는 부분이다.
   이를 분류 해보면 (엔코아 장희식 상무 자료 참조)
    (1) 기준 : 업무의 중심에 있으면서 비즈니스 흐름에 따라 서서히 증가하는 성향을 가지고 있음.
    (2) 업무 : 비즈니스 흐름에 따라 업무의 내역이 쌓이는 테이블.
    (3) 부가 : 기준과 업무에서의 하위 테이블, 데이터가 많이 발생하기는 하지만 비교적 간단한 Access Pattern을 가지고 있음
    (4) 참조 : 자주 참조되는 성격을 가지고 있으며, 특별하지 않은 이상(업무 요건 추가시 증가) 증가할 일이 적다.

 5) SQL의 성능 정보
  - SQL의 성능 정보는 SQL의 성능을 평가하는 가장 중요한 요소이다. 그만큼 다양한 측정지표를 가지고 있고, 각기 서로 다른 요소에 대한 성능을 측정하고 있다. 이러한 측정지표는 다양한 요소를 평가를 하고 있지만 주된 이유는 SQL에 대한 빠른 처리를 보장하면서 최대한의 적은 리소스를 사용하는 것이 공통된 방향이다. SQL의 성능 정보는 단일적인 SQL을 평가할 때도 유용하지만 데이터베이스의 전체적인 성능을 평가할 때도 유용하다. 물론 데이터베이스 엔진이 존재하는 서버와 디스크의 성능평가 만으로 데이터베이스를 평가할 수 있지만, 어떠한 부분이 우리에게 문제라는 것을 밝혀주지는 못한다. 단지 데이터베이스의 특정 시점만의 성능 상태를 평가할 뿐이다. 어떠한 악성 요소가 데이터베이스의 성능을 떨어뜨리고, 우리가 어떻게 접근해야 할지는 밝혀주지 못하기 때문에 측정지표로 쓰기에는 무리가 있다.
  여기서 사용하는데 중요한 SQL의 성능 정보는 '단일 SQL에 대한 수행횟수'이다. 이는 절대적이지는 않지만 SQL 자체의 중요성을 의미할 수 있다. '많은 수행 빈도를 가지고 있는 SQL은 해당 데이터베이스 성능에 많은 영향을 미친다'라는 것은 통념적으로 인지될 수 있는 내용이다.

 6) 테이블당 인덱스 수
 - 테이블의 인덱스가 많다는 것은 Access Pattern이 많다는 것과 테이블이 가지고 있는 업무의 복잡성을 의미하기도 한다. 절대적인 인덱스 갯수만으로 해당 테이블에 대한 어떠한 평가도 이루어지기 어렵지만, 다른 측정지표와 연계될 때 우선순위를 가지고 접근할 수 있게 해준다. 데이터에 대한 조작이 많은 테이블이 인덱스가 많이 있다면 이는 우선순위가 높아질 수 있고, 많은 인덱스를 가지고 있지만 실제 데이터 조작이 별로 없으면서, 많은 조회 쿼리에서 사용된다면 이는 우선순위를 뒤로 생각해도 된다.


 물론 이보다 다양하게 데이터베이스 성능을 측정하는 지표가 존재하지만, 인덱스 전략 매트릭스를 작성하는데 사용된 측정지표는 위에 설명한 내용을 근거로 작성이 되었다. 

 인덱스 전략 매트릭스의 목적은 아래와 같다.
  - 작업에 대한 우선순위를 제공하고, 이에 대한 근거를 제공
  - 튜닝 작업자 및 인덱스 설계자에게 단계별로 접근하고 우선순위를 제공함
  - 각 Segment별 접근 방법에 대한 Index Design 전략 제공
  - 현재와 미래의 데이터베이스 상황을 평가하고 비교함


인덱스 전략 메트릭스에서 두 개의 측정지표를 기준으로 한다. 하나는 "SQL의 수 / RAP의 수"와 "테이블 당 인덱스 개수" 이다. 

 "SQL의 수 / RAP의 수" 와의 관련성
테이블의 Access하는 SQL이 많다는 것은 해당 업무에서 중요한 테이블일 가능성이 높다고 하였다. 또한 존재하는 RAP의 수가 많다는 것은 다양한 Access Pattern을 가지고 있다는 것이고, 그만큼 이를 커버할 수 있는 인덱스가 더 필요할 수 있다는 것이다. 이를 "SQL의 수 / RAP의 수"로 나누는 것은 SQL이 가지고 있는 Access Pattern이 어느 정도인가를 측정하게 해주는 것이다. 이와 관련된 두가지 가정은 아래와 같다.
 - RAP 하나가 많은 량의 SQL과 관계되어 있는 경우, 비교적 적은 Access Pattern을 가지고 있다.
 - RAP 하나가 작은 량의 SQL과 관계되어 있는 경우, 비교적 많은 Access Pattern을 가지고 있다.
 RAP가 하나의 Access Pattern으로 인식한다고 가정한다면, 비교적 적은 Access Pattern을 접근하는 것이 작업의 성과가 빠르게 나온다는 가정이다.

  "인덱스 개수"와의 관련성
인덱스의 개수가 많다는 것은 해당 테이블의 다양한 Access Pattern이 존재할 수 있다는 것과 비효율적인 인덱스 디자인이 되어 있을 수 있다는 가정에 기반한다. 이는 많은 인덱스가 존재하지만 이 안에 인덱스를 효율적으로 조정할 수 있고, 적은 인덱스가 존재할 경우 Access Pattern이 적거나 최적화 되었을 것을 가정으로 한다.
 
 [테크닉 적용 프로세스]
 
 1. 업무 카테고리별 우선 순위를 선정한다.
  앞선 내용에도 업무 카테고리에 대하여 설명하였지만, 업무 카테고리는 해당 데이터베이스에 존재하는 업무에 대하여 분류하고 중요성을 평가하여 중요한 업무가 무엇인지를 평가할 수 있는 기초를 제공한다. 가장 중요한 업무는 해당 데이터베이스 내에서 다른 업무영역과 비교하여 상대적으로 많은 데이터를 발생시킬 확률이 높으며, 성능에 대한 최적화를 요구하는 우선순위와도 맞아 떨어지기 때문이다. 작업 방법은 테이블들을 업무 영역별로 그룹핑하고 이를 간략하게 설명할 수 있는 자료와 우순순위에 대하여 평가한다. 그리고 이 업무 영역이 왜 중요한지도 함께 작성한다.

 2. 테이블의 SQL 수와 RAP를 수집한다.
  해당 데이터베이스의 정보를 주기적으로 수집하여, 존재하는 SQL에 대한 수와 이 SQL에 대한 RAP를 수집한다. SQL의 경우 많은 테이블을 포함하고 있을 수 있기 때문에 여러개의 테이블과 관계되지만 테이블에 대한 SQL의 수는 중복되어서 숫자를 작성한다. 그렇기 때문에 전체 SQL보다 테이블과 관계되는 SQL의 합은 전체 SQL의 합보다 크다. 또한 RAP 역시 테이블별로 작성을 해야 하기 때문에 SQL 전체의 합과는 무관해진다. 단 RAP의 합은 테이블당 엑세스하는 SQL의 합보다는 같거나 작을수밖에 없다. 가장 나쁜 상황은 테이블별 SQL의 합이 절대적으로 크고 RAP의 합과 차이가 없거나 미비할때 이다. 

 3. 테이블의 인덱스 개수를 수집한다.
  테이블당 인덱스가 몇 개씩 존재하는지 수집한다. 인덱스 전략 매트릭스 이후에는 실제 주 작업인 인덱스 최적화 작업이 이루어지기 때문에 실제로 어느 정도의 성과가 있었는지 보여줘야 하기 때문이다. 

 4. 인덱스 전략 매트릭스 작성

인덱스전략메트릭스1.png

 < 그림. 인덱스 전략 매트릭스 >

 

  인덱스 전략 매트릭스는 "SQL의 숫자/RAP의 숫자" 세로축과 "테이블당 인덱스 개수"의 가로축으로 구성된다. 하지만 실제로 표현해야 할 것은 가로축과 세로축만으로 이루어진 2차원 형태보다 2가지에서 3가지 정도의 요소가 더 표현이 되어야 한다. 하나는 테이블에 대한 유형이다. 작업의 우선순위를 정한다는 것은 한정된 자원안에서 최대한의 효과를 내기 위해 중요한 곳에 집중하고, 상대적으로 덜 중요한 곳에는 자원의 소비를 막겠다는 것이다. 이를 위해서는 단일적인 테이블에 접근 할 때 테이블에 대한 성격을 분류하는 것이 좋다(어디까지나 권고 사항임). 다른 하나는 업무 카테고리에 대한 구분인데 이는 서로 다른 성격의 업무 카테고리이기 때문에 서로 다른 인덱스 전략 매트릭스에 작성하는 것이 좋다. 동일한 매트릭스에 동시에 표현하게 되면, 너무 많은 테이블이 하나의 점으로 표현이 되기 때문에 복잡하고, 주 작업자인 튜닝 작업자 및 인덱스 설계자는 업무에 대한 구분이 없이 접근할 수 있기 때문이다.
  
 5. 우선순위별 접근
  해당 매트릭스를 4분위로 작성하여 분류하고 우선순위별 접근은 상대적으로 효과를 빨리볼 수 있는 면부터 접근하게 된다. 접근에 대한 우선순위는 "RAP가 많은 SQL과 관계되며, 인덱스 개수가 많은 상태"이다. 다수의 RAP가 하나의 인덱스와 매핑된다는 것을 전제하는 것으로 인덱스에 대한 수를 줄일 수 있는 확률이 높기 때문에 절대적인 효과를 얻을 가능성이 높다. 이를 통해 불필요한 인덱스를 줄이는 것이다. (물론 SQL의 수와 RAP의 수, 인덱스 개수 에 대한 절대적인 수치 표현이 안되기 때문에 이는 뒤에 [약점 및 한계]에서 설명할 것이다)
  두 번째 우선순위는 "RAP가 적은 SQL과 관계되며, 인덱스 개수가 많은 상태" 이다. 이는 RAP는 SQL과 대비하여 서로 다른 SQL패턴을 보이고, 인덱스 개수도 많기 때문에 접근이 앞선 면보다 어렵게 된다. 단 RAP별로 인덱스를 작성하는 것은 아니기 때문에 비관적이지는 않다.
  세 번째 우선순위는 "RAP가 적은 SQL과 관계되며, 인덱스 개수가 적은 상태"로써, RAP의 숫자가 적고, 인덱스는 개수 역시 적기 때문에 불필요한 인덱스를 찾는 것이 마지막 영역에 비해서 수월하다.
  마지막으로 우선순위는 "RAP가 많은 SQL과 관계되며, 인덱스 개수는 적은 상태"이다. RAP가 많지만, 인덱스의 개수가 적은 상태로 접근이 용이하지 않다. 이미 최적화된 상태로 존재할 가능성이 높으며, 작업을 하더라도 효과를 보지 못하고 현재 상태를 유지하는 것이 옳다는 결론이 나올 가능성이 높다.

  6. 테이블의 제외 대상 분류
  작업자는 이렇게 접근 우선순위를 정하여 작업하다보면, 실제로 인덱스가 많은 곳에 대한 최적화를 강하게 요구받을 경우가 있다. 하지만 접근 우선순위에 따라 접근하다 보면 인덱스 최적화 작업이 어렵거나 불필요한 경우가 있다. 이를 예로 들면 같은 이유이다.

   - 데이터의 증가가 없거나, 더디지만 이를 Access하는 SQL이 많아 불필요한 장애를 발생할 가능성이 있는 경우
   - 이미 최적화되어 있는 상태
   - 절대적인 SQL의 수가 적은 상태

   이런 테이블들에 대해서는 작업이 어려운 경우 이기 때문에 작업자는 이러한 테이블들에 대해서 작업을 하면서 분류하고, 작업시 제외된 사유를 제공해야 한다. 하지만 작업자는 해당 테이블들에 대한 검토는 반드시 수행하여야 한다.

   7. 과거의 모습과 현재를 비교한 자료
   작업 이전과 작업 이후의 어느 정도의 성과가 있었는지에 대한 자료를 제공해야 한다. 이는 작업을 의뢰한 측과 작업을 수행한 측에 반드시 필요한 자료로써 매우 중요하다. 작업이 완료되면 일반적으로 테이블의 인덱스가 줄어야 한다고만 생각할 수 있지만 실제로는 인덱스가 증가할 수도 있다. 우선순위 첫번째와 두번째의 경우에는 인덱스가 줄어드는 바람직하고, 세번째와 네번째는 증가 또는 현상 유지될 가능성이 높다. 이는 필요한 인덱스가 생성되지 않은 채 불필요한 Access가 수행될 가능성이 있기 때문이다. 또한 매트릭스를 작성했을 때보다 표현되는 테이블의 수가 줄어들 수 있다. 6번 과정에서 작업이 제외된 테이블을 제외하고 매트릭스에 표현해야 차이를 확인하기 용이하다.

 
 [약점 및 한계]

인덱스 전략 매트릭스는 표현의 한계가 존재하게 되고, 이로 인해 발생하는 제약 및 해결하기 위한 접근 방법은 아래와 같다.

   1. SQL의 수가 적거나, SQL의 수행횟수가 누락
 SQL의 수가 적을 경우에는 RAP개수와의 상대적인 비율로 이를 표현하기 때문에 상위분면에 표현될 가능성이 높다. 또한 SQL의 수행횟수가 표현이 되지 않기 때문에 가중치 없이 이를 표현하여 영향도가 적은 대상이 많이 보일 수 있다. 이러한 한계를 극복하기 위해서는 작업자가 기준선을 정해놓고 작업을 하는 것이 수월하다. SQL의 수가 n개 이상이고, 해당 SQL의 수행 횟수가 특정 기간동안 n번 만큼 수행되어야 한다는 기준을 정해야 한다. 물론 이는 해당 데이터베이스의 환경에도 상당히 의존적이기 때문에 작업 환경을 고려하여 해당 수치를 정해야 한다.

   2. 데이터의 량과 컬럼의 개수에 대해 고려하지 않음
 인덱스 최적화 관련 프로젝트를 수행하러 가면 아래와 같은 경우를 많이 경험하게 된다. "우리에게 데이터가 많은 10개 테이블만 수행해달라". 이는 프로젝트 수행 비용에 대한 부담이 있어 최대한 빨리 끝내려고 하는 경우에 보이는 행동이다. 데이터가 많은 테이블은 가장 최소한의 비용을 들여 SQL 수행 시켜야 한다는 부담이 있지만, 실제로 인덱스를 최적화 시키는 작업은 단일 몇 개의 테이블만을 최적화 된다고 해서 해결되는 것이 아니다. 해당 데이터베이스에 존재하는 모든 테이블에 대해 인덱스를 최적화하여야만 제대로 된 성능을 보장할 수 있다. 작업을 의뢰한 고객은 데이터량을 우선순위로 작업을 해달라고 했지만, 실제 작업은 그렇게 작업을 하게 되면, 인덱스를 최적화 하는 순간 해당 SQL이 다른 실행계획을 가지고 수행될 수 있기 때문에 조심하여야 한다.
 인덱스 전략 매트릭스에는 이러한 관점에서 데이터 량을 우선순위의 관점을 뒤로하고 작업을 하게되는데, 여기서는 데이터량이 많은 것을 보는게 아니라, 데이터가 적은 테이블은 데이터의 연결고리로 사용되는 컬럼만을 인덱스 생성한다는 관점에서 보면 작업의 양을 줄이고, 성과를 높이기 위해서는 제외되어야 하는 대상이다. 이러한 테이블에 대해서는 빠르게 검토할 방법을 강구하고, 작업 우선순위를 뒤로 한다.

TAG

Leave Comments


profile우리는 하나님을 믿는다. 다른 모든 것들은 데이터로 검증해야 한다. 

Recent Trackback