2페이징 스크롤이 잦은 기능의 경우, 써보면 좋을 법한 아이디어가 있어 공유해보려 한다. 보통 스크롤 페이징을 구현해놓더라도 1페이징에 머무는 기능이 대부분이다. 예를 들어, 채팅 메시지 목록을 1페이징으로 조회한다고 했을 때, 메시지를 스크롤로 올려 이전 메시지를 확인하는 경우보다 1페이징에서 머물다 바로 메시지를 보내는 경우가 많다. (아니라고 하더라도 가정해보자) 하지만, 페이스북의 뉴스피드 타임라인의 경우 첫 페이징에 머물기보다는 2페이징, 3페이징 스크롤하여 나아갈 가능성이 많다. 이러한 경우 물론, OFFSET 페이징보다 커서 페이징이 이점이겠지만, 때에 따라 커서 페이징이 불가능한 경우가 있을 수도 있고, 커서가 2개 이상 존재하여 OFFSET 보다 속도가 나지 않는 경우가 있다. 이럴 때,..
특수한 경우에 페이징을 구현함에 있어 괜찮은 속도 개선을 만들어낸 경험이 있어 정리해보려 한다. 0. 테이블 2개의 페이징 보통 페이징을 시도하는 테이블은 1개가 정석인데, 2개로 요청이 들어왔다면 어떻게 쿼리를 짜야할까? 게시물과 댓글 각각 테이블로 데이터를 관리하고 있는 상태에서 게시물, 댓글 모두 등록시간순으로 정렬해 한꺼번에 리스팅 해주면 좋겠다는 요건이 나왔다. 일단, 강력하게 게시물, 댓글을 탭을 나눠 따로 조회했으면 좋겠다고 주장했으나 먹히지 않았다. 1. UNION 페이징 --UNION PAGING SELECT data, register_time FROM board --게시물 UNION SELECT data, register_time FROM comment --댓글 ORDER BY regi..
0. 스크롤 페이징이 점점 느려져요! 페이징은 점점 느려질 수 있다. 테이블의 크기가 커지면서 느려질 수도 있고, API 로직이 복잡해지면서 느려질 수도 있다. 하지만, 애초에 OFFSET, LIMIT으로 조회하는 방식은 앞에서 읽었던 행을 다시 읽어야하기 때문에 뒤로 갈수록 느리다. 그리고 OFFSET, LIMIT은 인덱스 스캔과는 전혀 상관없는 명령어기때문에 인덱스의 이점을 살릴 수도 없다. 이 때, 개선 가능한 방법이 No-Offset 페이징 혹은 커서 페이징이라고 불리우는 페이징 기법이다. 1. 속도가 빠른 커서 페이징 "커서 기반 페이징이 가장 효율적인 방법이며, 가능한 항상 사용되어야한다."라고 타임라인 기능을 무한스크롤 페이징으로 만든 페이스북 개발자는 말했다. 그만큼 커서 페이징은 가장 효..
서비스를 운영하면서 게시판 페이징, 스크롤 페이징을 경험해보았고, 페이징을 심도있게 공부하면서 실질적인 성능과 유지보수에 관해 고민했던 내용을 백엔드 개발자의 입장으로서 두서없이 적어보려고 한다. 정답이 아니라 하나의 방법으로서... 0. 페이징을 하는 이유는? [why] 결론부터 말하면 페이징은 속도는 빠르게, 부하는 적게 하기 위해 지금 당장 필요한 데이터만 가져올 수 있도록 데이터를 분리하는 작업이다. 예를 들어, 10만 개의 게시물 데이터가 있다고 가정했을 때, 페이징 없이 10만 개의 데이터를 한 번에 가져온다 생각해보자. 먼저 DB에서 쿼리로 10만개의 데이터를 조회한다. 정렬과 필터조건, 조인 여부에 따라 시간은 천차만별이겠지만 행여 그러한 복잡한 로직이 없더라도 쿼리를 순식간에 실행해 10..
