페이지네이션 처리 방식 결정 안건

[hyunsb]

Content

페이지네이션 처리 방식을 결정해야할 것 같습니다. 현재는 구현이 쉬운 오프셋 방식 구현했지만 대용량 데이터 처리의 경우에 해당 방식은 성능이 저하될 우려가 있습니다.

따라서 커서 방식 도입 의견이 나왔습니다. 커서 방식으로 페이지네이션을 구현할 경우 페이징의 기준이 되는 key값 선정을 논의해야 합니다.

[hyunsb]

• 커서 기반 페이지네이션은 페이징을 위해 키 값을 기준으로 데이터를 가져옴

• 기준이 되는 키 값을 비교연산자(<, >, <=, >=)를 통해 가져오기에 정렬 가능한 컬럼이어야 함

• 기준이 되는 키 값은 성능을 위해 인덱싱 되어야 함

• 보통 정수형 auto_increment PK를 통해 데이터를 페이징함

• 커서 기반 페이지네이션을 적용하려면 어떤 값을 키로 사용해야 할까? PK를 정수형 auto_increment로 두고 UUID는 유니크 키로 둔다. (가정) 페이지 마지막 데이터의 UUID를 통해 PK를 찾아 해당 PK ~ PK + size 까지 데이터를 가져온다

  이렇게 하면 PK 인덱스를 통해 페이징 가능 (역순도 가능), 데이터를 레인지스캔으로 가져올 가능성 높음

[hyunsb]

order by 조건이 있는 경우 복합인덱스를 사용하여 페이지네이션할 수 있다.

서비스가 확장됨에 따라 인덱스가 너무 커지는 게 아닌지? ->

• 인덱스가 많아지면 CUD 작업의 효율이 떨어진다. 가게 테이블이 수정될 가능성이 많은가?
  • 별점은 새벽 3시에 스케줄링으로 합산처리하는데 성능에 무리가 갈 것인지?
• 거의 사용되지 않는 정렬 조건은 인덱스를 걸어놓지 않아도 되지 않을까

[sososo0]

저는 cursor 기반이 더 좋아보입니다!

• 데이터를 순차적으로 조회하지 않아도 되기 때문에, 성능상의 이점이 있다.
• offset 기반과 달리, 데이터가 생성, 삭제 될 때에도 중복 및 누락되는 상황이 적어진다.

생각해보면 좋을 것

• 다른 정렬 조건이 들어올 때, cursor 값을 어떻게 선정하면 좋을지?
• 복합 인덱스를 사용해야 하는지?
• 정렬 조건이 많아진다면 인덱스가 많아지는 것은 아닌지?
• 적용 범위
  • 적용되는 기능 : 가게 조회(모든 가게, 카테고리별 조회, 키워드 검색), 메뉴 조회, 리뷰 조회
  • 적용이 되지 않는 기능 : admin과 관련된 기능 (admin은 모든 정보를 한눈에 볼 수 있어야 한다고 생각해서 cursor 기반보다는 offset 기반이 더 좋아보임)