# Prometheus TSDB ## 定義 Prometheus に内蔵された時系列ストレージエンジン。時系列データを効率的に収集・圧縮・クエリするために設計されている。HEAD(インメモリ)とディスクブロックの 2 層構造をとる。 (Source: [[@2026__SREcon26Americas__Unlock High-Frequency Deployments without Blowing Up Prometheus]]) ### ストレージ構造 ``` RAM: [HEAD (アクティブ時系列の最新チャンク)] Disk: [WAL] [M-map chunks] [Block 1] [Block 2] ... [Block N] ``` - **HEAD**: スクレイプされた最新データを保持するインメモリバッファ。デフォルト 2 時間分の保持後にディスクへ flush - **WAL (Write-Ahead Log)**: HEAD への書き込みを先行ログに記録してクラッシュ耐性を確保 - **M-map chunks**: HEAD の古いチャンクをメモリマップしてディスクに配置(メモリ節約) - **Block**: 一定期間のデータをイミュータブルなディレクトリ形式で保持 ### 時系列の識別 時系列 = ラベルセット(文字列のキーバリューペア集合)でユニークに識別される。 ``` http_requests_total{job="nginx", instance="1.2.3.4:80", status="200"} 28 ``` ラベルセットが 1 つでも異なれば別の時系列として記録される。これがシリーズチャーン問題の根本原因。 ## 横断的知見 - 現時点では単一ソース([[@2026__SREcon26Americas__Unlock High-Frequency Deployments without Blowing Up Prometheus]])のみ。追加ソースで更新予定。 ## 未解決の問い - HEAD flush を 2 時間に固定している設計上の理由・歴史的経緯は何か - [[VictoriaMetrics]] や [[Mimir]] との内部アーキテクチャの差異はどこにあるか ## 関連 - [[Prometheus]] / [[Prometheusシリーズチャーン]] - [[@2026__SREcon26Americas__Unlock High-Frequency Deployments without Blowing Up Prometheus]] ## 出典 - [[@2026__SREcon26Americas__Unlock High-Frequency Deployments without Blowing Up Prometheus]]