ホット/ウォーム/コールドボルト

1）ホット/ウォーム/コールドでデータを分割する理由

• コストの最適化：ホットワークセットのみの高速で高価なレイヤー。
• SLOに準拠：オンラインのp95/スループット、履歴の長い期限。
• スケーリングを簡素化：「フロント」を過熱することなく、水平に安価なレイヤーを構築します。
• リスクの軽減：異なる障害/レプリケーション・ドメイン、独立した保護ポリシー。

• ホット-最新、頻繁な読み書き、最小限のレイテンシ。
• 暖かい-頻繁に変化することは少なく、時間の経過とともに多くの読書があります。
• 冷たい-アーカイブ、安価なストレージ、高いTTFB、遅い回復。

2）レベル別のプロファイルとSLO

ホット（Hot）

アクセス：ミリ秒（KV/インデックスではp95 ≤ 5-20ミリ秒、複雑なクエリでは≤ 100-300ミリ秒）。
操作：頻繁なupsert/append、インデックス作成、OLTP/stream-ingest。
メディア：NVMe/SSD、メモリ、高速ネットワーク。
レプリケーション：増加（例：RF=3） RPO≈0、 RTO分。

暖かい

アクセス：数十から数百ミリ秒/秒。
操作：読み取り「ウィンドウ」、バッチ、新鮮な歴史のOLAP （7-90日）。
メディア：ローカルキャッシュ付きSATA SSD/高速 HDD/オブジェクトストレージ。
レプリケーション：中程度（RF=2）、圧縮が有効。

寒さ

アクセス：秒-時間；頻繁なオフラインアクセス、「retrieve-and-scan」。
操作：まれな読書、規則の承諾（年によって保持）。
メディア：オブジェクト/アーカイブ（S3氷河/ディープアーカイブ、Azureアーカイブ、GCS Coldline）。
レプリケーション：地域/地域間、WORM/Legal Hold。

3）層による典型的な技術

Hot： PostgreSQL （OLTP、パーティション）、MySQL/InnoDB、 Redis/Memcached （кэш）、 Elasticsearch/Opensearchホットノード、ClickHouse партиции、 Kafkaローカルログ。
Warm： ClickHouse列ストレージ、BigQuery/Snowflake最近のパーティー、Elasticsearch warm-nodes、 S3+Presto/Trino with cache、階層型ストレージ（Kafka/Pulsar）。
Cold： S3/Glacier、 GCS Nearline/Coldline/Archive、 Azure Cool/Archive、 HDFSアーカイブ、長期バックアップ。

4）ライフサイクルポリシー（ILM）と自動化

4.1つのコンセプト

時間パーティショニング（day/week/month）は、レイヤー間の主な翻訳レバーです。
ILMルール：ロールオーバー（ボリューム/年齢別）、縮小/マージ、フリーズ、削除。
重複排除と圧縮：暖かい/寒いときに有効にし、CPUのボトルネックを避けます。

4.2例

Elasticsearch 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.1シンプルなTCOモデル

'TCO=CapEx/OpEx media+network （egress）+CPU for compression/scans+management+DR/replication'。

5.2レイテンシーと価格のバランス

データの5〜20％ ≈ホットセットは、クエリの80〜95％を生成します。
目標は、Hot/cache （CPU/RAM/NVMe）で作業セットを維持し、残りをWarm/Coldにシフトすることです。

5.3メトリクス

、 、 、 、 （寒い→暖かい）、 （暑い→暖かい/寒い）。

6）パーティショニング、インデックス作成、キャッシュ

「新鮮な」スライスのタイムパーティション+セカンダリインデックス。
リクエストのゴールデンルール：最初に時間ごとにフィルターし、次に選択キーを指定します。
階層キャッシュ：in-proc→Redis→edge；ホットキー/集計のピンキャッシュ。
Bloomフィルタ/スキップインデックス（ClickHouse、 Parquet）は、読み取りを暖かく/寒くするために減らします。

7）レプリケーション、フォールトトレランス、DR

Hot：同期レプリケーション（マルチゾーン）、RPO≈0、高速feilover。
暖かい：非同期インターゾーン/地域間レプリカ；RPO分。
Cold： WORMと地域間（Write Once Read Many）、コンプライアンスの法的保持。
DR-plans：「冷たい」アーカイブの復元のためのランブック（時間）、定期的な消防訓練。

8）安全性とコンプライアンス

