대시보드 조회를 materialized view로 바꾸려 합니다. 일반 view와 갱신·최신성·비용이 어떻게 다른가요?

일반 view는 저장된 질의 정의이고 materialized view는 계산 결과를 저장해 재사용하는 구조입니다. 조회 비용을 미리 지불하는 대신 원본 변경이 언제 반영되는지와 재계산 비용을 관리해야 합니다.

동작 원리와 전제

주문 합계를 저장하면 매 요청 큰 집계를 피할 수 있지만 refresh 사이에는 값이 낡습니다. 전체 refresh와 증분 갱신 지원은 제품별로 다르며 동시 refresh 옵션도 잠금·인덱스 조건·임시 공간을 없애지 않습니다. 새 결과를 만드는 동안 사용자가 어느 버전을 읽는지 정합니다.

선택과 실패 처리

화면이 몇 분 지연을 허용하면 갱신 시각을 표시하고 실패 시 이전 결과를 유지할 수 있습니다. 결제·재고 확정에는 원본의 조건을 다시 확인해야 합니다. 증분 집계는 수정·삭제·지연 이벤트·중복 처리와 반올림 정책까지 다뤄야 합니다.

구체적인 사례와 검증

집계가 매 5분 갱신되는데 갱신 시간이 10분이면 단순 주기 설정만으로 5분 신선도를 보장하지 못합니다. 겹친 refresh를 허용할지 한 번만 실행할지와 실패 후 다음 기준점을 정해야 합니다. 새 결과를 부분적으로 덮는 구현은 사용자가 일부 구간은 새 값, 일부는 옛 값을 보는 문제를 만들 수 있어 원자 게시나 버전별 읽기가 필요합니다. 집계의 count·sum을 원본과 대조하고 삭제·환불·소급 보정을 포함합니다. 조회 성능만 기록하면 갱신 작업이 원본 DB를 느리게 만드는 비용을 놓치므로 사용자 쓰기 지연과 동시에 측정하겠습니다.

refresh 중 오류·동시 쓰기·큰 데이터·디스크 부족을 재현합니다. 조회 p99뿐 아니라 갱신 CPU·I/O·잠금·원본과의 차이를 측정합니다. 저장 결과가 있다는 사실이 현재 원본과 항상 같다는 보장은 아니므로 신선도 SLO와 재구축 절차를 함께 둡니다.