RDBMS 캐싱 필드를 사용한 성능향상

캐싱필드 추가

• 관계형 데이터베이스를 사용하다 보면 다대다 테이블에서, 메인 테이블이 아닌 다른 테이블의 연산 결과를 정렬하거나 조건을 걸어주는 일이 발생합니다.
• 이 경우, 테이블이 커지면 커질수록 연산량이 많아지고 DB에 많은 부하를 가하게 됩니다.
• 이를 해결하기 위한 방법중 하나로, 결과값을 저장하는 필드를 하나 추가해 사용하면 매번 실시간으로 연산을 하지 않아 성능이 크게 향상되는 경우가 많습니다.

• 캐싱 필드를 업데이트해 주는 전략은 아래와 같습니다.
  • Lazy update (지연 업데이트)
    • 필요할 때만 계산하여 업데이트
  • Event-Driven update (이벤트 기반 업데이트)
    • 관련 데이터 변경 시에만 업데이트
  • Scheduled update (스케줄 업데이트)
    • 배치를 걸어놔 정기적으로 일정 시간마다 업데이트

예시) 조회수 캐싱 필드

mysql> select planId, recentViews, totalViews from PlanViews order by totalViews desc limit 10;
+--------+-------------+------------+
| planId | recentViews | totalViews |
+--------+-------------+------------+
|   1469 |           0 |        456 |
|  41054 |           0 |        338 |
|  41061 |           0 |        328 |
|  20443 |           0 |        254 |
|   1288 |           0 |        215 |
|  20691 |           0 |        179 |
|  20693 |           0 |        166 |
|   4029 |           0 |        164 |
|  41317 |           0 |        140 |
|  11505 |           0 |        114 |
+--------+-------------+------------+
10 rows in set (0.01 sec)

• 핸드폰 요금제의 최근 7일, 전체 조회수를 미리 계산해 매 요청마다 연산해야 하는 상황을 피해 성능개선을 할 수 있습니다.
• 조회수 같은 경우 실시간 변동량이 높은 편에 속하니 특정 시간마다 업데이트를 해주는 방향으로 진행했습니다.

예시) 아이템 사은품 합산 점수 캐싱 필드

mysql> select planId, giftScore from Plans order by giftScore desc limit 10;
+--------+-----------+
| planId | giftScore |
+--------+-----------+
|   3584 |        15 |
|   3587 |        15 |
|   3553 |        15 |
|   3585 |        15 |
|   3552 |        15 |
|   3563 |        15 |
|   3603 |        15 |
|   3578 |        15 |
|   3577 |        15 |
|   3568 |        15 |
+--------+-----------+
10 rows in set (0.02 sec)

• 핸드폰 요금제와 연결되어 있는 여러개의 사은품별 점수를 미리 계산해 매 요청마다 연산해야 하는 상황을 피해 성능개선을 할 수 있습니다.
• 사은품이 수정, 추가, 삭제 등 상태값이 변경될 수 있으니 해당 이벤트가 발생할 때 마다 업데이트 하는 방향으로 진행했습니다.
• 사은품별 활성화 되어 있는 시간이 다 다르니 특정 시간마다 추가로 업데이트 하도록 설정했습니다.

• 위와 같은 방법으로 연산량이 많은 작업일 경우 캐싱 필드를 추가해 DB 부하를 줄여 엄청난 성능 향상을 달성할 수 있습니다.