2페이징 스크롤이 잦은 기능의 경우, 써보면 좋을 법한 아이디어가 있어 공유해보려 한다.
보통 스크롤 페이징을 구현해놓더라도 1페이징에 머무는 기능이 대부분이다. 예를 들어, 채팅 메시지 목록을 1페이징으로 조회한다고 했을 때, 메시지를 스크롤로 올려 이전 메시지를 확인하는 경우보다 1페이징에서 머물다 바로 메시지를 보내는 경우가 많다. (아니라고 하더라도 가정해보자) 하지만, 페이스북의 뉴스피드 타임라인의 경우 첫 페이징에 머물기보다는 2페이징, 3페이징 스크롤하여 나아갈 가능성이 많다. 이러한 경우 물론, OFFSET 페이징보다 커서 페이징이 이점이겠지만, 때에 따라 커서 페이징이 불가능한 경우가 있을 수도 있고, 커서가 2개 이상 존재하여 OFFSET 보다 속도가 나지 않는 경우가 있다.
이럴 때, 2페이징, 3페이징의 속도를 끌어올리기 위해, 정렬 플래그가 되는 값들을 1페이징에 미리 여러 개를 들고 와 2페이징시 IN 절로 데이터를 가져오는 것이다.
--1페이징
--1-1. 100개의 플래그값을 가져온다.
SELECT data_num FROM board ORDER BY data_num LIMIT 100;
--1-2. 1페이지에 해당되는 10개의 데이터를 IN절 가져온다.
SELECT data num FROM board WHERE data_num in (1000,999,998,997,996,995,994,993,992,991);
--2페이징
--1-2. 2페이징에 해당되는 10개의 데이터를 IN절로 가져온다.
SELECT data num FROM board WHERE data_num in (990,989,988,987,986,985,984,983,982,981);
...
--11페이징
--1-1. 100개의 플래그값을 더 가져온다.
SELECT data_num FROM board ORDER BY data_num LIMIT 100 OFFSET 100;
쿼리를 찬찬히 살펴보면 정렬하고 LIMIT 하여 페이징하는 것이 아니라 최초에 어느 정도 플래그 값들을 다 가져온 후 10 사이클 (리밋은 10개인데, data_num은 100개를 가져와 10 싸이클 동안 활용한다) 정도 IN 절을 활용하여 데이터를 가져오는 방식이다. 이것의 장점은 일단, 플래그 값을 가져오는 쿼리의 경우 Index Only Scan을 타서 굉장히 빠르게 데이터들을 가져올 수 있다는 것이다. (INDEX ONLY SCAN 이 무조건 INDEX SCAN보다 빠른 것은 아니나 대게 그러하다) 그리고 데이터를 가져오는 쿼리의 경우 IN 절이기에 인덱스를 타 더 빠른 속도 이점을 가질 수 있다.
하지만, 위의 예시는 cursor 페이징 하는 것과 큰 차이가 없으니, 만약 복잡한 쿼리 페이징 중에 속도가 잘 나지 않는다고 생각되면 한 번 써보면 좋을 방법으로 보인다. 또, 2페이징 스크롤이 잦지 않은 경우 애초에 플래그 값들은 가져오기 위해 쿼리가 한번 더 수행될 필요가 없기 때문에 상황을 고려해서 써볼 방법으로 보인다.
'Deep Dive Series > Paging' 카테고리의 다른 글
[페이징 톺아보기 2] 두 테이블의 유니온 페이징 (정석이 아니라 선택) (0) | 2021.08.02 |
---|---|
[페이징 톺아보기 1] 가장 효율적인 커서 기반 페이징 (0) | 2021.08.02 |
[페이징 톺아보기 0] Why, How, What is 'Paging'? (0) | 2021.07.31 |