전체 글 썸네일형 리스트형 MySQL 성능 개선 프로젝트 13 현재 진행중인 프로젝트는 마켓컬리, 쿠팡프레시 등을 벤치마킹한 주문 배송 시스템이다.그 중 규모가 더 작은 마켓컬리도 하루에 약 10만 건의 주문이 처리된다고 한다.그렇다면 설계한 배송 주문 테이블에 하루에 10만 건의 데이터가 쌓일것이고, 많은 데이터가 쌓이게 될 것이다.그래서 데이터를 옮겨주는 아카이빙 기능을 구현하는데, 생각보다 많은 쿼리가 실행되어야 한다.우선 배송 주문만 옮겨주는게 아니라 해당 데이터의 키값을 외래키로 가지고 있는 모든 테이블들의 데이터를 먼저 처리해 주어야 한다.그 중 배송 로그만 옮긴다고 했을 때, 옮기는 과정은 다음과 같다.1.일정기간이 지난 배송 주문 데이터를 아카이빙 테이블에 입력하는 프로시저 실행2.옮겨진 데이터들의 키값을 외래키로 가지는 배송 로그 삭제3.배송 주문 .. 더보기 MySQL 성능 개선 프로젝트 12 2024.09.19 - [분류 전체보기] - MySQL 성능 개선 프로젝트 9 MySQL 성능 개선 프로젝트 9배송 주문 테이블의 경우 다음과 같이 데이터가 입력되고 있다. is_complete 컬럼을 통해 해당 배송 주문이 완료되었는지 확인 하며, 완료된 배송 주문은 기사에게 할당되지 않는다.하지만 시간이yis0707.tistory.com 지난 글에서 배송 기사 실적에 대한 빠른 조회를 위해 완료된 배송 주문 데이터를 실시간으로 다른 테이블로 옮기는 방법을 택했었다. 하지만 이 경우 몇 가지 문제가 발생할 수 있다.첫 번째는 잘못된 주문이 배송 완료 처리 되었을 때이다. 배송은 배송 기사가 배송을 끝낸 후 서명이나 증빙 사진을 입력할 경우 완료 처리된다. 이 때 배송 기사가 잘못된 입력을 통해 다른 배.. 더보기 MySQL 성능 개선 프로젝트 11 내가 이번 성능 개선 프로젝트에서 가장 중심적으로 개선 중인 사항은 트리거와 프로시저인데, 어떤 한 기능을 트리거로 구현하느냐 프로시저로 구현하느냐이다. 배송 주문이 생성되는 과정을 예로 들면,주문 상태가 '상품 준비중' 으로 변경됨 -> 주문에 기사가 할당되며 배송 주문 생성 -> 고객과 기사 채팅 채널 생성 -> 배송보험 가입 다음과 같이 프로세스가 진행된다. 처음에는 이 과정을 주문 테이블에 트리거를 걸어서 주문 상태가 '상품 준비 중'으로 변경되었을 때 순차적으로 실행되도록 쿼리를 작성했다.하지만 트리거에 대해 알아보면서 '복잡한 쿼리는 트리거가 아닌 프로시저로 실행시키는게 좋다.'는 정보를 찾을 수 있었다. 그 이유에 대해서 단순히 '복잡한 트리거는 트랜잭션 관리도 어려울뿐더러 안정성을 해친다... 더보기 MySQL 성능 개선 프로젝트 10 프로젝트 중 배송상태가 변경되면 배송 주문이 자동으로 할당되는 기능을 테스트 하던 중이었다.1000건의 배송 상태 변경에 따른 배송 주문 할당, 채팅 채널 생성, 배송 보험 가입의 프로시저의 시간을 비교하던 중,자꾸 중복된 데이터가 입력되는것을 확인했다.배송 주문 테이블에 데이터가 생성되면 SET selected_dv_order_id = last_insert_id(); 해당 변수에 방금 생성된 데이터의 ID값을 넣고 그걸 참조해서 채팅 채널과 배송 보험을 생성하는 방식이었다.모든 데이터가 중복으로 입력되는 것이 아니라 가끔 한번씩 정해진 데이터들만 중복으로 입력됐고,도무지 공통점을 찾을 수 없었다.그래서 해당 부분들을 트리거로 바꿔보니 또 중복된 데이터가 입력되지 않는것이었다.동시성의 문제인가 싶어 트랜.. 더보기 MySQL 성능 개선 프로젝트 9 배송 주문 테이블의 경우 다음과 같이 데이터가 입력되고 있다. is_complete 컬럼을 통해 해당 배송 주문이 완료되었는지 확인 하며, 완료된 배송 주문은 기사에게 할당되지 않는다.하지만 시간이 지나 수많은 데이터가 이 테이블에 쌓이면 어떻게 될까아마 해당 테이블을 조회하는 쿼리가 포함된 기능의 성능이 느려질 것이다. 해당 VIEW 테이블은 배송 기사의 실적을 관리하는 테이블로,총 배송 건수를 조회하기 위해 집계함수(count)를 사용하며, 이 경우 테이블의 전체 데이터를 조회한다.delivery_order 테이블에 약 10만건의 데이터가 있을 때 해당 VIEW 테이블을 조회하면 약 0.8초의 시간이 걸린다. delivery_order 테이블에 20만건의 데이터를 추가한 후 20만건의 데이터가 있.. 더보기 MySQL 성능 개선 프로젝트 8 배송 주문 할당 프로세스를 트리거에서 프로시저로 바꾸면서 생각보다 성능이 느리다는것을 확인했다.그래서 프로시저의 기능을 조금 추려냈고 트리거와 연계하는 방식으로 설계를하면 시간이 단축이 될지 실험해 보았다. delimiter //DROP PROCEDURE if exists INSERT_processing;CREATE PROCEDURE insert_processing(pm_order_id bigint)BEGIN DECLARE selected_storage_id BIGINT; DECLARE selected_delivery_type VARCHAR(255); DECLARE selected_worker_id BIGINT; DECLARE selected_dv_order_id BIGINT; DECLARE select.. 더보기 MySQL 성능 개선 프로젝트 7 배송이 완료될 경우 고객은 해당 배송 기사에 대해 리뷰를 작성할 수 있다.그리고 해당 리뷰를 바탕으로 관리자가 배송 기사의 실적을 확인할 수 있는 기능이 필요하다.고려한 선택지는 세 가지였는데,첫 번째는 실적을 입력하는 테이블을 새로 만드는 것이다.컬럼으로는 배송기사의 id, 평균 평점, 노동 시간, 총 건수가 있는데 이를 최신화 시켜주기 위해서는 배송 리뷰가 입력될 때마다 트리거를 이용해 반영하기, 이벤트 스케쥴러를 이용해 특정한 시간마다 갱신하기 두가지 방법이 있을것이다.이 방법의 장점은 테이블 조회만 하면 되므로 매우 간단하고, 빠르다는 것이다. 하지만 최신화를 위해 트리거를 이용한다면 리뷰가 많이 생성될 때 성능저하가 우려되고, 이벤트 스케쥴러를 사용한다면 실시간으로 결과가 반영되지 않을것이다. .. 더보기 MySQL 성능 개선 프로젝트 6 더미데이터 배송 기사 50만건, 주문 50만건을 넣은 후 1000건의 업데이트가 발생했다고 가정, 1000건의 프로시저 실행 delimiter //DROP PROCEDURE if EXISTS update_status;CREATE PROCEDURE `update_status`( IN `from_id` BIGINT, IN `to_id` bigint) BEGIN DECLARE current_id BIGINT DEFAULT from_id; while current_id 테스트는 다음과 같은 프로시저를 이용했다. 실행결과 35초가 걸렸다. 추가로 SELECT문의 인덱스를 추가했다. 그리고 다시 실행한 결과 26초로 단축시킬 수 있었다. 더보기 이전 1 2 3 4 ··· 10 다음
