목록 쿼리 - 페이지 처리에 대한 고찰

페이지 처리

현재의 인터넷 페이지는 아주 많은 부분이 게시판 형식의 목록 형태로 되어 있다. 수 천에서 수백만 이상의 데이터를 특정 조건으로 조회/정렬하여 사용자 화면에 보여주게 되는 이러한 형태의 SQL은 자주 사용되어진다. 이 문서는 이러한 목록 형태의 SQL을 패턴별로 어떻게 작성해야 효율적인지에 대하여 설명할 것이다.

왜 제대로 해야 하는가?

목록 형태의 웹 페이지는 거의 모든 웹사이트에서 필수적으로 사용되고 있다. 이 이야기는 결국 DBMS을 이용하여 서비스를 하는 웹사이트는 필수적으로 목록 SQL을 작성할 수 밖에 없다는 말과 같다. 그런데 많은 개발자들이 이러한 SQL의 중요성을 잘 모르고 있을 뿐만 아니라 효율적으로 작성하지 못하는 것이 현실이다. 또한 다양한 사이트에서 SQL튜닝을 지원한 결과 많은 사이트에서의 성능 이슈가 주로 목록 SQL에 있었다는 점이다. 심지어 모 회사에서 만든 프레임워크에서는 웹 페이지의 페이지처리를 담당할 수 있는 모듈을 공통기능으로 만들어 놓았으나, 프레임워크에서 성능에 부정적인 SQL을 자동으로 생성해 주는 문제점도 보았다.

다음과 같은 경우를 생각해보자

1.     페이지 처리를 SQL에서(DBMS에서)하지 않고 어플리케이션에서 하는 경우

이 경우 SQL이 효율적으로 작성되어 있다(물론 페이지처리를 할 때의 효율성은 아니다) 하더라도 네트워크에 대한 부하는 막을 수 없다. 앞쪽 페이지의 경우에는 네트워크 부하가 적을 수 있으나 뒤쪽 페이지로 이동 할 수록 DBMS와 WAS간의 데이터 통신량은 늘어 날 것이다.

예를 들어, 한 건의 로우가 2,000바이트이고 페이지당 50건씩 보여준다고 할 때 1,000번째 페이지로 이동한 경우를 생각해 보라.(누가 1,000 페이지까지 보겠어? 라고 반 문 할 수도 있지만, 보지 말라는 법도 없다.) 95.5MB(2,000 * 50 * 1,000)가 네트워크 라인을 타고 DBMS에서 WAS로 전달 될 것이고, 어플리케이션에서는 50,000번(50 * 1000) 만큼 루프를 돌며 앞쪽 49,950건의 데이터는 그냥 버리게 될 것이다.

이런 비효율을 감수하면서도 어플리케이션에서 페이지처리를 할 것인가?

2.     페이지 처리를 어플리케이션에서 하되, SQL이 효율적이지 않은 경우

수백 수천 건 정도의 데이터인 경우에는 크게 문제가 되지 않겠으나, 수십 수백만 건의 데이터에 대해서 조인/정렬 등의 작업은 많은 부하를 줄 수 밖에 없다. 목록에서 특정 로우를 클릭하여 조회하는 경우에는 주로 Unique Index를 사용하므로 문제가 될 것이 없지만, 목록을 조회하는 경우에는 SQL의 효율이 아주 중요하다 할 수 있다. 이러한 목록 형태의 SQL들은 특히 좀더 효율적으로 작성하여야 한다. 

기본개념

페이지 처리를 위한 효율적인 SQL을 작성하는 것도 SQL을 튜닝하는 기본 개념과 다르지 않다. 몇 가지 중요한 원리만 알고, 그 원리에 기반하여 SQL을 작성하면 좋은 성능을 보장 받을 수 있다.

첫 번째 I/O의 최소화이다. I/O를 최소화 한다는 이야기는 Disk 또는 DB Buffer로 부터 필요로 하는 데이터만을 읽는 것이다. 잘 수립된 인덱스 전략으로 생성된 인덱스를 효율적으로 엑세스 하는 것이 중요하다. 인덱스를 효율적으로 엑세스 할 수 없다면, Index FFS를 통해서 처리할 수 있는 방안이 있는지도 고민해 봐야 한다.

두 번째 조인의 최소화이다. 이는 I/O최소화와도 아주 관련이 많다. 필요로 하는 데이터만을 이용하여 두 번째 테이블과 조인하여야만 조인을 최소화 하고 I/O도 최소화 할 수 있는 것이다.

세 번째 정렬의 제거 또는 최소화이다. Index를 잘 활용하면 정렬을 수행 하지 않고도 정렬된 결과를 얻을 수 있으며, 정렬이 불가피한 경우에는 정렬을 수행할 데이터의 양을 최소화 하는 것이다.

대부분의 SQL는 위의 3가지를 유의하여 작성하면 최소한의 성능은 보장 받을 수 있다. 

이러한 원리를 적용한 구체적인 사례를 통하여 앞으로 이 블로그에 하나씩 설명을 하고자 한다.

(시간이 생길 때 마다 하나씩 정리해 봐야겠다.)

패턴1 – 검색조건 없음

패턴2 – 단일테이블 검색조건

패턴3 – 다중테이블 검색조건

패턴4 – OUTER 조인을 포함