티스토리

roqkfchqh

검색하기

블로그 홈

roqkfchqh

roqkfchqh.tistory.com/m

구구구..구구....구구구구구...

구독자: 3

방명록 방문하기

주요 글 목록

플러스 프로젝트 KPT 회고 KEEP🥇 소통서로 코드를 확인하며 로직 면에서 아쉬운 부분을 피드백하면 피드백 받은 사람이 적극 수용하고, 의견이 다를 때에는 같이 얘기하면서 조율한 점아이스 브레이킹, 팀원끼리 어색한 시간이 매우 짧아서 바로 활발할 의사소통을 하면서 프로젝트에 돌입할 수 있던 점발표자한테 모든 걸 맡기지 않고 다같이 리허설을 하면서 피드백도 하고 같이 발표 자료도 검토한 점의사소통이 잘 되어서 프로젝트 완성도에 오롯이 집중할 수 있던 점팀원이 힘들 때마다 서로 서로 격려와 응원의 말을 자주 해준 점🥈 기록5분 기록 보드 등등을 활용하여 고민과 규칙과 계획을 꼼꼼하게 기록한 점기술을 하나 사용할 때나 기술적 의사결정을 할 때마다 꼭 근거를 덧붙인 점🥉 협업jira, pull request template을 사용하.. 공감수 1 댓글수 0 2025. 2. 7.
조회 성능 개선 작업 정리본 문제: 조회 성능이 매우 매우 느리다.초기 거래소 조회 속도: 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. 조건에 따른 조회와 검색이 많이 일어나는 항목이므로.. 공감수 2 댓글수 0 2025. 2. 6.
성능 개선 4편 & 트러블슈팅: 커서 기반 페이지네이션 + 전략 패턴 커서 기반 페이지네이션이란?데이터베이스에서 대량의 데이터를 효율적으로 탐색하기 위한 기법이다.커서 기반 페이지네이션은 특정 커서(정렬된 컬럼의 마지막 id값)를 기준으로 다음 데이터를 가져와서 인덱스를 탈 수 있어 성능 저하 없이 빠르게 데이터를 불러올 수 있다.기존 오프셋 기반 페이지네이션에서 오프셋이 커질수록 발생하는 성능 저하 문제나 데이터 중복/누락 문제를 효과적으로 방지할 수 있다. 물론 단점도 존재한다. 임의의 페이지로 바로 이동하기 어렵다는 점이다. 페이지 번호 대신 마지막 데이터의 커서를 사용하기 때문에, 사용자가 특정 페이지를 지정해서 바로 접근하는 기능을 구현하기 힘들다. 또 다른 단점은 구현 복잡도가 증가한다는 점이다. 정렬 기준이나 필터 조건이 다양해지면 커서를 통한 데이터 조회가 .. 공감수 3 댓글수 0 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.. 공감수 1 댓글수 0 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내역까지 풀스캔 해야 해서 엄청나게 오래걸리다 못해 컴퓨터가 조회하기를 포기중이다... 인덱스 스코프 정하기.. 공감수 3 댓글수 0 2025. 2. 4.
성능 개선 1편: db조회 성능 개선 플랜 수립 목표거래소와 경매장의 인기 아이템 조회는 상당히 많이 일어나기에 caching이 필수적이라고 생각한다.인기아이템 뿐만아니라, 경매장에서1. "마감 시간이 임박한 경매 목록"2. "현재 입찰가가 가장 높은 항목"에 대해서도 조회가 굉장히 많이 일어난다. 하지만 해당 캐싱 전략을 수립하거나 멀티인스턴스에서 접근하기 전에우선 인덱스 등을 이용하여 순수 조회 성능부터 개선해야 한다. 따라서,1. 인덱스를 통한 db 조회성능 개선2. 커서 기반 페이지네이션 적용3. 풀텍스트 인덱스 적용3. DB vs Redis순으로 진행한다. 테스트 조건, 환경 수립제일 정하기 어렵다. 실제 게임이라고 생각해보면, 과연 얼마나 있을까.. 하던 게임에서 한번 찾아보자.원정대(계정) 65만개아이템 개수 1315 x 10 = 131.. 공감수 1 댓글수 0 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)), .. 공감수 2 댓글수 0 2025. 2. 2.

문의안내

티스토리
로그인
고객센터

티스토리는 카카오에서 사랑을 담아 만듭니다.