pile·
DB / 데이터·토니모리토니모리·

토니모리 공식몰 API 응답시간 2차 개선기 (SQL 실행계획 최적화 및 index)

문제토니모리 공식몰 API에서 구매 내역 COUNT(*) 호출과 리뷰 썸네일 다중 조건 조회가 풀스캔과 ROW_NUMBER 부하로 300~400ms대 응답을 만들고 있었다.
접근구매 여부 체크는 COUNT 대신 첫 매칭에서 끝나는 EXISTS로 바꾸고, THUMBNAIL_DATA·PRODUCT_REVIEW_DATA에 가로 크기·삭제 여부·썸네일 타입을 묶은 복합 인덱스를 얹어 인덱스 범위 스캔으로 필터링 단계를 앞당겼다.
결과구매 내역 조회는 80ms대에서 30ms대로 약 20%, 리뷰 썸네일 조회는 350ms대에서 100~180ms대로 50% 이상 단축됐고 CPU 비용도 22,203에서 7,271로 약 3배 줄었다.
토니모리
토니모리 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)
·takedown 요청

이 글과 비슷한

  1. DB / 데이터·pinterest-engPinterest Engineering·

    Pinterest 차세대 DB 수집 프레임워크의 자동화된 스키마 진화

    Pinterest의 CDC 기반 DB 수집 파이프라인은 MySQL에서 Kafka, Flink, Spark, Iceberg를 거치는 다층 구조다. 스키마 변경이 생기면 모든 계층을 동시에 업데이트해야 해 드리프트, 배포 실패, 데이터 불일치가 반복됐다. Pinterest 엔지니어링 팀은 이를 해결하기 위해 가산적 변경만 자동화하는 스키마 진화 프레임워크를 구축하고, PR 기반 롤아웃과 SLA 기반 일관성 모델을 도입했다.

    #data-pipeline#apache-flink#cdc+2