아래 링크 참조

https://gall.dcinside.com/board/view/?id=programming&no=1839835

우선 디씨와 같은 방식의 페이지네이션은 아니야

그리고 결국엔 단점도 존재하지

디씨가 어떻게 구현했는지 노무노무 궁금해

내가 생각해낸 방식은 Keyset + Offset이야

Keyset만으로 특정 페이지를 찾아가는것은 불가능해

왜냐하면 중간중간에 글들이 지워지기 때문이지 실제 테이블에서 레코드를 안지우고 is_deleted같은 필드를 지정하더라도 결과는 같아

이유는 알거라고 생각함. 모르면 댓글로 질문

posts 란 테이블이 있고

id INTEGER,

is_deleted BOOLEAN

가 있다고 쳐보자

id는 글 번호 즉 1번부터 시작해서 번호가 클수록 가장 최근 글이지 글이 삭제되더라도 id는 그대로 남아있어

다음 조건으로

- 1페이지당 글이 10개

- 글이 100개 있다고 치면 총 10페이지

- 가장 최근인 1 페이지는 100~91

- 만약 2페이지면 글번호는 90~81

- id 가 key

쿼리는 3개로 이루어져있고 순서는 다음과 같아

1. (is_deleted=false) 인 가장 최근 글을 찾는다

1.1. 그 최근 글에서 가고싶은 페이지의 마지막 글 번호를 얻는다

- 가고싶은 페이지가 3페이지면 마지막 글번호는 80

2. 그 글 번호를 기준으로 이후에 삭제된 글 갯수를 얻는다

- 만약 글 99, 98, 97이 지워졌으면 글번호 80이후 삭제된 글 갯수는 3

3. 글번호 80 에서 삭제된 글 갯수만큰 뺀 Key에서 (80 - 3) 시작해서 삭제되지 않은 글들중 마지막 글 번호를 찾는다 (지워진 레코드수만큼 채워줘야함)

3에서 나온 번호가 내가 찾으려는 페이지중 가장 최근 글이겠지?

그럼 그 번호 기준으로 지워지지 않은 글 10개를 찾으면 그게 해당 페이지인거야

Key는 id기준으로 찾는거니 Keyset 페이지네이션이 아니냐고?

바로 3번 쿼리에서 삭제된 글 수만큼 Offset을 사용할거야

SELECT id FROM posts

WHERE id <= 78 AND is_deleted = false

ORDER BY id

OFFSET 3

LIMIT 1

이러면 2번 페이지의 첫번째 글, 즉 3번 페이지의 마지막 글의 기준이 되는 Key인 id를 알수있지

그럼 그 id를 기준으로 10개를 뽑으면 그게 3번째 페이지가 되는거야.

결국 OFFSET을 쓰면서 그럼 퍼포먼스는 똑같이 않겠냐고?

아니야 왜냐면 요건 OFFSET을 "지워진 글갯수"에 한해서 쓰거든

즉 지워진 글들이 적으면 적을수록 성능은 가장 빠르고

지워진 글들이 늘어나면 늘어날수록 성능은 느려지지

예를 들면

1000만 레코드를 OFFSET으로 페이지네이션 했을때 가장 마지막페이지로 가려면 수초가 걸려.

지워진 글 갯수에 상관없이 수초가 걸리지.

1000만 레코드를 KEYSET+OFFSET으로 페이지네이션 하면

맥북프로 기준으로

지워진 글이 1만개일시 성능은 거의 차이가 없어

지워진 글 10만개정도부터 100ms정도 늘어나고

지워진 글 100만개 됐을때는 1초 안으로 처리되더라고

야갤보면 글이 약 800만개에

지워진 글은 약 5만개 정도인것으로 보여

800만개를 단순 OFFSET으로 페이지네이션 했을때 수초 걸리는걸 생각해보면

OFFSET+KEYSET으로는 지워진글 을 5만개라고 했을때 쿼리당 100ms도 안걸리는걸 알수있지.

나름대로 만족하는 답이야 그래서 이렇게 길게라도 글을 남기는거임

근데 이게 디씨가 사용하는 방식이 아닌 이유는

디씨는 첫페이지나 마지막 페이지나 처리시간이 거의 비슷함.. 그래서 뭔가 다른거라고 생각하는중임.