時系列の保管

1）なぜ時系列のための別のアーキテクチャ

• 高い記録速度（ingest）および頻度。
• 時間範囲による読み取り（スキャン+集計/ウィンドウ関数）。
• タグの組み合わせによる爆発的なカーディナリティ。
• 保持（保存寿命制限）とダウンサンプリング（時間圧縮）の必要性。
• したがって、特別なストレージモデル、圧縮フォーマット、リクエストプロトコルです。

2）データモデルと契約メトリック

2.1ネーミングとタグ

metric_name：単数動詞/名詞（'http_requests_total'、 'cpu_usage_seconds_total'）。
labels：属性キー（'job'、 'instance'、 'dc'、 'pod'、 'status'、 'method'）。
不変量：名前のセマンティクスを変更せず、互換性のない変更でバージョン（'metric_v2'）を追加します。

2.2種類の行

ゲージ、カウンター、ヒストグラム/サマリー、イベント/スパン。
財務/密度の場合-単位と集計可能性を修正します（合計/平均）。

2.3保持とロールアップポリシー

熱い細部（秒/1-10分）→暖かい単位（5m/1h）→冷たい（1d/1w）。
カウンター-ストアレート/デリブアグリゲート。

3）記録道： 受信、緩衝、密集した

3.1インジェストパイプライン

多くの場合、ゲートウェイ/エージェントを介してスクレイプ（pull、 Prometheus）またはプッシュ（OTLP/StatsD/Graphite）。
WAL（書き込み先ログ）でバッファリングし、セグメント/ブロック（LSM風アーキテクチャ）に圧縮します。
バッチ分類と時間分類は圧縮と速度を増加させます。

3.2アウトオブオーダーやテイクの処理

公差ウィンドウ（遅延ウィンドウ、例えば5-15 min）+ポリシー：'drop | upsert | keep-last'。
'（series_id、 timestamp）'による重複排除（バージョニングまたは「最後のレコードの勝利」）。

3.3圧縮

タイムスタンプのデルタ、floatのゴリラ/XOR、整数のRLEとvarint、タグの辞書。
1-8K点の最適なブロックサイズ（「チャンク」）は、IOPSとCPUの妥協点です。

4）ストレージスキーム： TSDBとSQL/columns

4.1専用TSDB

Prometheus（ローカル、ショートリテンション、PromQL、 remote_write)。
VictoriaMetrics/M3/InfluxDB-水平スケーリング、長い保持、リモート読み取り。
ブロックフォーマットは、レンジスキャン+テンダリングの集計に最適化されています。

4.2リレーショナル/コラム・エンジン

TimescaleDB （PostgreSQL）：ハイパーテーブル、時間/スペースによるチャンク、連続集計。
ClickHouse： MergeTree/TTL/materializedビュー、優れた圧縮と時間集約。
選択-クエリ・エコシステム（SQL vs PromQL）、 参加/BI要件、チームの運用スキル。

5）スキームと例

5.1 TimescaleDB：ハイパーテーブル+連続集計

sql
CREATE TABLE metrics_cpu(
ts timestamptz NOT NULL,
host text NOT NULL,
dc text NOT NULL,
usage double precision NOT NULL,
PRIMARY KEY (ts, host, dc)
);
SELECT create_hypertable('metrics_cpu', by_range('ts'), chunk_time_interval => interval '1 day');

-- Continuous unit (5 minutes)
CREATE MATERIALIZED VIEW cpu_5m
WITH (timescaledb. continuous) AS
SELECT time_bucket('5 minutes', ts) AS ts5m, host, dc, avg(usage) AS avg_usage
FROM metrics_cpu GROUP BY 1,2,3;

-- Politicians
SELECT add_retention_policy('metrics_cpu', INTERVAL '14 days');
SELECT add_retention_policy('cpu_5m',   INTERVAL '180 days');

5.2 ClickHouse：ストレージの集約

