본문 바로가기
팀 프로젝트/플러스 프로젝트

조회 성능 개선 작업 정리본

by pon9 2025. 2. 6.

문제: 조회 성능이 매우 매우 느리다.

초기 거래소 조회 속도: 36.8초

1차 개선 후: 24.17초

개선내용:

1. tradeCount 집계테이블 생성

2. tradeCount테이블의 count에 인덱스 생성(asc)

3. 마켓status와 createdAt 복합인덱스 생성

4. trade에 createdAt 인덱스 생성(desc)

 

문제점: 인덱스가 너무 많고, trade에 인덱스가 걸려있어 삽입 시 오버헤드 우려됨. trade는 삽입이 활발히 일어나는 항목이므로 해당 부분에 대한 개선 필요했음

커서기반 페이지네이션 적용 후: 3.6초

개선내용:

1. 커서 기반 페이지네이션 적용

2. 정렬 전략 별로 다른 cursor 사용, tie-breaker로 itemId 사용

3. 조건에 따른 조회와 검색이 많이 일어나는 항목이므로, (status,createdAt, itemId, amount, price) 복합 인덱스 생성. 이전처럼 인덱스를 많이 사용하기보다 하나의 인덱스로 성능을 개선함.

 

문제점: market 삽입 시 오버헤드를 고려할 필요가 있으나, trade보단 빈도가 덜할 것이기에 상대적으로 괜찮다고 판단함.

풀텍스트 인덱스 적용 후: 39ms

개선내용: CustomFunctionContributor 이용하여 풀텍스트 인덱스 적용

 

caching

튜닝을 마치지 못한 느린 쿼리(거래소 인기내역): 26.7초

 

문제점: cursor와 tie-breaker를 넣어주면 그나마 속도가 빠르지만, 인기 내역 첫 로드 시 조회속도가 매우 느림. 원인 찾지 못하였고, 이후 생각날 때 마다 개선 예정.

해결(임시방편): redis 캐싱을 이용하여 성능 향상. 어차피 인기 내역은 변동성이 적기 때문에 TTL을 꽤 길게 가져감.

DB 부하 감소: 느린 쿼리로 인한 DB 트래픽 줄여줌

redis insight에 캐시가 저장되어있는 모습