PII/PCI： rest （KMS）での暗号化、各ステージでのキーポリシー、下に移動するときのマスキング。
保存と削除：寒さ、証明可能な消去（レポートの消去）の自動期限。
管轄区域：地域内の保管（EU専用、RU専用、BY地域など）、バケットの地理的分離。

9）使用パターン

9.1ログとテレメトリー

ホット：最後の24-72 NVMeのElasticsearch/ClickHouseでh。
暖かい：S3のSSD/HDD+Parquetの30-180日。
寒さ：氷河で>180日；Trino/Prestoでのリクエストは「オンデマンド」です。

9.2トランザクション/注文

Hot： OLTPデータベース（PostgreSQL/MySQL）と短い履歴。
Warm： BI用の非正規化スナップショット。
Cold：法的アーカイブ、オブジェクトストレージへのエクスポート。

9.3 ML-ficestore

ホット：Redis/low-latency DBのオンライン機能。
Warm： column/objectのオフラインフィーチャー。
Cold：ソースデータセット、バージョン管理（Delta/Iceberg/Hudi）。

10）クラスターとKubernetesとの相互作用

Mark StorageClass by tier： 'gold-nvme'（ホット）、'silver-ssd'（ウォーム）、'bronze-object'（コールド）。
ホット/ウォーム/コールドワークショップのプールノード（テイン/ラベル）を計画します。
オブジェクトストレージへのリクエストの前にサイドカーキャッシュ（例えば、ローカルSSDキャッシュ）。

ポリ塩化ビニールの例

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

11）観測可能性

ダッシュボード：階層別のバイト/リクエストの分布、階層ごとのレイテンシ、ウォーム/コールドへのオフロード、コスト/月。
アラート：ヒット比ホットの減少、プロモーションレートの増加（十分なホット量があります）、暖かいことによるTTFBの増加、寒さの遅い回復（SLO違反）。

12）アンチパターン

「すべてホット」：過剰なコスト、IO過熱。
「インデックスなしの深い寒さ」：保存するには安く、読むのに高価。速いスライスパスはありません。
「No ILM」：手動転送、ヒューマンエラー。
すべてのレベルの「均一なレプリケーション・ポリシー」：過払いと不均一なRPO。
1つの計算プールにprod/archiveクエリをミックス-干渉。
冷たい雲からの「Accounted egress」：法案の驚き。

13）実装チェックリスト

• データセットの分類：SLA、アクセス頻度、ストレージ要件。
• レイヤーごとのメディアとエンジン（NVMe/SSD/HDD/Object/Archive）を選択します。
• 時間/キーパーティション、インデックス、フォーマット（Parquet/ORC/Delta）を設計します。
• ILMルール（ロールオーバー/トランジション/期限切れ）を定義し、自動化します。
• 圧縮/コーディング（ZSTD/LZ4；寒さで-より強い）。
• レプリケーション/RPO/RTOおよびDRプロシージャを定義します。
• ホットアグリゲートのキャッシュ階層とピンを設定します。
• コスト/レイテンシーメトリックと階層アラート。
• セキュリティポリシー（KMS、法的保持、地理的分離）。
• 転送しきい値（季節性、成長）を定期的にレビューします。

14） FAQ

Q：ホットとウォームの境界をどのように定義していますか？
A：要求の実質の配分に従って：「熱い働くセット」=要求の80-95％を提供するキー/党の上5-20％。失敗するのは温かい候補者だけだ。

Q：私は風邪から直接読むことができますか？
A：はい、しかし数分/時間および出口の費用の下でSLAを計画して下さい；分析の前にフラグメントを暖かい（ステージング）に送還することは、より多くの場合有益です。

Q：分析のために選ぶべき何30-180日か？
A：オブジェクト+クエリエンジン（Trino/Presto/ClickHouse）上のカラム形式（Parquet/ORC）キャッシュ；indexes/skip-dataを使ってIOを保存します。

Q：寒さからリサンプリングするときに「ウォームアップ嵐」を避ける方法は？
A：プリフェッチ/プリペアジョブ、リミットリクエスト、タイムシャーディー、リクエストコールエスケシング、ピンキャッシュを使用して暖かくします。

15）合計

Hot/Warm/Coldアーキテクチャは、アクセスプロファイルと自動ライフサイクル管理のコストマッチングです。レイヤー、パーティショニング、ILMによるSLOのクリア、合理的なレプリケーションとキャッシュ階層は「、ホット」「、ウォーム」「、手頃な価格」「、コールド」を安価かつ安全に保ちます。