Offset & Cursor

What

• 페이징이란?

• 종류
• 오프셋 페이징
• OffSet : 어디 부터 시작해서 가져올것인지?
• Limit : 몇개를 가져올 것인지?

SELECT * FROM ${table_name}
ORDER BY ${Column}
OFFSET 10 LIMIT 5

• 보통 offset 페이징은 프론트 엔드에서 이렇게 표현됩니다.
페이지 버튼과 함꼐 쓰이며 버튼을 클릭함으로써 페이지를 휙휙 넘길 수 있습니다.

• 커서 페이징
• Cursor - 사전적의미

사전적 의미 : 데이터베이스 커서는 일련의 데이터에 순차적으로 액세스할 때 검색 및 "현재 위치"를 포함하는 데이터 요소 DB 의미 : 특정 SQL 문장을 처리한 결과를 담고 있는 영역을 가리키는 일종의 포인터 입니다.

 
• 실시간 데이터와 대량의 데이터(페이스북, 슬랙 , 트위터 등)을 다루는 웹사이트에서 쓰이는 페이징 방법으로써, 프론트에서 무한 스크롤(인스타 그램, 페이스북처럼 하단으로 계속 스크롤 되는 페이징 방식)을 지원
 

Why [왜 cursor 인가?]

우수한 실시간 데이터 처리 능력

• 오프셋 쿼리 예시

SELECT *
  FROM (
        SELECT ROWNUM() over (ORDER BY timestamp) rnum
             , A.*
          FROM table A
         ORDER BY timestamp
        )
 WHERE ROWNUM BETWEEN 6 AND 10

• timestamp를 정렬 기준으로 전체 데이터의 행번호를 출력하고 이 번호를 기준으로 잘라내는 것입니다.

• 이건 오프셋 숫자가 커질수록 큰 문제가 됩니다. 다량의 데이터를 테스트 하는 부분에서 아주 큰 차이를 보입니다.



또 고려해봐야 할 것들

✍🏻
마지막 페이지를 이용할 확률은 얼마정도 될까? 0%는 아니겠지만, 매우 작을 것이다.
그렇지만 굳이 7백만개의 데이터가 아니더라도, 그래프에서 확인 할 수 있듯이 오프셋 페이징의 시간복잡성 O(N), O(offset+limit) 때문에 오프셋이 커질수록 시간이 증가해 UX는 감소합니다. 반면 커서 페이징의 경우는 O(1), O(limit)로 항상 일정합니다.
따라서 전보다 페이지 로딩이 느려진 것같은 느낌이 든적이 있다면, 아마도 그건 오프셋 페이징의 비효율성 때문입니다 ‼️

누락되지 않는 데이터 - 사용자의 기대 부응

• Offset 페이징 예시 - sns에서 최근 피드 3개의 피드가 올라왔다.

사용자에게 보여지는 페이지당 데이터 구성

==== 1 페이지 =======
A
B
F
==== 2 페이지 ======
G
H
I
==== 3 페이지 ====== 
.
.
.


sns에서 최근 피드 3개의 피드가 올라왔다.

==== 1 페이지 =======
A
B
C [new]
==== 2 페이지 ======
D [new]
E [new]
F
==== 3 페이지 ====== 
G
H
I

• 해당 데이터의 새로운 삽입 으로 현재 보고 있는 2페이지에서 3페이지로 갈 떄 똑같은 데이터가 보이게 될 수 있다. 사용자는 ? 할 수 도 있습니다.

• 삽입 외로 삭제가 이루어질 경우도 비슷합니다.

• 실제적으로 사용될 쿼리 예시

SELECT * FROM table ORDER BY timestamp OFFSET  0 LIMIT 3
SELECT * FROM table ORDER BY timestamp OFFSET  3 LIMIT 3
SELECT * FROM table ORDER BY timestamp OFFSET 6 LIMIT 3
SELECT * FROM table ORDER BY timestamp OFFSET 9 LIMIT 3

• Cursor 페이징 예시 - sns에서 최근 피드 3개의 피드가 올라왔다.

사용자에게 보여지는 페이지당 데이터 구성

