DB 느릴 때

1 개요

DB 느릴 때

RDB 느릴 때

항목	애플리케이션 변경	인프라 구성 변경
1. 느린 쿼리 및 DB 테이블 확인 ★★★ 가능한 경우, 실행계획까지 확인하면 더욱 좋다. (쿼리 내부에서 어디가 병목인지 확인) 쓰기가 느린가? 읽기가 느린가? 인덱스(PK, UNIQUE, INDEX)가 적절히 설정되었는가? JOIN 관계는 적절한가? 불필요하게 많은 테이블을 JOIN하고 있지는 않은가? FULL JOIN을 LEFT JOIN으로 바꿔볼 수는 없는가? 너무 많은 컬럼/행 테이블에 너무 많은 컬럼이 있는 것은 아닌가? 너무 많은 컬럼을 SELECT 하고 있는 것은 아닌가? 너무 많은 행을 가진 테이블은 없는가? 여러 테이블/DB로 분산해보면 어떨까? 예: 샤딩 자주 조회되는 간단한 요약 정보가 있다면 요약 테이블을 따로 만들어보면 어떨까? 게으른 처리 실시간 갱신이 필요한 것이 아니라면, 다른 곳에 쌓아놨다가 야간(어쨌든 바쁘지 않은 시간)에 처리할 수는 없을까? N+1 문제? 혹시 ORM을 사용한다면 N+1 문제가 없는지 살펴보자.	3️⃣	0️⃣
2. DB 상태 확인 및 튜닝 DB 상태를 확인하고 설정(DB 파라미터)이 적절한지 검토한다. 적절한 크기의 DB 캐시 설정은 매우 중요하다. OS의 메모리 크기와, DB에 할당한 메모리의 크기, DB 캐시의 크기는 적절한가? 필요시 advisory 도구를 활용해볼 수도 있다.	0️⃣	0️⃣
3. DB 구성 확인 및 개선 수평 확장 - 1대라면 Replication이나 Clustering 구성으로 2~3대로 늘려보면 어떨까? 수직 확장 - CPU나 메모리 사용률이 높다면 해당 리소스를 높여보면 어떨까?	수평 확장(1️⃣~2️⃣) 수직 확장 0️⃣	수평 확장(3️⃣) 수직 확장 0️⃣
4. DB 캐시 구성 Redis/Memcached 등으로 캐시를 적용해보면 어떨까? 자주 조회되지만 변경은 별로 없고, 쿼리 결과물의 크기는 큰 경우(특히 여러 테이블 JOIN), 효과가 좋을 수 있다.	1️⃣~2️⃣	1️⃣
5. 기타 어쨌거나 앞단에서 DB Hit를 줄일 수 없는가? DB 내용 중 일부를 다른 DB, object storage로 분산 webcache 도입 (애플리케이션 특성에 따라 DB Hit 줄이는 효과가 별로 없을 수도 있다.) 다른 DB 추가 도입 특정 컬럼에 매우 긴 글(text)가 있고, 부분문자열 검색(LIKE %%)을 자주 하는 경우하는 경우 → 해당 테이블을 Elasticsearch에 복제하여 검색하는 방법 검토	1️⃣	2️⃣

2 같이 보기

• 웹 느릴 때