2024.07.12
🔥오늘의 공부🔥
● 1. ㅇㅇㅇㅇ
최적화
주어진 자원(시간, 하드웨어 등)과 같은 제약조건 내에서 최선의 결과(속도 향상, 비용 감소 등)을 도출하기 위해 전체 시스템 또는 코드 구조를 재설계하거나 개선하는 과정을 최적화라고 칭한며, 특정 부분의 성능을 개선하여 전체 성능을 향상하는 것을 목표로 한다. 정리하면 최소한의 자원을 이용해 성능을 향상 시킨다는 것을 최적화라고 칭한다.
최적화 전략
1. 성능 측정 : 최적화 전후의 성능을 객관적으로 측정하고 비교합니다.
2. 점진적 적용 : 한 번에 많은 변경을 하기보다는 단계적으로 최적화를 진행합니다.
3. 모니터링 : 최적화 후 시스템의 전반적인 성능과 안정성을 지속적으로 모니터링 합니다.
4. trade-off 고려 : 성능 향상과 코드 복잡도, 유지보수성 간의 균형을 유지합니다.
최적화 절차
분석(측정) -> 설계 -> 구현 -> 검증을 반복하며 유의미한 결과(수치)에 근접한 결과를 도출합니다.
쿼리 최적화
쿼리 최적화 또한, 최적화와 같은 개념을 이용해 DB의 쿼리를 최적화하여 속도 향상과 비용 감소를 도출하는 과정을 의미한다. SQL을 최적화하는 이유는 Query 성능을 끌어올리기 위함이 우선이지만 DB 사용 비용은 WAS 사용 비용보다 비싸기 때문에 쿼리 최적화는 중요시 된다. DB증축 및 관리 비용보다 WAS 증축 및 관리 비용이 더욱 값이 나간다.
1. 사례
index(색인) 생성 : value로 탐색하는 것이 아닌 index(색인)으로 탐색하여 속도를 높인다.
Sub-Query : 불필요한 Sub_Query를 튜닝하면서 속도를 높인다.
No-Offset Pagination : full range scan 후 n개를 절삭하면서 출력 갯수를 줄이며 속도를 높인다.
반정규화 : 정규화된 테이블로인한 성능 저하 시 중복되는 데이터를 허용함으로써 join비용을 절감하여 속도를 높인다.
Index
인덱스는 데이터베이스에 저장된 테이블 레코드를 빠르게 탐색하기 위한 자료구조를 말한다.
( 레코드를 빠르게 탐색할 수 있는 이유는 미리 정렬이 되어있기 때문이다!! )
데이터 자체가 정렬이 되어 읽기에는 빠르지만, 반면에 쓰기(생성, 삭제, 수정)가 일어날 경우라면 재정렬을 하거나 인덱스를 추가해주는 작업이 필요하기 때문에 오히려 성능이 떨어질 수 있다는 문제점이 있다.
정리 : 무조건적인 인덱스 생성 보다는 SQL문을 효율적으로 작성 한후 인덱스 사용을 고려하는것이 좋다.
index의 적용 기준
1. 활용도가 높을 수록 적합하다. ( 해당 테이블의 데이터를 활용하는 활용도를 의미한다. )
2. 카디널리티(Cardinality)의 정도가 높을 수록 적합하다. ( 중복되지 않는 값을 의미한다. )
3. ETC
* 반대로 활용도가 낮거나, 카디널리티의 정도가 낮을 수록 index를 사용하는 것은 적합하지 않을 수 있다.
- 주로 단일 인덱스보단, 복합 인덱스를 많이 사용한다. ( 컬럼 두 개 이상을 묶어서 인덱싱하는 것을 의미한다. )
카디널리티
중복이 되지 않는 값을 의미한다.
ex) pk 컬럼 => 100개의 데이터가 존재할 때 PK는 중복이 불가능하므로 카디널리티 값은 100개 이다.
ex2) name 컬럼 => 100개의 데이터가 존재할 때 이름은 중복이 안 될 확률이 높기 때문에 확률로 계산 해볼때 80개 정도임
실행 절차
명확히 쿼리 성능이 떨어질 때 어떻게 튜닝을 하는 것이 좋은지 분석하기 위해 우리는 실행 절차를 확인해 볼 필요가 있다.
1. Parser
쿼리 문장을 쪼개서 MySQL이 이해할 수 있도록 세분화하여 tree로 만든다.
2. Resolver
쪼개진 문장을 체크한다.
3. Optimizer
tree를 탐색하며 무슨 테이블들 읽을지, 조건은 무엇인지, 어떤 인덱스를 사용할지 혹은 사용하지 않을지 선별하여 최적화 시킨 후 실행 계획을 만든다.
4. Query execution
최적화된 실행 계획을 기반으로 스토리지 엔진으로부터 데이터를 가져온다.
데이터 검색
쿼리 조회 시 가장 우선시 해야하는 것은 탐색 데이터 범위를 줄이는 것입니다.
Full Table Scan
데이터베이스가 테이블의 모든 행을 순차적으로 읽는 방법이며, index를 사용하지 않으며, 테이블의 모든 데이터를 확인해야 함으로 매우 비효율적이다.
ex) SELECT * FROM BOARD;
Full Index Scan
인덱스의 모든 엔트리를 순차적으로 읽는 방법입니다. 테이블 전체를 읽는 것보다 빠를 수 있지만, 인덱스의 모든 항목을 읽어야 하기 떄문에 비효율적이다.
ex)
Full Range Scan
인덱스의 특정 범위 내에 있는 엔트리만 읽는 방법입니다. 인덱스를 활용하여 필요한 데이터만 읽기 때문에 효율적이다.
Index Unique Scan
고유 인덱스를 사용하여 하나의 특정 행을 검색하는 방법으로, 매우 효율적이며 unique 인덱스가 있는 경우 사용이 된다.
Index Range Scan
인덱스를 사용하여 특정 범위 내의 데이터를 검색하는 방법으로, Full Range Scan과 유사하지만, 인덱스를 사용하여 보다 효율적이다.
엔티티 클래스의 @Table => option에 index에 컬럼이름을 넣을 수 있다.
회고
쿼리 최적화에 대해 배웠다 영상 마저 보고 수정해야함.
'내일배움캠프 Spring 5기' 카테고리의 다른 글
EduWithMe-Project (0) | 2024.09.03 |
---|---|
내일배움캠프 62일차 TIL - JPA(CascadeType, OrphanRemoval) (0) | 2024.07.16 |
내일배움캠프 60일차 TIL - Security 예외처리 (0) | 2024.07.13 |
내일배움캠프 59일차 TIL - 심화 프로젝트 설계 (0) | 2024.07.10 |
내일배움캠프 58일차 TIL - Redis (0) | 2024.07.09 |