뜨거운/따뜻한/차가운 금고

1) 데이터를 Hot/Warm/Cold로 나누는 이유

새로운 데이터에 대한 대화식 요청, 최근 기간 동안의 분석 및 아카이브에 대한 드문 액세스 등 다양한 액세스 패턴이 동일한 클러스터에 공존합니다. 레이어링을 통해 다음을 수행 할 수 있습

비용 최적화: 핫 워크 세트만을위한 빠르고 비싼 레이어.
SLO와 함께: 온라인을위한 p95/처리량, 역사를위한 더 긴 마감일.
스케일링 단순화: "전면" 을 과열하지 않고 저렴한 레이어를 수평으로 구축합니다.
완화 위험: 다른 실패/복제 도메인, 독립적 인 보호 정책.

• 핫-가장 최근의 빈번한 읽기/쓰기, 최소 대기 시간.
• 따뜻함-시간이 지남에 따라 많은 독서가 덜 자주 변경됩니다.
• 콜드-아카이브, 저렴한 스토리지, 높은 TTFB, 느린 복구.

2) 레벨 별 프로필 및 SLO

뜨거운

액세스: 밀리 초 (KV/인덱스의 경우 p95 × 5-20 ms, 복잡한 쿼리의 경우 100-300 ms).
작업: 빈번한 업저트/추가, 인덱싱, OLTP/스트림 발굴.
미디어: NVMe/SSD, 메모리, 빠른 네트워크.
복제: 증가 (예: RF = 3) RPO 0, RTO 분 동안.

따뜻한

액세스: 수백 밀리 초/초.
작업: 신선한 역사에 대한 "창", 버치, OLAP 읽기 (7-90 일).
미디어: 로컬 캐시가있는 SATA SSD/fast HDD/오브젝트 스토리지.
복제: 보통 (RF = 2), 압축 활성화.

감기

액세스: 초 시간; 자주 오프라인 액세스, "검색 및 스캔".
운영: 드문 수치, 규제 준수 (연도 별 유지).
미디어: 객체/아카이브 (S3 Glacier/Deep Archive, Azure Archive, GCS Coldline).
복제: 지역/지역 간, WORM/법적 보류.

3) 층별 전형적인 기술

뜨거운: PostgreSQL (OLTP, 파티션), MySQL/InnoDB, Redis/Memcashed (채), Elastic까지 검색합니다.
따뜻한: ClickHouse 열 스토리지, Bigquery/Snowflake 최근 파티, Elastic까지 따뜻한 노드, 캐시가있는 S3 + Presto/Trino, 계층 형 스토리지 (Kafka/Pulsar).
콜드: S3/Glacier, GCS Nearline/Coldline/Archive, Azure Cool/Archive, HDFS 아카이브, 장기 백업.

4) 생명주기 정책 (ILM) 및 자동화

4. 1 개념

시간 분할 (주/주/월) 은 레이어 간의 주요 번역 레버입니다.
ILM 규칙: 롤오버 (볼륨/연령 별), 수축/병합, 동결, 삭제.
중복 및 압축: 따뜻한/차가운 상태에서 CPU 병목 현상을 피하십시오.

4. 2 예

엘라 스틱 검색 ILM (핫 → 워머 → 콜드 → 삭제)

json
{
"policy": {
"phases": {
"hot":  { "actions": { "rollover": { "max_age": "7d", "max_size": "50gb" } } },
"warm": { "min_age": "7d", "actions": { "allocate": { "require": { "box_type": "warm" } }, "forcemerge": { "max_num_segments": 1 } } },
"cold": { "min_age": "30d", "actions": { "allocate": { "require": { "box_type": "cold" } }, "freeze": {} } },
"delete":{ "min_age": "365d", "actions": { "delete": {} } }
}
}
}

S3 라이프 사이클 (표준 → 빈번하지 않은 → 빙하 → 심판)

