주말에 개발 관련 공부를 하고 있었는데, 팀 슬랙에 팀원 분의 개발 현황이 올라왔다.
내가 경험해 본 페이징 전략 중에 Cursor 기반의 페이징 전략을 프로젝트에 적용 시키면 좋겠다는 생각이 들어 의견을 제안해봤다.
- 왜 Cursor 기반? : 페이징 기능을 구현할 때 가장 흔하게 접하는 전략은 Offset 기반이다. Offset 기반의 페이징은 구현하기는 쉽지만, 데이터가 많아질수록 성능이 저하된다는 단점이 있다. (주말에 정리해 본 글 - offset 기반 vs cursor 기반) 또한, 주문 플랫폼의 서비스 특성을 생각해 보았을 때, 사용자의 입장에서는 모든 음식점을 알기보다는 자신이 선호하는 음식점을 보고 싶을 것이다. 따라서, Cursor 기반으로 구현하는 것을 시도해 봐도 좋을 것 같았다.
다행히도, 긍정적으로 생각해주시는 것 같았다!
이제 개발을 해볼까~ 하며 개발 요구 사항을 보다가 문득 생각이 들어 또 생각을 올려보았다.
역시 팀원분이 의견을 달아주셨다..!
이번 PK와 관련한 논의는 팀원분의 의견을 들어보면서 배우게 되는 게 있어서 좋았다. (클러스터링 인덱스, DB가 변경에도 괜찮음)
이렇게 의견 교환을 하니 생각을 제시한 사람도, 같이 생각을 교환한 사람도 같이 공부가 된 것 같아 좋았다.
역시 의견 교환을 할 수 있는 사람들이 있으니 생각이 잘 정리되는 것 같다.
월요일에 다른 팀원분들과 논의를 해보기 위해 정리를 해서 이슈로 올려주셨다.
궁금한가? 이슈 링크
궁금한가? 이슈 링크
그리고 11/11 오늘! 오전에 다같이 모여서 위의 2가지 안건에 대해 다같이 지식을 공유하며 의견 교환을 했다. (거의 2시간 가량 생각을 주고 받았다...)
+) 공부한 내용 : 나중에 더 자세히 공부해서 글로 올릴 거다.
클러스터링 인덱스 : 데이터베이스에서 테이블의 데이터가 실제로 저장되는 순서를 기준으로 정렬된 인덱스
클러스터링 인덱스는 테이블의 데이터를 물리적인 순서대로 정렬하여 저장하게 되며, 데이터의 저장 방식 자체가 인덱스의 구조와 일치하도록 하는 인덱스이다.
클러스터링 인덱스를 통해 데이터가 정렬되어 있기 때문에 테이블의 검색 속도가 높아지지만, 삽입, 삭제, 수정이 빈번한 테이블에서는 성능 저하가 발생할 수 있다.
주말부터해서 오늘까지 굉장히 열띤 토론이 있었다. (같이 의견을 내주시며 고민해 주신 팀원분들 감사합니다...🥸)
결정된 사안
- 페이지네이션 : Cursor 기반 도입은 긍정적, 하지만 cursor로 사용될 key 값의 선정 문제로 인해 아직은 보류(좀 더 생각해보기로..)
- pk 변경 : pk는 varchar 타입의 uuid에서 bigint 타입의 auto_increment로 변경!
이게 팀플을 하는 이유가 아닐까 다시 생각해보는 계기가 되었다.
'💻 개발 > 주문 플랫폼' 카테고리의 다른 글
11/14 - TIL : POSTMAN 로그인 설정하기 (0) | 2024.11.14 |
---|---|
11/13 - TIL - Sub Query와 Join (2) | 2024.11.13 |
11/12 - TIL : git merge와 rebase, 반정규화 (0) | 2024.11.12 |
페이지네이션 방식 - offset 기반과 cursor 기반 (0) | 2024.11.10 |
DB PK 전략 - UUID를 PK로..? (0) | 2024.11.08 |