sql
CREATE TABLE metrics_cpu (
ts DateTime,
host LowCardinality(String),
dc LowCardinality(String),
usage Float32
) ENGINE = MergeTree()
PARTITION BY toYYYYMM(ts)
ORDER BY (host, dc, ts)
TTL ts + INTERVAL 14 DAY
SETTINGS index_granularity = 8192;

-- Rollup in hourly detail
CREATE MATERIALIZED VIEW cpu_1h
ENGINE = SummingMergeTree()
PARTITION BY toYYYYMM(ts)
ORDER BY (host, dc, ts)
POPULATE AS
SELECT toStartOfHour(ts) AS ts, host, dc, avg(usage) AS usage
FROM metrics_cpu GROUP BY ts, host, dc;

5.3 Prometheus/Victoriaメトリクス：remote_write

yaml global:
scrape_interval: 15s remote_write:
- url: http://vminsert:8480/insert/0/prometheus/api/v1/write

6）カーディナリティ： ストレージを「爆破」しない方法

6.1ルール

ラベルのカーディナリティ（一意の値の数）を制限します。'user_id'、 'request_id'、 'trace_id'は含めないでください。
「multi-valued」タグ（カテゴリ→コード）を正規化します。
LowCardinalityタイプ（CH）、辞書/ラベルツリー（TSDB）を使用します。

6.2コントロールとアラート

メトリック：'series_count'、' label_values {label}'、top-N「高価な」行。
テナント/ジョブごとにカーディナリティ制限を超えた場合の書き込み失敗ポリシー。

6.3履歴/ヒストグラム

高cardinalityのために、集計物（ヒストグラムのバケツ）および前ロールアップを貯えることはよいです；集計でオンラインで計算するクオンタイル。

7）保持、ダウンサンプリング、階層型ストレージ

7.1ポリシー

熱い：秒/分の細部の3-30日。
暖かい：5m/1hの集計の90-365日。
Cold：日数の集計、Parquetによるオブジェクトストレージ（S3/Glacier）のアーカイブ。

7.2人の技術者

連続集計（タイムスケール）、実体化ビュー（CH）、保持タスク+ロールアップタスク（ビクトリア/M3/影響）。
階層型ストレージ：ローカルでは「ホットブロック」、ローカルキャッシュを持つオブジェクトでは「コールド」。

8）照会および言語

8.1 PromQL（例）

promql rate(http_requests_total{job="api",status=~"5.."}[5m])

5xx APIエラーレートを探しています。

8.ウィンドウごとに2つのSQL集計

sql
SELECT time_bucket('1h', ts) AS hour,
dc, avg(usage) AS avg, max(usage) AS pmax
FROM metrics_cpu
WHERE ts >= now() - interval '24 hours'
GROUP BY 1,2 ORDER BY 1;

8.3異常（スケッチ）

ウィンドウ統計によるZ スコア/ESD、季節性のSTL分解；結果を別の行'anomaly=1/0'に格納します。

9）統合とプロトコル

OTLP （OpenTelemetry）： metrics/trails/logs、 exporter on agent （otel-collector）→TSDB/clickhouse/object。
StatsD/Graphite：単純なカウンター/タイマー；プロキシからエッジへ、そして単一のフォーマットへの変換。
Kafka/NATS：インジェストバースト用のバッファ、バックフィル用のリプレイヤー。消費者はバチャミを書く。

text kafka(topic=metrics) -> stream processor (normalize/tags) -> CH INSERT INTO metrics_cpu FORMAT RowBinary

10）アクセシビリティ、HAおよび連邦

レプリカ/TSDB HAペアまたはPrometheusフェデレーション（地域→グローバルレベル）。
長期間のストレージと一元管理されたダッシュボードのためのリモート読み取り/書き込み。
Shard-by-label/time： ingestの均一な分布、'dc/tenant'による局所性。

11）貯蔵自体の観察可能性

11.1メトリクス

Ingest： 'samples/sec'、 'append_latency'、 'wal_fsync_ms'。
Хранение： 'blocks_count'、' compaction_queue_len'、'chunk_compression_ratio'。
'query_qps'、 'scan_bytes'、 'p95/p99_latency'、 'alloc_bytes'。
Cardinality： 'series_count'、トップラベル。

