coding tasty house

1. 개요시스템을 운영하면서 요청건수가 쌓이게되어, 단순하게 조회하는 api 부터 시작해서, 요청의 통계등 관리자 사용 api가 점점 느려지는 것이 느껴졌다.우선순위를 낮게 두어 계속 밀렸던 인덱싱을 적용하도록 결정했다.✅ 인덱스란 무엇인가?인덱스는 테이블의 특정 컬럼에 대해 검색 가능한 색인 구조를 만드는 것이다.일반적으로 B-Tree 기반 인덱스가 기본이며, 정렬된 구조로 되어 있어 WHERE, JOIN, ORDER BY 등에서 전체 테이블 스캔을 막는다.왜 인덱스가 성능을 올리는가?전체 테이블을 순회하는 Full Table Scan 보다 빠르게 조회 가능키를 통한 검색 범위 지정이 빨라짐데이터가 많아질수록 효과가 더 커짐다만, insert/update/delete는 오히려 느려질 수 있기때문에 신중..

0. 개요 레거시 db를 정규화 한다이제 운영에 기존 레거시 데이터를 옮기기 위해서는 sql dump가 필요하다구조는 https://gyeong99.tistory.com/139 [레거시 정규화] DB 정규화 하기10. 개요레거시 DB를 보다 보면 이런 테이블을 자주 만난다.“요청에 대한 모든 걸 한 테이블에 다 때려 넣은 구조”문제는 요청 내용 + 요청 메타 정보 + 결재자 정보가 전부 이 테이블에 들어가gyeong99.tistory.com여기서 설명한다 레거시 DB 정규화의 진짜 시간을 쏟은 부분은 기존 REQUEST 테이블 데이터를 새로운 구조로 안전하게 덤프하는 과정이다. 1. DATA dump전제: 레거시 테이블 구조기존 REQUEST 테이블은 이런 형태였다고 가정하자. REQUEST - requ..

0. 개요레거시 DB를 보다 보면 이런 테이블을 자주 만난다.“요청에 대한 모든 걸 한 테이블에 다 때려 넣은 구조”문제는 요청 내용 + 요청 메타 정보 + 결재자 정보가 전부 이 테이블에 들어가 있었다는 점이다.시스템을 새로 개발하면서 레거시 DB에 있는 데이터들을 일부 필요한 부분들은 정규화하여 운영하기로 결정했다 1. 정규화 이전 정규화 이전 : 모든 걸 담고 있던 REQUEST 테이블정규화 전 테이블은 대략 이런 느낌이었다. REQUEST- request_id- request_title- request_content- request_type- request_status- created_at- requester_id- requester_name- requester_dept- approver_id- ..

기존 서비스 운영 중 DB를 업데이트 해야할 때 서비스 진행중에 새로운 서비스를 도입해서 기존의 사용자에게도 적용해야할 때, 조건을 걸고 일괄 수정이 필요할 때가 있다. 이번의 경우에는 id로 group by절을 사용하여 나온 결과의 수를 세고 그 결과대로 컬럼 두개를 업데이트 시켜야 했다 1. UPDATE가 필요한 조건의 대상자 찾기 user의 id로 그룹화 하여 해당 유저가 작성한 글의 수를 센다 select count(*) as CNT, user_id from feedlist group by user_id having CNT>=7; # Feedlist라는 테이블에서 user_id로 그룹화 하고 반환되는 튜플의 수를 세는데, 7개 이상일 때만 나오도록 한다. group에 대한 조건을 세기 위해서는 w..