캐시 관리

CoreRx는 모든 KPI 계산을 PostgreSQL DB Function으로 사전 수행하여 캐시 테이블에 저장합니다. 대시보드(BI 도구)는 캐시 테이블만 조회하므로, 캐시 갱신 전략이 데이터 정합성과 대시보드 성능의 핵심입니다.

캐시 아키텍처

원칙

• 원본 테이블 직접 조회 금지: 대시보드는 반드시 corerx_cache_* 캐시 테이블만 조회합니다.
• DB Function으로 집계: 모든 KPI 계산은 PostgreSQL Function에서 수행합니다.
• TRUNCATE + INSERT 패턴: 각 캐시 함수는 기존 데이터를 삭제하고 새로 계산된 결과를 삽입합니다.

캐시 테이블 목록

refresh_all_kpi_cache()

전체 캐시를 일괄 갱신하는 마스터 함수입니다.

실행 방식

내부적으로 5개의 개별 캐시 갱신 함수를 순차 실행합니다:

1. refresh_cache_sales_monthly(company_id) — 월별 매출 캐시
2. refresh_cache_product_ranking(company_id) — 제품 순위 캐시
3. refresh_cache_account_summary(company_id) — 거래처 요약 캐시
4. refresh_cache_market_share(company_id) — 시장점유율 캐시
5. refresh_cache_cso_status(company_id) — CSO 성과 캐시

각 함수 완료 시 corerx_cache_meta 테이블에 상태가 기록됩니다.

수동 실행

Superset SQL Lab 또는 psql에서 직접 실행할 수 있습니다.

SELECT refresh_all_kpi_cache(
  '4b5b1d04-23f6-42a7-9fe5-acb0a9998c55',
  'manual'
);

개별 캐시만 갱신

특정 캐시만 갱신해야 하는 경우 개별 함수를 직접 호출합니다.

-- 시장점유율 캐시만 갱신 (UBIST 데이터 업데이트 후)
SELECT refresh_cache_market_share(
  '4b5b1d04-23f6-42a7-9fe5-acb0a9998c55'
);

갱신 주기와 트리거

자동 갱신

수동 갱신이 필요한 경우

성능 고려사항

갱신 소요 시간

캐시 갱신 시간은 데이터 양에 비례합니다.

갱신 중 대시보드 동작

• TRUNCATE + INSERT 패턴이므로, 갱신 진행 중 대시보드를 조회하면 일시적으로 데이터가 비어 보일 수 있습니다.
• 갱신 중에는 corerx_cache_meta의 상태가 running으로 표시됩니다.
• 사용자가 적은 시간대(업무 시작 전, 점심시간 등)에 갱신을 실행하는 것을 권장합니다.

메모리 사용량

DB Function은 서버 사이드에서 실행되므로, PostgreSQL의 work_mem 설정이 충분해야 합니다. UBIST 데이터가 대용량(11만 행)이므로 market_share 캐시 갱신 시 메모리 사용량이 높아질 수 있습니다.

주의: 캐시 갱신이 반복적으로 실패하면 PostgreSQL 로그를 확인하세요. 메모리 부족이 원인인 경우 work_mem 값을 조정해야 합니다.

캐시 메타 테이블

corerx_cache_meta 테이블은 각 캐시의 갱신 이력을 기록합니다.

모니터링

데이터 관리 탭에서 캐시 상태를 정기적으로 확인합니다. 다음 경우에 주의가 필요합니다:

• last_refreshed가 예상 갱신 주기보다 오래된 경우
• status가 failed인 경우
• row_count가 이전 대비 크게 변동한 경우 (데이터 누락 또는 중복 가능성)

다음 단계

• ETL 파이프라인 — UBIST 데이터 적재 방법
• 문제 해결 — 캐시 관련 문제 대응