TimescaleDB Continuous Aggregates: 실시간 vs Materialized-Only

Source: Dev.to

위의 링크에 포함된 전체 텍스트를 제공해 주시면, 해당 내용을 한국어로 번역해 드리겠습니다.
(코드 블록, URL 및 마크다운 형식은 그대로 유지됩니다.)

연속 집계란 무엇인가?

연속 집계는 자체 숨겨진 하이퍼테이블을 기반으로 하는 물리화된 뷰입니다. TimescaleDB는 사전에 계산된 집계 결과를 이 물리화 하이퍼테이블에 저장하므로, 쿼리는 수백만 개의 원시 레코드를 스캔하는 대신 압축된 요약 행을 읽습니다.

CREATE MATERIALIZED VIEW hourly_device_metrics
WITH (timescaledb.continuous) AS
SELECT
    time_bucket('1 hour', event_timestamp_utc) AS bucket_hour_utc,
    device_id,
    AVG(metric_value)      AS avg_metric_value,
    MAX(metric_value)      AS max_metric_value,
    COUNT(*)               AS event_count
FROM sensor_events
GROUP BY bucket_hour_utc, device_id;

CAGG를 생성하면 구조가 정의되지만 데이터가 채워지지는 않습니다. 물리화 하이퍼테이블은 새로 고침 정책을 추가하거나 수동으로 새로 고침을 실행할 때까지 비어 있습니다.

새로 고침 정책

새로 고침 정책은 TimescaleDB에게 슬라이딩 시간 창에 대해 주기적으로 집계를 다시 계산하도록 지시합니다:

SELECT add_continuous_aggregate_policy(
    'hourly_device_metrics',
    start_offset      => INTERVAL '3 hours',
    end_offset        => INTERVAL '1 hour',
    schedule_interval => INTERVAL '30 minutes'
);

세 매개변수의 상호 작용 방식

end_offset은 핵심 매개변수입니다. 이것은 의도적인 공백을 만듭니다: 정책이 고의적으로 건너뛰는 최신 데이터의 창입니다. 이는 버그가 아닙니다. 가장 최신의 시간 버킷은 여전히 데이터를 축적하고 있습니다. 부분적으로 채워진 버킷을 물리화한 뒤 몇 분 뒤에 다시 물리화하는 것은 불필요한 연산입니다. end_offset은 이러한 반복을 방지합니다.

실제 결과: 위와 같은 설정에서는 물리화된 데이터가 항상 최소 1시간 이상 오래된 것이며, 최대 1.5시간까지 오래될 수 있습니다 (end_offset에 schedule_interval 한 사이클을 더한 값).

실시간 모드 (기본)

실시간 CAGG를 쿼리하면 TimescaleDB가 두 데이터 소스를 투명하게 결합합니다:

1. 역사적 범위에 대한 물리화된 하이퍼테이블에서 사전 계산된 결과.
2. 소스 하이퍼테이블에 대해 물리화 워터마크보다 최신인 데이터에 대한 실시간 집계.

두 결과 집합은 자동으로 합쳐집니다. 애플리케이션은 모든 데이터가 물리화된 것처럼 단일하고 완전한 결과 집합을 보게 됩니다.

쿼리 계획에서 확인할 수 있습니다: 두 자식을 가진 Append 노드 — 하나는 물리화된 하이퍼테이블을 스캔(빠름)하고, 다른 하나는 소스 하이퍼테이블을 스캔(느림, 원시 데이터에 대해 전체 집계를 수행)합니다.

트레이드‑오프

Materialized‑Only Mode

실시간 union을 완전히 비활성화할 수 있습니다:

ALTER MATERIALIZED VIEW hourly_device_metrics
SET (timescaledb.materialized_only = true);

materialized‑only 모드에서는 CAGG가 사전 계산된 데이터만 반환합니다. 쿼리는 소스 하이퍼테이블에 절대 접근하지 않습니다. 가장 최신 데이터(end_offset 윈도우 내의 모든 데이터)는 표시되지 않습니다.

장점

• 쿼리가 더 빠르고 예측 가능합니다; 실시간 집계 경로가 없고, 누적된 비물리화 데이터 양에 따라 성능이 변동하지 않습니다.
• 쿼리 계획에 단일 스캔이 표시되어 물리화된 하이퍼테이블만 읽습니다.

데이터 손실 없이 언제든지 모드 간 전환이 가능합니다:

-- materialized‑only 로 전환 (쿼리는 더 빠르지만 최신 윈도우는 오래된 데이터)
ALTER MATERIALIZED VIEW hourly_device_metrics
SET (timescaledb.materialized_only = true);

-- real‑time 로 다시 전환 (최근 윈도우는 느리지만 전체 데이터 제공)
ALTER MATERIALIZED VIEW hourly_device_metrics
SET (timescaledb.materialized_only = false);

데이터가 삭제되거나 재계산되지 않으며, 토글은 쿼리 실행기가 실시간 union을 포함할지 여부만 변경합니다.

비교 표

Source: …

언제 어떤 모드를 사용할까

• 실시간 모드 (Real‑Time Mode) – 소비자가 최신 데이터를 기대하고 최근 윈도우에서 약간 높은 지연을 허용할 수 있을 때 사용합니다. 운영 대시보드와 알림에 이상적입니다.
• Materialized‑Only 모드 – 신선도 요구사항이 완화되고 쿼리 일관성이 더 중요할 때 사용합니다. 청구 계산, 일일 보고서, 일정에 따라 실행되는 분석 파이프라인 등 실시간 집계 오버헤드가 필요 없는 경우에 이상적입니다.

무음 실패 모드

연속 집계의 무음 실패 모드는 staleness(오래됨) 입니다. Materialized‑Only 모드에서는 CAGG가 end_offset과 schedule_interval 크기만큼 오래된 결과를 반환합니다. 애플리케이션의 신선도 요구사항에 맞는 모드를 선택하십시오.

-- 물리화 워터마크를 확인하고 오래됨을 감지
SELECT
    view_name,
    materialization_hypertable_name,
    (SELECT max(bucket_hour_utc) FROM hourly_device_metrics) AS latest_materialized,
    now() - (SELECT max(bucket_hour_utc) FROM hourly_device_metrics) AS staleness
FROM timescaledb_information.continuous_aggregates
WHERE view_name = 'hourly_device_metrics';

staleness가 end_offset과 schedule_interval을 크게 초과한다면, 새로 고침 정책이 제대로 실행되고 있지 않은 것입니다. timescaledb_information.job_stats에서 새로 고침 작업의 last_successful_finish와 total_failures를 확인하십시오.

Note:
새로 고침 정책에 있는 end_offset은 버그나 잘못된 설정이 아닙니다. 부분적으로 채워진 버킷의 불필요한 재계산을 방지하기 위한 의도된 설계 선택입니다.

• 실시간 모드는 차이를 투명하게 메워 최신 결과를 보장합니다.
• Materialized‑Only 모드는 속도가 신선도보다 더 중요할 때 유용합니다.

권장 사항

1. 실시간 모드부터 시작하세요.
2. 라이브 집계 오버헤드가 불필요한 특정 쿼리나 사용 사례를 식별한 후에만 materialized‑only 모드로 전환하세요.

모드 간 토글은 즉시이며 되돌릴 수 있습니다. 각 연속 집계가 어떤 모드에서 실행되고 있는지, 그리고 그 이유를 아는 것이 집계된 데이터의 신뢰성을 유지합니다.