재료보기
MV (Materialized View) 는 물리적으로 저장된 쿼리 결과 (집계/투영) 로 주기적으로 또는 지속적으로 업데이트되며 빠르게 읽을 수 있습니다. 실제로, 이것은 신선도와 판독 비용이 통제 된 "사전 계산 된" 데이터입니다.
주요 목표는 다음과 같습니다
읽기 대기 시간을 안정화하십시오 (p95/p99).
핫 OLTP 테이블을 언로드하십시오.
분석, API 및 기능 (권장 사항, 카운터, 디렉토리) 에 대한 예측 가능한 SLA를 제공하십시오.
1) MV 사용시기 (및 그렇지 않은 경우)
적합:- 유효한 업데이트 지연으로 무거운 요청 (가입/agg/창) 이 자주 반복됩니다.
- CQRS/제품 예측: 대시 보드, 카탈로그, 순위 목록, 카운터.
- 다중 지역은 "로컬" 총 사본을 읽습니다.
- 보상 논리가없는 "레코드 당" 매우 엄격한 관련성 → 더 나은 인덱스/OLTP + 캐시/스트리밍.
- 복잡한 거래 불변량은 MV → 를 쓸 때 트랜잭션을 대체하지 않습니다.
2) MV vs 캐시 vs 프로젝션
캐시: 응용 프로그램 수준에서 TTL/장애로 관리되는 "응답 사본"; 스키마가 없습니다
MV: DBMS/엔진이 관리하는 "데이터 복사"; 체계, 색인, 트랜잭션 새로 고침이 있습니다.
프로젝션 (이벤트 소싱/CQRS): 이벤트에서 계산; 종종 테이블 + 증분 업데이트 (즉, 본질적으로 "수동 MV") 로 구현됩니다.
3) 업데이트 방법
3. 1 배치 REFRESH (주기적)
Scheduler (cron/skeduler): 'REFRESH MATERIALIZED VIEW...'.
장점: 간단하고 예측 가능하며 저렴합니다. 단점: 오래된 창문.
3. 2 증분 새로 고침
키/시간 창 별 델타, MV의 업저트.
변경 사항: CDC (Debezium, 논리 복제), 스트리밍 (Kafka/Flink/Spark), 트리거.
장점: 낮은 대기 시간과 비용. 단점: 보다 복잡한 코드와 일관성.
3. 3 스트리밍 MV
열/스트리밍 ICE: 구체화 된 스트림/테이블 (ClickHouse/Kafka, Flink SQL, Materialize, Bigquery MV).
장점: 초 이하. 단점: 스트림 인프라와 명확한 키/워터 마크가 필요합니다.
4) 일관성과 "신선도"
MV의 강력한 일관성은 "원자" 새로 고침 (새 버전으로의 읽기 전환) 으로 발생합니다.
더 자주 - 한계가있는 부실성: "을 초과하지 않습니다. "API/UX 계약에서이를 통신하십시오.
결제/엄격한 불변량의 경우 CP 코어를 OLTP에 보관하고 MV를 판독 평면으로 사용하십시오.
5) 모델링 및 레이아웃
MV를 목적에 따라 좁게 만드십시오: 하나의 작업-하나의 MV.
임시 키 (이벤트 _ time/워터 마크) 및 비즈니스 키 (테넌트 _ id 엔티티 _ id) 를 저장합니다.
빈번한 필터/정렬 색인; 열 DBMS - 집계/스캔 용.
빠른 새로 고침 및 유지를 위해 날짜/테넌트/지역 별 참여.
6) 증분 업데이트: upsert 프로젝션 패턴
1. 변경이 도착합니다 (CDC/이벤트).
2. MV 문자열의 델타 (재 컴파일/병합) 를 고려하십시오.
3. 키 별 'UPSERT' ('테넌트 _ id, 엔티티 _ id, 버킷').
4. 신선도 메타 데이터 업데이트
이념은 필수입니다: 델타 반복이 결론을 깨지 않아야합니다.
7) 예 (개념적으로)
PostgreSQL (배치 새로 고침)
sql
CREATE MATERIALIZED VIEW mv_sales AS
SELECT date_trunc('day', created_at) AS day,
tenant_id,
SUM(amount) AS revenue,
COUNT() AS orders
FROM orders
GROUP BY 1,2;
-- Быстрые чтения
CREATE INDEX ON mv_sales (tenant_id, day);
-- Без блокировок чтения при обновлении
REFRESH MATERIALIZED VIEW CONCURRENTLY mv_sales;ClickHouse (MV и스트리밍 카프카)
sql
CREATE TABLE events_kafka (..., ts DateTime, tenant_id String)
ENGINE = Kafka SETTINGS kafka_broker_list='...',
kafka_topic_list='events',
kafka_format='JSONEachRow';
CREATE MATERIALIZED VIEW mv_agg
ENGINE = AggregatingMergeTree()
PARTITION BY toDate(ts)
ORDER BY (tenant_id, toStartOfMinute(ts)) AS
SELECT tenant_id,
toStartOfMinute(ts) AS bucket,
sumState(amount) AS revenue_state
FROM events_kafka
GROUP BY tenant_id, bucket;Bigquery MV (자동 업데이트)
sql
CREATE MATERIALIZED VIEW dataset.mv_top_products
AS SELECT product_id, SUM(amount) AS revenue
FROM dataset.orders
WHERE _PARTITIONDATE BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY) AND CURRENT_DATE()
GROUP BY product_id;8) 인터페이스/계약의 신선도
반환 'X-Data-Freshness: <seconds> '/field' as _ of '.
중요한 화면의 경우 "업데이트 버튼" 및 "뒤에서 N을 업데이트" 배지입니다.
API에서 신선도의 SLO를 지정하십시오 (예: p95 소 60 초).
9) 멀티 테넌트 및 지역
MV의 '테넌트 _ id' 키가 필요합니다.
공정성: 임차인에 의한 새로 고침/스트림에 대한 할당량; 세입자 당 밤에 큰 MV를 전단합니다.
거주지: MV는 기본 데이터와 동일한 지역에 거주합니다. 교차 지역-집계 만.
10) 관찰 가능성
메트릭:- 'freshness _ age _ ms' (p50/p95/p99), '새로 고침 _ latency _ ms', 'rows _ processed/s', 'refresh _ orts'.
- MV/로트 크기, 스토리지 오버 헤드.
- 스트리밍: 커넥터 지연, "물" (워터 마크), 늦은 이벤트 공유.
- 이름: 'mv _ 막대', '테넌트 _ id', '파티션', '새로 고침 _ id', '델타 _ 크기'.
- 이유에 대한 "재 계산" 및 파일에 대한보고 (스키마 불일치, 시간 초과).
11) 테스트와 혼돈
정확성: 서브 샘플에서 MV 대 소스의 비교; 체크섬.
하중중의 신선도: 쓰기 부하 + SLO 신선도 보장.
스키마 진화: 필드 추가/이름 변경, CDC 커넥터 드롭.
늦음/순서 외: 이벤트 재생, 워터 마크 변경.
이념성: 델타/배치의 재전달.
12) 유지 및 비용
필요한 창 만 저장하십시오 (예: 90 일). 오래된 파티를 보관하십시오.
정기적 인 진공 청소기/병합 (엔진 별).
"범용 몬스터" 를 피하면서 특정 API/페이지로 MV를 줄입니다.
13) 안전 및 준수
상속 소스 액세스 정책 (RLS/ACL) -소스 테이블보다 광범위한 MV를 배포하지 마십시오.
특히 분석/로그를 위해 MV를 구축 할 때 PII를 마스크하십시오.
감사 새로 고침/재구동.
14) 전형적인 오류
"모든 것을위한 하나의 거대한 MV →" 값 비싼 새로 고침과 약한 격리.
색인/파티 부족 → p99 점프, 새로 고침 클러스터가 교살됩니다.
점진적으로 가능한 델타 대신 완전 재 계산.
"오래된" 데이터에 대한 API/UX → 사용자 불만에서 선언되지 않은 신선도.
스키마 진화/CDC 오류를 무시하고 → 일관성 상실.
MV를 트랜잭션으로 교체하려고 시도: MV는 엄격한 쓰기 작업이 아니라 읽기에 관한 것입니다.
15) 빠른 레시피
제품 대시 보드: 분/시간 버킷 별 MV, VIP 주문형 스케줄 + 새로 고침, p95 신선도
디렉토리/검색: CDC (upsert) 의 증분 투영, 필터 별 색인, 지연 5-15 초.
재무보고: 응답에서 원자 'REFRESH CONCURENTLY', 체크섬 "as _ of" 로 MV를 배치하십시오.
글로벌 SaaS: 지역 MV, 지역 간 비동기 집계.
16) 사전 판매 점검표
- 신선한 SLA (λt/p95) 는 API/UX에 정의되고 반영됩니다.
- 선택된 모드: 배치 새로 고침/증분/스트리밍; 소스 (CDC/이벤트) 가 설명됩니다.
- MV는 "작업별로" 설계되었으며 인덱스와 파티션이 있으며 스토리지는 창으로 제한됩니다.
- upsert/colligates의 신원은 테스트에 의해 확인됩니다. 늦은/주문 외 처리.
- 관찰 가능성: 신선도/지연 지표, 경고, 새로 고침 추적.
- 플레이 북: 부품의 재 계산, 커넥터 고장 후 다시 그리기, 계획의 진화.
- 액세스 및 PII는 소스에 해당합니다. 감사가 활성화되었습니
- 통제되는 비용: 보존, 압축, 새로 고침 창 시간.
- 문서: MV에서 사실, 파생 계층, 비즈니스 기대치는 무엇입니까?
결론
재료 표현은 읽기 속도와 관련성 간의 엔지니어링 절충입니다. 명확한 SLA 신선도, 올바른 체계, 증분 업데이트 및 일반 원격 측정을 통해 MV는 신뢰성과 비용 관리를 희생하지 않으면 서 무거운 요청을 예측 가능한 밀리 초 단위로 전환합니다.