11.2 SLO

「p99 latency for 1h range ≤ 200ms at QPS ≤ 500」。

"Ingest-drop ≤ 0。01％ Xサンプル/秒の前にバースト"

「圧縮バックログ<10分」

11.3アラート

成長'series_count'> Y ％/hour。
圧縮キュー/フラッシュ>しきい値。
順不同>N％、 dedup/late-drops。

12）安全および複数のテナント

'テナント'による分離（キーのラベル、個々のテーブル/データベース、クォータ）。
ラベルの消毒（PII禁止）、サイズ/バリューコントロール。
暗号化「休息時」およびトランスポート上で「、機密」指標へのアクセスを監査します。

13）営業活動

ウォームアップとコールドスタート：キャッシュ内の「ホット」ブロックのピン、最後のN時間のプリフェッチ。
バックフィル：優先度の低い個々のパイプラインは、オンラインで混合しないでください。
スキーマバージョニング：並列書き込み（デュアル書き込み）およびその後のスイッチによるマイグレーション。
ストレージ予算：'cost_per_TB_month'の制御+カルディナリティの成長予測。

14）アンチパターン

カーディナリティが高いタグ（user_id、 uuid）→行の爆発。
保持のない「永遠の」行→制御されていない成長。
ノンバッチ/ソート録画→圧縮不良とIOPS嵐。
同じディスクプールでOLTPと長いスキャンをミックスします。
アウトオブオーダーポリシーの欠如→重複と膨らみ。
何百ものバケットを持つヒストグラム→利益なしで10 ×コスト。

15）実装チェックリスト

• メトリクス、そのタイプと単位を定義する。名前/ラベル契約を修正しました。
• Engine （TSDB vs SQL/Column）とQuery Language （PromQL/SQL）を選択します。
• 保持/ロールアップ（ホット/ウォーム/コールド）とILMを設計します。
• ingest： WAL/batches/sorting、 out-of-orderウィンドウを設定します。
• 圧縮（デルタ/XOR/RLE）、最適なチャンクをオンにします。
• cardinalityを制御する：クォータ、アラート、オプトアウトポリシー。
• HA/フェデレーションとリモート書き込み/読み取りを構成します。
• SLOダッシュボードとストレージメトリック（ingest/query/storage）。
• セキュリティ/テナントの分離ポリシーとラベルのPIIの欠如。
• 通常の「ゲームの日」：バックフィル、ノードの損失、インジェストサージ。

16） FAQ

Q：インフラ監視のために何を選ぶべきですか：PrometheusかClickHouse/Timescaleか？
A：ネイティブモニタリングとPromQL-Prometheus+長期ストレージ（Victoria/M3）。BI/warehouseシナリオとSQL-Timescale/ClickHouseの場合。

Q：重い要約なしで量子を貯える方法か？
A：きちんとしたバケツが付いているヒストグラムを使用し、要求されたとき量子を計算して下さい；または集計のt ダイジェスト/CKMS。

Q：順序を取扱う方法か？
A：許容の窓（5-15分）および決定論的なdedupの方針を入力して下さい；モバイル/エッジからのテレメトリー-ウィンドウが広くなります。

Q：ロールアップはいつ必要ですか？
A：常に>30-90日：集計は10-100 ×サイズを減らし、分析を加速します。

Q：ログとメトリックを混在させることは可能ですか？
A：別々に保存します（フォーマット/クエリは異なります）。相関関係については、Exemplar/TraceIDとダッシュボードを使用しますが、すべてを1つのテーブルに追加することはできません。

17）合計

効果的な時系列ストレージは、メトリクスcontract+tag規律、有能なingest （WAL/compaction）、圧縮、および保持/ロールアップポリシーです。カルディナリティコントロール、NA/フェデレーション、店舗自体の可視性を追加すると、予測可能なP95、数ヶ月から数年の間の合理的なコスト、およびサージ抵抗性が得られます。