==== 1 페이지 =======
A
B
F
==== 2 페이지 ======
G
H
I
==== 3 페이지 ====== 
.
.
.


sns에서 최근 피드 3개의 피드가 올라왔다.

==== 1 페이지 =======
A
B
F
==== 2 페이지 [다음 데이터 요청 가져옴] ======
G
H
I
==== 3 페이지[다음 데이터 요청 가져옴]====== 
.
.
.

• 왜 삽입된 데이터들을 안불러올까?

• 오프셋은 매번 항상 데이터들을 모두 가져와서 선별을 하지만, 커서는 지정된 기준 이외에는 전체 데이터를 뒤적거리지 않고 특정 조건 이후에 있는 데이터들만 선별해서 가져옵니다.

쿼리 결과에 대한 스코프

제한된 정렬 기능

• Firstname과 Lastname을 기준으로 정렬한 테이블 하나를 가정 해봅니다.

• 이 경우는 커서 페이징에 구현에 문제를 발생시킨다. 왜냐하면 커서 페이징 정렬의 요구사항 중 하나는 정렬할 컬럼에 중복된 값이 존재하면 안되고, 순차적이어야 한다 는 것 입니다. 커서 페이징을 사용하려면 "이 레코드 다음 레코드를 조회해줘"라고 할 수 있는 특정 지점을 커서로 지정할 수 있어야 합니다.

이런 요구사항 때문에, 대부분의 커서 페이징은 timestamp 컬럼을 기준으로 한다. 왜냐하면 작은 단위의 timestamp는 순차적이고 고유하기 때문입니다.

Firstname은 순차적일 수는 있지만 고유하지는 않습니다. 우리는 김, 박, 최씨를 적어도 100명은 알고 있습니다. 그래서 이런 경우 커서는 고유한 레코드가 아닌 전체 레코드 집합을 가리킬 수도 있습니다. 따라서 커서를 구현한 방법에 따라 데이터를 건너 뛰거나 중복될 수 있습니다.

회원 테이블의 경우 정렬 기준으로 이메일이 더 좋을 수 있습니다. 고유하고 순차적 이라고 볼 수 있기 때문입니다.

그러나 요구사항이 Lastname 또는 Firstname으로 정렬하는 것이라면 커서 페이징이 적합하지 않을 수 있습니다. 이름과 성을 연결하거나 여러 열의 튜플을 사용하여 고유한 열을 만들 수 있지만 이로 인해 커서 페이징이 오프셋 페이징보다 훨씬 느려질 수도 있습니다. SQL문에서 연결 및 튜플 비교는 모두 시간복잡도 O(N), O(전체 데이터) 를 가지기 때문입니다.

• 커서를 잘못 쓰는 경우 포포몬쓰의 저하

• 실제로, 커서 페이징이 오프셋 페이징보다 첫번째 페이지를 훨씬 느리게 조회했습니다. 직관적으로 이해되지 않을 수 있지만 Cursor(Concatenated)가 우하향 하는 이유는 레코드가 많아 질수록 SELECT 하는 레코드가 적기 때문입니다.

How

Offset

• 스프링 jpa에 제공하는 Pageable 객체 사용

• Pageable 구현체에는 PageRequest라는 객체가 존재합니다.
• 해당 PageRequest는 해당 페이징에 필요로 하는 것들이 있습니다.
• 몇개씩 보여줄 것인지(limit) 어디 페이지(offset은 아니지만 연관이 있음.)를 볼것인지?에 대한 정보가 필요합니다.
• 클라이언트로 부터 사이즈와 페이지 정보를 받습니다.
• PageRequest 객체를 생성합니다.

public static PageRequest of(int page, int size, Sort sort) {
		// 페이지는 0부터 시작한다! 사용자는 1,2,3 이지만 컴퓨터 세계는 0번째부터 존재함을 인지해야 한다.
		return new PageRequest(page, size, sort);
	}

• 페이지 번호

• 전 페이지 존재 여부 등등…

• 추가적으로 이것보다 UI에서는 현재 페이지들의 번호가 필요하니 따로 커스텀 해야합니다!

Cursor

