조회 성능 개선 작업 정리본 문제: 조회 성능이 매우 매우 느리다.초기 거래소 조회 속도: 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. 조건에 따른 조회와 검색이 많이 일어나는 항목이므로.. 2025. 2. 6. 조회성능 개선 마무리(저장용 글) 쿼리 성능 개선 과정 결과물트레이드카운트를 지우거나, onsale로직을 또 고칠 순 없어서 그냥동일하게 진행. 처음 완전 성능 개선 전거는 그냥 첫 게시글에서 쓰면 됨explain analyze와 포스트맨의 괴리감이 너무 커서(analyze엔 8초인데 포스트맨은 측정불가 수준으로도 나옴) 포스트맨의 결과만 믿기로 함 메인 마켓 : 커서 기반 +CREATE INDEX idx_market_status_item ON market (status, item_id, amount, price);채택이후 인기 마켓에서 created_at도 필요해서#인기마켓CREATE INDEX idx_market_status_created_item ON market (status, created_at, item_id, amount, .. 2025. 2. 6. 성능 개선 4편 & 트러블슈팅: 커서 기반 페이지네이션 + 전략 패턴 커서 기반 페이지네이션이란?데이터베이스에서 대량의 데이터를 효율적으로 탐색하기 위한 기법이다.커서 기반 페이지네이션은 특정 커서(정렬된 컬럼의 마지막 id값)를 기준으로 다음 데이터를 가져와서 인덱스를 탈 수 있어 성능 저하 없이 빠르게 데이터를 불러올 수 있다.기존 오프셋 기반 페이지네이션에서 오프셋이 커질수록 발생하는 성능 저하 문제나 데이터 중복/누락 문제를 효과적으로 방지할 수 있다. 물론 단점도 존재한다. 임의의 페이지로 바로 이동하기 어렵다는 점이다. 페이지 번호 대신 마지막 데이터의 커서를 사용하기 때문에, 사용자가 특정 페이지를 지정해서 바로 접근하는 기능을 구현하기 힘들다. 또 다른 단점은 구현 복잡도가 증가한다는 점이다. 정렬 기준이나 필터 조건이 다양해지면 커서를 통한 데이터 조회가 .. 2025. 2. 5. 성능 개선 3편: Index 적용하고 비교분석하기 2025.02.03 - [팀 프로젝트/플러스 프로젝트] - 성능 개선 2편: Index 설계하기 (with Explain analyze, Explain) 성능 개선 2편: Index 설계하기 (with Explain analyze, Explain)인덱스 없이 조회, 얼마나 걸릴까?개선이 시급한 쿼리는 거래소/경매장 | 전체조회/인기아이템 이렇게 4개다.총 4개 쿼리의 실행속도를 우선 알아보자.hibernate 2차캐시는 사용하지 않고 있다.(defauroqkfchqh.tistory.com해당 글에서 이어집니다.요약하면 인덱스는 총 5개를 걸고,(bidderCount, trade createdAt, market/auction status-createdAt 복합인덱스, tradeCount)집계용 테이블(tr.. 2025. 2. 4. 성능 개선 2편: Index 설계하기 (with Explain analyze, Explain) 인덱스 없이 조회, 얼마나 걸릴까?개선이 시급한 쿼리는 거래소/경매장 | 전체조회/인기아이템 이렇게 4개다.총 4개 쿼리의 실행속도를 우선 알아보자.hibernate 2차캐시는 사용하지 않고 있다.(default설정으로 사용 중)거래소 메인페이지 /markets/main : 36초, 40초경매장 메인페이지 /auctions/main : 21초, 25초 거래소 인기아이템 /markets/populars : 6시에 보낸 요청이 6시 31분까지 조회되지 않는다.경매장 인기아이템 /auctions/populars : 1분 30초, 1분 38초거래소 인기아이템에 대한 조회는 해당 거래소 아이템의 trade내역까지 풀스캔 해야 해서 엄청나게 오래걸리다 못해 컴퓨터가 조회하기를 포기중이다... 인덱스 스코프 정하기.. 2025. 2. 4. 성능 개선 1편: db조회 성능 개선 플랜 수립 목표거래소와 경매장의 인기 아이템 조회는 상당히 많이 일어나기에 caching이 필수적이라고 생각한다.인기아이템 뿐만아니라, 경매장에서1. "마감 시간이 임박한 경매 목록"2. "현재 입찰가가 가장 높은 항목"에 대해서도 조회가 굉장히 많이 일어난다. 하지만 해당 캐싱 전략을 수립하거나 멀티인스턴스에서 접근하기 전에우선 인덱스 등을 이용하여 순수 조회 성능부터 개선해야 한다. 따라서,1. 인덱스를 통한 db 조회성능 개선2. 커서 기반 페이지네이션 적용3. 풀텍스트 인덱스 적용3. DB vs Redis순으로 진행한다. 테스트 조건, 환경 수립제일 정하기 어렵다. 실제 게임이라고 생각해보면, 과연 얼마나 있을까.. 하던 게임에서 한번 찾아보자.원정대(계정) 65만개아이템 개수 1315 x 10 = 131.. 2025. 2. 3. 트러블슈팅: queryDSL 중복집계, 비정상적으로 큰 count 문제(with only_full_group_by) MySQL의 ONLY_FULL_GROUP_BY모드와(디폴트 설정),JPA/QueryDSL에서 아이템별 집계를 구현할 때 발생한 문제(groupby 중복 행, count 합계 뻥튀기)해결 과정을 정리한 문서입니다. 1. 문제 상황JPQLQuery query = queryFactory .select(new QMarketListResponseDto( market.item.id, market.item.name, JPAExpressions .select(market.amount.sum().coalesce(0)) .from(market) .where(market.item.id.eq(item.id)), .. 2025. 2. 2. 이전 1 다음