json
{
"Rules": [{
"ID": "logs-lifecycle",
"Filter": { "Prefix": "logs/" },
"Status": "Enabled",
"Transitions": [
{ "Days": 7, "StorageClass": "STANDARD_IA" },
{ "Days": 30, "StorageClass": "GLACIER" }
],
"Expiration": { "Days": 365 }
}]
}

카프카 계층 형 스토리지 (스케치)

properties log. segment. bytes=1073741824 log. retention. ms=259200000 tiered. storage. enable=true remote. log. storage. system=s3 remote. log. storage. bucket=topic-archive

날짜 별 PostgreSQL 파티션

sql
CREATE TABLE events (
id bigserial, at timestamptz NOT NULL, payload jsonb
) PARTITION BY RANGE (at);

CREATE TABLE events_2025_10 PARTITION OF events
FOR VALUES FROM ('2025-10-01') TO ('2025-11-01')
TABLESPACE ts_hot; -- further ALTER TABLE... SET TABLESPACE ts_warm по ILM

5) 비용 및 성능 모델링

5. 간단한 TCO 모델 1 개

'TCO = 압축/스캔 + 관리 + DR/복제를위한 CapEx/OpEx 미디어 + 네트워크 (출력) + CPU'.

5. 2 대기 시간과 가격의 균형

데이터의 5-20% 인 핫 세트는 쿼리의 80-95% 를 산출합니다.
목표는 작업 세트를 Hot/cash (CPU/RAM/NVMe) 에 유지하고 나머지는 Warm/Cold로 이동하는 것입니다.

5. 3 메트릭

(PHP 3 = 3.0.6, PHP 4)

6) 파티션, 인덱싱 및 캐싱

"신선한" 슬라이스에 대한 타임 파티션 + 2 차 지수.
요청의 황금 규칙: 먼저 시간별로 필터링 한 다음 선택적 키.
계층 적 캐시: in-proc → Redis → edge; 핫 키/골재를위한 핀 캐시.
Bloom은 인덱스 (ClickHouse, Parquet) 를 필터/건너 뛰어 읽기를 따뜻하거나 차갑게 줄입니다.

7) 복제, 내결함 및 DR

핫: 동기 복제 (다중 영역), RPO λ0, 빠른 페일 오버.
따뜻함: 비동기식 인터 존/지역 간 복제본; RPO 분.
추위: WORM (Write Once Read Many) 과의 지역간 규정 준수.
DR 계획: "차가운" 아카이브 (시간) 복원, 주기적인 소방 훈련을위한 런북.

8) 안전 및 준수

PII/PCI: 휴식 시간 암호화 (KMS), 각 단계의 주요 정책, 아래로 이동할 때 마스킹.
보존 및 제거: 차갑고 입증 가능한 지우기에 대한 자동 마감일 (지우기 보고서).
관할권: 해당 지역의 저장 (EU 전용, RU 전용, Ł- 지역 등), 버킷의 지리 격리.

9) 사용 패턴

9. 1 개의 통나무 및 원격 측정

핫: NVMe의 ElasticSearch/ClickHouse에서 마지막 24-72 시간.
따뜻함: S3의 SSD/HDD + Parquet에서 30-180 일.
감기: 빙하에서> 180 일; Trino/Presto를 통한 요청 "주문형".

9. 거래/주문 2 개

핫: 짧은 기록을 가진 OLTP 데이터베이스 (PostgreSQL/MySQL).
따뜻한: BI에 대한 비정규화 된 스냅 샷.
추위: 법률 보관소, 객체 보관소로 내보냅니다.

9. 3 ML-ficestore

핫: Redis/low-latency DB의 온라인 기능.
따뜻함: 열/객체의 오프라인 기능.
추위: 버전이 지정된 소스 데이터 세트 (Delta/Iceberg/Hudi).

10) 클러스터 및 Kubernetes와의 상호 작용

