Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
Tags
- Kotlin in action 5장
- 스프링 컨테이너와 스프링 빈
- 코틸린인액션
- Python
- 기능개발 python
- 백준
- Kotlin In Action
- spring
- 고급매핑
- 스프링 핵심 원리 - 기본편
- Kotlin in action 6장
- Kotlin in action 3장
- 객체 지향 설계와 스프링
- Kotlin
- 백준 13460 Python
- 자바 ORM 표준 JPA 프로그래밍 7장
- 백준 20055 컨베이어 벨트 위의 로봇
- 스프링 핵심 원리 이해
- 코틀린
- 컨베이어 벨트 위의 로봇 Python
- KotlinInAction
- 20055
- 7장 고급매핑
- kotlin in action 정리
- 싱글톤 컨테이너
- 스프링 핵심 원리
- Kotlin in action 10장
- 코틀린인액션
- 13460 구슬탈출 2
- 20055 컨베이어 벨트 위의 로봇
Archives
- Today
- Total
기록하는 습관
offset, cursor 기반 pagination 본문
1. Offset 기반
- 페이지 단위로 데이터를 불러오는 방식.
- offset 기반 페이지네이션은 우리가 원하는 데이터가 '몇 번째'에 있다는 데에 집중
offset을 사용해도 되는 경우
- 데이터의 변화가 거의 없다시피하여 중복 데이터가 노출될 염려가 없는 경우
- 일반 유저에게 노출되는 리스트가 아니라 중복 데이터가 노출되어도 크게 문제 되지 않는 경우
- 검색엔진이 인덱싱 할 이유도, 유저가 마지막 페이지를 갈 이유도, 오래 된 데이터의 링크가 공유 될 이유도 없는 경우
- 애초에 row 수가 그렇게 많지 않아 특별히 퍼포먼스 걱정이 필요 없는 경우
문제점
- 각각의 페이지를 요청하는 사이에 데이터의 변화가 있는 경우 중복 데이터 노출
- 대부분의 RDBMS 에서 OFFSET 쿼리의 퍼포먼스 이슈
2. Cursor 기반
- 클라이언트가 가져간 마지막 row의 순서상 다음 row들을 n개 요청/응답하게 구현
- cursor 기반 페이지네이션은 우리가 원하는 데이터가 '어떤 데이터의 다음'에 있다는 데에 집중
- n개의 row를 skip 한 다음 10개 주세요 가 아닌, 이 row 다음꺼부터 10개 주세요 를 요청하는 식
- 반드시 정렬 기준이 되는 필드 중 (적어도 하나는) 고유값이어야 한다.
요약
- 동일 레코드 중복 노출, 데이터의 빈번한 C/U/D 가 없는 리스트의 페이지네이션은 오프셋 기반으로 구현해도 좋음.
- 그외 거의 모든 리스트는 커서 기반 페이지네이션을 사용하는 것이 무조건적으로 좋다.
- 서버의 쿼리 퍼포먼스 / 클라이언트의 사용 편의를 위해서 커서로 사용할 값을 별도로 정의하고, 이 값을 활용한 WHERE / LIMIT 으로 커서 기반 페이지네이션을 구현할 수 있다.
- 이렇게 구현하는 경우 각 정렬 방식마다 cursor 값과 정렬할 필드, ASC/DESC를 지정함으로써 쿼리 생성을 깔끔하게 할 수 있다.
참고
'개발 > Research' 카테고리의 다른 글
Java (0) | 2022.07.12 |
---|---|
Spark, Hadoop (0) | 2022.07.12 |
lock 오픈소스 (ShedLock, dLock) (0) | 2022.07.12 |
AWS lambda (s3) (0) | 2022.07.12 |
DB 리서치 (S3, Mongo, Mysql - InnoDB, MyISAM, heap) (0) | 2022.07.12 |
Comments