프로젝트

개요이전 포스팅에서 현재 구현된 API의 문제점에 대해서 분석했습니다. 이번 포스팅에서는 오프셋 기반 페이지네이션으로 구현된 로직을 커서 기반 페이지네이션으로 바꾸고 그 과정에서 나오는 문제점, 나아진 점 등을 살펴보도록 하겠습니다. SQL 작성현재 커서 기반 페이지네이션을 구현하려면 크게 두가지 정보를 클라이언트에게 요구해야 합니다. 1. cursor 데이터2. 요청 파라미터 커서(기준)가 될 데이터를 받아온 후 어느 데이터로 정렬을 할지 요청 인자값을 받아와야 합니다. 정렬 기준은 다음과 같습니다. - 경매 시작일- 경매 종료일- 최고 입찰가- 상한가 unique한 값으로 페이지네이션을 구현하는 것은 쿼리도 간단하고 구현도 복잡하지 않습니다. 중복이 없으니까요. 하지만, 경매 데이터에서 정렬이 될 필..

개요경매 글 목록을 불러오는 api의 구조를 개선하여 목표하는 성능까지 올려보는 과정을 기록하고자 해당 시리즈를 작성하기로 하였습니다. 본론에 앞서서 해당 프로젝트의 더미 데이터로 유저 약 100만, 기프티콘 개수 약 2천만, 경매 글 개수 약 100만 개를 생성해놓은 상태입니다. 문제 인식부하 테스트를 하기 전, postman으로 먼저 간단하게 응답 시간이 얼마나 걸리는지 테스트 해봤습니다. 응답 시간이 매우 느립니다.. 네 이건 뭐 부하테스트를 할 필요도 없이 먼저 해당 API의 문제를 살펴보는 것이 좋을 것 같다는 판단을 했습니다. 전체적인 로직을 파악해본 결과 문제는 아래 부분 정도로 정의했습니다. 1. 페이지네이션 오프셋 성능 저하 문제2. N + 1 문제3. queryDSL 에서 cross j..