핵심 요약
Materialize 1.0 GA 후 첫 분기. 핵심은 incremental view maintenance(IVM) — 일반 SQL의 VIEW가 실시간으로 변경분만 재계산되며 항상 최신 상태를 유지한다. Flink/ksqlDB 대비 SQL 그대로 쓸 수 있다는 점이 가장 크다. 단, 메모리 모델과 비용은 처음에 놀란다.
1. 핵심 개념 — 그냥 SQL인데 실시간
CREATE SOURCE orders
FROM POSTGRES CONNECTION pg_conn (PUBLICATION 'mz_pub')
FOR TABLES (orders, order_items);
CREATE SOURCE clicks
FROM KAFKA CONNECTION kafka_conn (TOPIC 'clicks')
FORMAT JSON;
CREATE MATERIALIZED VIEW user_revenue AS
SELECT u.id, u.country, SUM(oi.price * oi.qty) AS total
FROM users u
JOIN orders o ON o.user_id = u.id
JOIN order_items oi ON oi.order_id = o.id
WHERE o.created_at > NOW() - INTERVAL '7 days'
GROUP BY u.id, u.country;
이 뷰는 항상 최신. Postgres에서 INSERT가 들어오는 즉시 뷰가 갱신된다. SELECT 시 항상 0에 가까운 응답.
2. Postgres CDC 설정
-- Postgres 측
ALTER SYSTEM SET wal_level = logical;
CREATE PUBLICATION mz_pub FOR TABLE orders, users, order_items;
-- Materialize 측
CREATE CONNECTION pg_conn TO POSTGRES (
HOST 'pg.internal',
DATABASE 'prod',
USER 'mz_repl',
PASSWORD SECRET pg_pass,
SSL MODE 'require'
);
주의: 초기 스냅샷이 큰 테이블(수억 행)에선 수 시간 걸린다. 운영 중인 DB의 WAL 슬롯 보관 용량 모니터링 필수.
3. 실측 — 레이턴시와 비용
| 워크로드 | 처리량 | p50 lag | p99 lag |
|---|---|---|---|
| 단순 필터링 뷰 | 180K msg/s | 12ms | 48ms |
| 3-way 조인+집계 | 42K msg/s | 96ms | 230ms |
| 윈도우 함수+조인 | 18K msg/s | 210ms | 520ms |
비용: Standard 100cc 클러스터 월 $1,800. 위 워크로드 한 번에 처리. Flink 자체 운영 대비 인건비 빼면 비싸 보이지만 합치면 비슷.
4. Flink와 직접 비교
| 항목 | Materialize | Flink |
|---|---|---|
| 학습곡선 | SQL만 알면 됨 | Java/SQL+상태 API |
| 운영 인력 | 0.2명 | 1~2명 |
| 월 인프라+라이선스 | $1,800~$8,000 | $600~$3,000 |
| 복잡 윈도우 | 기본 SQL만 | 매우 유연 |
| State 크기 한계 | 메모리 제약 큼 | RocksDB로 큼 |
5. 비용이 폭증하는 패턴
- 큰 카디널리티 GROUP BY: 사용자별 집계가 수천만이면 메모리 폭증
- 윈도우 없는 조인: 양쪽 테이블 전체를 메모리에 들고 있어야 함
- JSON 컬럼 빈번한 unnest: CPU 부담
6. 클러스터 분리 — 비용 통제
CREATE CLUSTER ingest SIZE = '50cc';
CREATE CLUSTER analytics SIZE = '200cc' REPLICATION FACTOR = 2;
CREATE CLUSTER serving SIZE = '25cc';
SET CLUSTER = analytics;
CREATE MATERIALIZED VIEW heavy_agg AS ...;
SET CLUSTER = serving;
CREATE INDEX ON heavy_agg (user_id);
7. 실패 시나리오
- 스키마 변경: Postgres ALTER TABLE 후 소스 재생성 필요
- 리허이드레이션: 클러스터 재시작 시 모든 뷰 재계산. 큰 뷰는 15~30분
- WAL 슬롯 폭증: Materialize가 죽으면 Postgres WAL이 차오름. 알람 필수
8. 도입 결정
- 좋음: 실시간 대시보드, 사기 탐지 룰, 개인화 점수, CDC 기반 read model
- 유보: 메모리 제약 큰 워크로드, 복잡한 시간 윈도우 로직
- 나쁨: 배치 ETL을 굳이 실시간으로 만들고 싶을 때
참고
- materialize.com/docs
- github.com/MaterializeInc/materialize

댓글 0