2019-10-11 개발일지

오늘은 앱 내에 보여주는 사용자의 한 줄 광고 기능에 연관된 API를 만들었다.

신청자는 자신이 신청했던 이력을 볼 수 있는 목록 화면이 있어 목록 API를 만들었다.

관리자는 모든 신청자들의 이력을 볼 수 있는 목록 API를 만들었다.

 

해당 데이터를 관리하는 DB는 MS-SQL 2005라 또 로우 쿼리를 직접 작성해야 했다.

 

혹여나 내가 아직 찾지 못한 방법이 있지 않을까 다시 한번 탐색을 진행했지만 MS-SQL 2005에 대한 지원은 어쩔 수 없는 모양이다.

 

결국 수동으로 offset next limit을 대체하기 위해 TOP()함수를 사용했다.

 

 

그리고 이번에 페이지 네이션 처리를 다르게 했다.

 

 

기존 offset 방식의 페이지 네이션 처리를 해왔었는데, 해당 페이지 네이션 대신 커서 방식의 페이지 네이션 처리를 알게되서 작업을 해봤다.

 

 

 

 

OFFSET을 이용한 페이지 네이션 처리 방식

OFFSET 구문을 이용한 페이지 네이션 처리는 클라이언트가 보고자 하는 페이지를 요청했을 때 해당 페이지의 목록 범위구간을 조회하는 방식이다.

 

해당 방식은 다음과 같은 문제점을 갖는다.

• 페이지를 요청하는 사이 데이터에 변화가 발생하는 경우 중복 데이터가 노출되는 문제가 존재한다.

클라이언트에서 2 페이지를 보고 있을 때 누군가가 새로운 게시글을 작성한 경우 3 페이지로 넘어가면 2 페이지에서 보고 있던 게시글이 3 페이지에 표현되는 현상이 발생한다. 이를 중복 데이터가 노출되었다고 표현한다.

 

• RDBMS에서의 OFFSET 쿼리의 퍼포먼스 이슈

RDBMS는 OFFSET을 통해 쿼리한다고 했을 때, 모든 값들을 만들고 지정된 갯수만큼 순회하여 자르는 방식을 사용한다.

이 때 테이블의 row수가 많을 때, OFFSET의 수도 높아진다면 쿼리의 퍼포먼스가 하락하는 구조로 만들어져있다.

총 게시글 수가 50십만개라고 했을 때, 10,000 페이지를 조회할 때 OFFSET의 값은 10000이 된다.

이 경우 수많은 게시글을 순회해야하기 때문에 성능 이슈가 발생한다.

 

 

커서 방식을 이용한 페이지 네이션 처리 방식

커서 방식을 이용한 페이지 네이션 처리는 클라이언트가 보고 있는 페이지의 마지막 게시글을 기준으로 이전 게시글을 조회하는 방식이다.

 

해당 방식은 클라이언트가 지금 수많은 row중에 몇번째 row를 보고 있는지 '위치'를 알고 있다.

이 때 커서 방식의 페이지 네이션은 현재 보고 있는 row의 이후 데이터를 바로 접근하여 조회하면 되므로 전체 row를 순회할 필요가 없다.

 

 

즉 전체 row를 순회하여 데이터를 추출하느냐, 현재 시점을 기준으로 다음 row를 조회하느냐의 차이이다.

 

 

이를 OFFSET, NEXT, LIMIT 구문을 지원하지 않는 MS-SQL 2005 기준으로 구현하려면 다음과 같이 쿼리할 수 있다.

 

SELECT 
    TOP(10) 
    ...
FROM 
    Table
WHERE 
    ...
    id < 10001

 

딱히 크게 변동이 있는 쿼리가 되지 않았다.

LIMIT 구문을 TOP이 대신 담당한다.