계층 별 Mark StorageClass: 'gold-nvme' (핫), 'silver-ssd' (워밍), '브론즈 오브젝트' (콜드).
핫/워밍/콜드 워크샵을위한 풀 노드 (테인/라벨) 를 계획하십시오.
오브젝트 스토리지 요청 전에 사이드카 캐시 (예: 로컬 SSD 캐시).

PVC의 예

yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: { name: db-hot }
spec:
storageClassName: gold-nvme accessModes: [ ReadWriteOnce ]
resources: { requests: { storage: 500Gi } }

11) 관찰 가능

대시 보드: 계층별 바이트/요청 배포, 계층 당 대기 시간, 따뜻한/차가운, 비용/월 오프로드.
경고: 히트 비율의 감소, 프로모션 비율의 증가 (충분한 뜨거운 양이 있음), 따뜻함에 의한 TTFB의 증가, 감기의 느린 회복 (SLO 위반).

12) 반 패턴

"모두 뜨겁다": 과도한 비용, IO 과열.
"인덱스가없는 깊은 추위": 저장하기에 저렴하고 읽기 비싸다; 빠른 슬라이스 경로가 없습니다.
"ILM 없음": 수동 전송, 인적 오류.
모든 수준에 대한 "균일 한 복제 정책": 초과 지불 및 고르지 않은 RPO.
하나의 계산 풀에서 혼합 prod/archive 쿼리-간섭.
차가운 구름에서 "설명되지 않은 탈출": 법안의 놀라움.

13) 구현 점검표

• 데이터 세트: SLA, 액세스 주파수, 스토리지 요구 사항.
• 계층 당 미디어 및 엔진 선택 (NVMe/SSD/HDD/Object/Archive).
• 디자인 시간/키 파티션, 색인 및 형식 (Parquet/ORC/Delta).
• ILM 규칙 정의 (롤오버/전환/만료) 및 자동화.
• 압축/코딩 사용 (ZSTD/LZ4; 추위에-더 강함).
• 복제/RPO/RTO 및 DR 절차를 정의하십시오.
• 캐시 계층 구조를 설정하고 핫 집계를 위해 핀을 설정합니다.
• 비용/대기 시간 지표 및 계층 경고.
• 보안 정책 (KMS, 법적 유지, 지리 격리).
• 정기적 인 검토 이전 임계 값 (계절성, 성장).

14) FAQ

Q: 뜨거운 것과 따뜻한 것의 경계를 어떻게 정의합니까?
A: 요청의 실제 배포판에 따르면: "핫 워킹 세트" = 키/파티의 상위 5-20%, 요청의 80-95% 를 제공합니다. 실패하는 것은 따뜻한 후보입니다.

Q: 감기에서 직접 읽을 수 있습니까?
A: 그렇습니다. 그러나 몇 분/시간 및 탈출 비용으로 SLA를 계획하십시오. 분석 전에 조각을 따뜻하게 (준비) 하기 위해 본국으로 송환하는 것이 더 수익성이 높습니다.

Q: 30-180 일 동안 분석을 위해 무엇을 선택해야합니까?
A: 캐시가있는 객체 + 쿼리 엔진 (Trino/Presto/ClickHouse) 의 열 형식 (Parquet/ORC); Io를 저장하기 위해 색인/건너 뛰기 데이터.

Q: 추위에서 회복 할 때 "예열 폭풍" 을 피하는 방법?
A: 따뜻한 상태에서 프리 페치/준비 작업, 제한 요청, 시간 선명도, 요청 통합 및 핀 캐시를 사용하십시오.

15) 총계

Hot/Warm/Cold 아키텍처는 액세스 프로파일과 자동 수명주기 관리 비용이 일치합니다. 계층 별 SLO, 파티션 및 ILM, 합리적인 복제 및 캐시 계층 구조는 "핫" 빠르고 "따뜻한" 저렴하며 "차가운" 저렴하고 안전합니다.