Capacity Anti-Patterns(용량 안티패턴) -2

손으로 만든 SQL

개발자가 만든 SQL은 너무나 독특하고 예측할 수 없다.

1. 인덱스가 없는 컬럼에 자주 조인한다.

2. 일반적으로 너무 많은 테이블에 조인한다. 간단한 관계인 경우 ORM 패키지를 사용해야 한다.

3. 개발자는 SQL을 실질적인 집합기반의 관계형 언어가 아닌 절차형 언어나 객체지향 언어처럼 취급하려고 한다.

• 손으로 만든 SQL을 최소화하자

• 성능 최적화를 위해 자신이 만든 SQL을 실행하고픈 유혹에 빠질지 모른다. 데이터 베이스 안에서 같은 작업을 하는 방법이 있는지 살펴보는 것이 좋은 생각이며, 힌트나, 인덱스나 뷰를 이용하는 방법이 있다.

• 실제 데이터를 대상으로 성능향상을 확인하자

• 실전 크기의 데이터를 대상으로 손으로 만든 SQL을 시험하자. 개발 데이터베이스에서 관찰된 성능향상은 실전에서 근본적으로 다른 쿼리 계획 때문에 사라지곤 한다.

데이터베이스 부영양화

• 인덱스를 만들자. 이것은 데이터베이스 관리자만의 책임이 아니다.

• 개발자는 어플리케이션의 의도를 데이터베이스 관리자보다 더 잘 안다. 검색에 사용될 컬럼이 어떤 것인지, 어떤 테이블이 가장 많이 읽힐지, 어떤 테이블이 가장 많이 기록될지 반드시 알아야 한다. 인덱스를 구성하는 첫 번째 반복주기를 제시하는 것은 어플리케이션 개발자의 책임이다.

• 침전물을 제거하자.

• 오래된 데이터는 조회와 삽입을 느리게 만든다. 사용자가 주문이력 테이블과 같은 것에 관심을 두지 않는다면, 실전 서버에서 제거해야 한다.

• 실전에서 리포트를 분리하자.

• 리포트는 어디에서라도 서비스될 수 있고 되어야만 한다. 리포트가 값비싼 쿼리를 수행함으로 써 실전운영을 위험에 빠트리지 마라. 아울러, 리포트는 어쨌든 OLTP 스키마 보다 스타 스키마에서 더욱 잘 만들어진다.

통합지점 지연

다른 시스템과의 통신은 어떤 것이든 어느 정도의 지연을 수반한다. 원격 호출은 로컬 호출보다 적어도 천 배정도 오래 걸린다. 통합지점 지연은 심각한 성능 문제가 될 수 있다. 이런 문제는 통합지점이 원격객체 프로토콜의 독특한 특성을 사용할 때 심각해진다. 원격 객체에 대한 “위치 투명성” 철학은 호출자가 로컬 호출과 원격 호출 사이에서 차이를 인식하지 못해야 한다고 주장한다. 이런 철학은 두 개의 주요한 이유 때문에 널리 신뢰되지 않는다.

1. 원격 호출은 로컬 호출과 다른 고장 유형을 보인다. 원격 호출은 원격 처리에서 일어나는 네트워크 고장이나, 호출자와 서버 사이에 버전이 맞지 않는 등의 문제에 취약하다.

2. 위치 투명성은 개발자가 로컬 객체를 설계하는 방식과 동일하게 원격 객체 인터페이스를 설계하도록 유도하기 때문에, 번잡한 인터페이스가 나온다. 이런 설계는 상호작용을 한한 할 때 다수의 메서드 호출을 사용한다.

개별적인 사용자에 대한 성능 문제는 전체 시스템에 대한 용량 문제가 된다. 트랜잭션을 처리하는 쓰레드는 응답을 기다리는 동안 일시적으로 유휴 상태에 있어도, 많은 자원을 점유한다. 쓰레드는 확실히 메모리와 CPU의 타임 슬라이스를 소비한다. 아울러 이 쓰레드는 다른 쓰레드가 필요한 데이터베이스의 연결을 점유할 수도 있다. 더 아래 쪽에서 유휴 쓰레드가 데이터베이스 안에서 열이나 페이지에 락을 걸어 두었다면, 데이터베이스 안에서 경쟁을 유발시킨다.

• 웬만해서는 자신을 지연되게 하지 마라.

• 번잡스러운 원격 프로토콜을 삼가자. 이런 프로토콜이 실행되는데 오래 걸릴수록, 소중한 요청을 처리하는 쓰레드를 정체시킨다.