• 페이지를 처음 진입했을 때는 별도의 페이징을 하지 않고 일정 개수만큼 조회합니다.
• 조회한 데이터 중 마지막 데이터의 커서값을 조회 데이터와 함께 프론트에 넘겨줍니다.

• 다음 데이터를 조회할 때에는 백엔드에게 커서 값과 함께 “이 커서 값 이후의 데이터를 N개 조회 해주세요" 라고 요청 보냅니다.

• 백엔드는 커서 값 이후의 데이터를 조회합니다.(Member를 id 역순으로 조회, 최근 커서가 id = 10일 경우)
• ex) SELECT m From Member m WHERE id < 10 ORDER BY id DESC LIMIT 6;

❗️ Cursor 방식 페이징 사용 시 주의점

• 데이터 유실에 주의 하세요 ‼️ 

• 쿼리를 잘 짜야합니다! ‼️ 

SELECT * FROM post WHERE id < ${cursorId} and updatedAt <= ${cursorUpdatedAt} 
	order by updatedAt desc, id desc limit 3;

# 처음 데이터 3개 불러오기 (마지막 데이터 id = 14, updatedAt = 2022-08-14 09:53:39
SELECT * FROM post order by updatedAt desc, id desc limit 3;

# 다음 페이징
# cursor -> id = 14, updatedAt = 2022-08-14 09:53:39
# 13, 11, 10
SELECT * FROM post WHERE id < 14 and updatedAt <= '2022-08-14 09:53:39' 
	order by updatedAt desc, id desc limit 3;

# 다음 페이징
# cursor -> id = 10, updatedAt = 2022-08-14 08:53:39
# 8, 7, 9
SELECT * FROM post WHERE id < 10 and updatedAt <= '2022-08-14 08:53:39' 
	order by updatedAt desc, id desc limit 3;

SELECT * 
FROM post 
WHERE updatedAt < ${cursorUpdatedAt} 
			or (id < ${cursorId} and updatedAt == ${cursorUpdatedAt}
ORDER BY updatedAt DESC, id DESC LIMIT 3;

1. 처음 3개의 데이터를 불러옵니다 cursor 는 id = 1, updatedAt = 2022-09-04 12:00:00 입니다.

2. 그 다음은 updatedAt < 2022-09-04 12:00:00 조건으로 id가 18, 17, 6 … 인 값이 조회되고
2022-09-04 12:00:00:00과 중복되는 데이터가 없으므로 다음으로 넘어갑니다
이제 cursor는 id = 6, updatedAt = 2022-09-04 08:00:00입니다.

3. 다음으로 updatedAt < 2022-09-04 08:00:00 조건으로 3-a 부분이 조회됩니다.
cursor updatedAt보다 작은 데이터들입니다.
id < 6 AND updatedAt = 2022-09-04 08:00:00 조건으로 3-b 부분이 조회됩니다.
cursor updatedAt과 같지만 id가 더 작은 것 들입니다. 중복 문제가 해결 되었습니다.

REFER

무한 스크롤링을 이용하여 성능 개선하기

안녕하세요! 이번 포스팅에서는 기존 리스트에 무한 스크롤링 방식 을 추가하여 성능을 개선한 사례를 소개해드리려고 합니다. SELECT * FROM 테이블 WHERE 검색조건 ORDER BY id 기존에 리스트를 가져올 때는 SELECT 된 결괐값들을 모두 가져와서 리스트에 담아서 View 단에서 반복문을 돌려서 뿌리는 방법을 사용하곤 했습니다.

https://shinsunyoung.tistory.com/98

Infinite Scroll로 리스트 처리하기

데이터가 많은 리스트를 보여주는 방법에는 크게 두 가지가 있습니다. 첫 번째는 게시판에서 주로 볼 수 있는 페이징 방식이고 두 번째는 인스타그램이나 페이스북 등에서 볼 수 있는 무한 스크롤 방식입니다. 페이징 은 위 사진과 같이 한 페이지당 나오는 데이터의 개수가 정해져 있고 주로 1부터 시작하는 페이지를 옮겨가며 여러 건의 데이터를 순차적으로 조회하는 방식입니다.

https://hye-on-astrogrammer.tistory.com/21