# 時系列データベース ## 定義 時系列データベース(TSDB)は、(1) timestamp・value・任意の tags からなる行を保存し、(2) 複数の時系列をまとめて保存し、(3) 行をクエリでき、(4) クエリに timestamp / 時間範囲を含められる DBMS(Bader らの定義)。時系列は「系列識別子 + (timestamp, value) のデータ点列」で表される。([[Scaling Telemetry Workloads in Cloud Applications]]) アーキテクチャは 2 系統に大別される: **TSDA(Time Series Data-Intensive Application)** は汎用 DBMS(HBase/Cassandra 等の KVS)上に取り込み/クエリのインタフェースを載せたアプリ(OpenTSDB・KairosDB)で、自動クラスタ管理を活かし運用が楽。**TSDBMS(Time Series DBMS)** は時系列特化のストレージエンジンを持つ DBMS(Gorilla・InfluxDB・Prometheus・VictoriaMetrics)で、Gorilla 圧縮等で高い取り込み率を出すが運用は自前。([[Scaling Telemetry Workloads in Cloud Applications]]) ## 横断的知見 - **RRD 設計（ラウンドロビン型）は固定サイズ・ローリング・精度劣化の三位一体で「ディスク使用量の予測可能性」を最優先する**: [[Graphite]] の whisper は固定サイズファイルに複数 archive（精度×保持期間の組）を持ち、古いデータを Rollup Aggregation で粗精度（例: 1 分→10 分平均）に変換することでディスク増大を防ぐ。この設計は「容量計画が単純」「データ保持期間が明確」という運用利点を持つ反面、高精度の過去データは失われる——この制約が、追記型+TTL tiering（[[Gorilla]]・[[HeteroTSDB]]）や前処理ダウンサンプリング（[[Lindorm TSDB]]）などの後継アプローチへの移行動機となった。[[Mackerel]] は 2018 年に whisper/Graphite から [[HeteroTSDB]] へ移行しており、RRD 型から追記型への現実の移行事例として参照できる。(Source: [[@2015__yuuk.io__High-Performance-Graphite]]) - **RRD 設計は「監視ドメインで生まれた」時系列ストレージであり、汎用 TSDB の先祖にあたる——2011 年の産業実務がこの起源を裏づける**: 本ページが引用する whisper(Graphite)の RRD 型設計(固定サイズ・ローリング・精度劣化)は 2015 年時点の議論だが、[[@2011__OReillyJapan__ウェブオペレーション - Chapter 3 インフラとアプリケーションのメトリクス]] は 2011 年時点で RRD(ラウンドロビンデータベース)を「メトリクス保存のデファクトスタンダード」と述べ、[[Ganglia]] の `gmetad` が RRDtool の RRD にデータを保存する実装を詳述する。すなわち RRD 型設計は 2015 年の Graphite 固有の選択ではなく、2000 年代の HPC/クラスタ監視(Ganglia は 1999-2000 年に UC Berkeley で誕生)から継承された、監視ドメイン全体で共有された設計規範だったことが分かる。「容量計画が単純」「過去の高精度データは失われる」という whisper の特性評価は、Ganglia の RRD 運用にもそのまま当てはまる——1 時間を過ぎると時間分解能が下がり、過去には戻れない(§3.1)という 2011 年の記述は、2015 年の whisper 分析が指摘した制約を 4 年先取りしていた。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 3 インフラとアプリケーションのメトリクス]] §3.1, §3.9.2.5, [[@2015__yuuk.io__High-Performance-Graphite]]) - **gmond の UDP・非信頼配送設計は、Monarch・Gorilla が形式化する「一貫性より可用性」という CAP トレードオフを、15 年前の実運用として先取りしていた**: [[Monarch]](2020)は「アラートが正確なデータより届くことの方が重要」という監視ドメイン固有の優先順位から可用性(A)を一貫性(C)より優先すると明示し、[[Gorilla]] も書き込み失敗より部分データ返却を優先する。[[Ganglia]] の `gmond` はクラスタ内メトリクス送信に UDP を採用し、「ベストエフォートで信頼性の保証はない」(表3-3)ことを設計時点で受け入れている——パケットロスをリトライで救うのではなく、収集インターバルごとの次回送信で自然に上書きされることを前提にした設計である。これは分散システムのメトリクス収集において「配送の信頼性より鮮度・低オーバーヘッドを優先する」というトレードオフが、プラネットスケール TSDB が明示的に定式化する 2020 年より 15 年以上前から、実務上のデファクトとして選択されていたことを示す。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 3 インフラとアプリケーションのメトリクス]] §3.9.2.3, [[@2020__VLDB__Monarch - Google's Planet-Scale In-Memory Time Series Database]] §1) - **シングルスレッド書き込みデーモンとマルチコアスケーリングの解はクラスタシャーディングだが、多段構成は可用性・保守性トレードオフを生む**: [[Graphite]] の carbon-cache は Twisted ベースで 2 スレッド上限のため、スケールアウトには carbon-relay + consistent-hashing で複数プロセスに分散する必要がある。しかし多段 relay 構成は全体の可用性を下げ、メンテナンスを複雑にする——著者評「多段になればなるほど全体としての可用性やメンテナンス性は落ちる」。これは[[HeteroTSDB]] がマルチコアスケールを単一プロセスアーキテクチャで解決しようとした動機の一つだ。(Source: [[@2015__yuuk.io__High-Performance-Graphite]]) - **多数ファイルへの全方位書き込みはカーネルページキャッシュの圧迫・スラッシングを引き起こし、posix_fadvise より「メモリ増強」が実際の解になりやすい**: whisper の全方位書き込みパターン（多数の小ファイルへのランダムシーク）では posix_fadvise DONTNEED でページキャッシュ削除を試みても部分的効果に留まる。O_DIRECT は Python バッファのアライメント制約で実装困難。本番では**メモリ増強**が採用解となった。これは「ディスク I/O 最適化より先にメモリを足す」という実践的判断の実証事例であり、抽象的チューニング指針より運用上の実態を示す。(Source: [[@2015__yuuk.io__High-Performance-Graphite]]) - **インメモリ TSDB の設計は「直近データの鮮度」と「過去データの省コスト保持」の分離を前提とする**: Gorilla（[[@2015__VLDB__Gorilla - A Fast, Scalable, In-Memory Time Series Database]]）はクエリの 85% 以上が直近 26 時間を対象とする実測に基づき、26 時間分の全量をインメモリに保持し、それより古いデータは HBase（ディスク）へ委譲する。Karumuri ら（[[@2021__SIGMOD Record__Towards Observability Data Management at Scale]]）はクエリの 97% 超が直近 24 時間を対象とする Slack の実測でも同じ「鮮度バイアス」を確認し、リアルタイム層・永続ストレージ層・ホットデータキャッシュの 3 層分離を提案した。「何時間をインメモリにするか」は組織とデータ量によって異なるが、階層分離の哲学は共通する。（Source: [[@2015__VLDB__Gorilla - A Fast, Scalable, In-Memory Time Series Database]], [[@2021__SIGMOD Record__Towards Observability Data Management at Scale]]） - **TSDB の圧縮スキームは時系列の物理的性質（固定間隔到着・隣接値の類似性）を前提に設計される**: Gorilla（[[@2015__VLDB__Gorilla - A Fast, Scalable, In-Memory Time Series Database]]）のデルタ・オブ・デルタ圧縮はタイムスタンプの 96% を 1 ビットに圧縮し、XOR 浮動小数点圧縮は値の 51% を 1 ビットに圧縮して、合計 12 倍（16 バイト → 1.37 バイト/点）を達成した。この「Gorilla 圧縮」は後続の [[HeteroTSDB]]（[[Scaling Telemetry Workloads in Cloud Applications]]）でも Flusher がディスク KVS への書き出しに採用しており、事実上の監視 TSDB 圧縮標準として機能している。（Source: [[@2015__VLDB__Gorilla - A Fast, Scalable, In-Memory Time Series Database]], [[Scaling Telemetry Workloads in Cloud Applications]]） - **「オブザーバビリティ TSDB」の設計はリアルタイム層と履歴層の分離が原則となる**: Karumuri ら([[@2021__SIGMOD Record__Towards Observability Data Management at Scale]])は Slack の実測データでクエリの 97% 超が <24h データを対象とすることを示し、リアルタイム層(Real-Time Indexing)・永続ストレージ層(Persistent Storage, S3 等)・ホットデータキャッシュ(Hot Data Cache)の 3 層に分ける ODMS ポリストア型アーキテクチャを提案した。各層を独立弾力的にスケールすることで、バースト書き込み時は Indexing を、歴史クエリ集中時は Hot Cache を個別スケールアップできる。この方向性は [[HeteroTSDB]] の TTL ベース tiering と同じ「データ年齢ベースの層分け」哲学と合流する。(Source: [[@2021__SIGMOD Record__Towards Observability Data Management at Scale]] §4) - **インデックス構造の選択が取り込みスケーラビリティを決める**: disk-based KVS はソート指向の tree 系インデックス(balanced tree / skip-list)で、多数キーの挿入が対数時間でボトルネック化する。hash table は定数時間で挿入できるがランダムアクセスゆえ memory-based DB 向き。[[HeteroTSDB]] はこの非対称性を逆手にとり、memory-KVS(hash table・高速挿入)と disk-KVS(低コストの長期保持)を **TTL ベースの自動 tiering** で federate して両取りする。([[Scaling Telemetry Workloads in Cloud Applications]]) - **保持する DB と予測するモデルが同じ観測時系列を別軸で扱う**: TSDB(本概念)は観測テレメトリの「取り込み・保持・範囲クエリ」を効率化する。[[時系列基盤モデル]]([[Toto]]・[[Falcon-X]])は同じ観測時系列の「ゼロショット予測」を担う。[[BOOM]] は本番テレメトリを予測ベンチマーク化したが、そのテレメトリを生成・保持する側が TSDB であり、両者は観測データのライフサイクルの別段を占める(保持 → 予測)。(Source: [[Scaling Telemetry Workloads in Cloud Applications]], [[@2025__NeurIPS2025__This Time is Different - An Observability Perspective on Time Series Foundation Models]]) - **TSDB 効率化には「取り込み最適化」と「クエリ最適化」の 2 軸があり、両者は直交する**: [[HeteroTSDB]] はインデックス構造の選択(hash table vs balanced tree)と TTL tiering で**取り込み**スケーラビリティを攻める。一方 [[PromSketch]] は同じ [[Prometheus]]/[[VictoriaMetrics]] 系 TSDBMS の**クエリ側**ボトルネック——周期ルールクエリが重複ウィンドウを繰り返しスキャン・再計算する点——を中間結果キャッシュで攻める。VictoriaMetrics は CPU 時間の 80.2% を Data Scanning に費やすという測定が、ストレージエンジン改善だけでは取りきれないクエリ側の冗長性を裏づける。取り込み最適化はクエリ冗長性を減らさず、クエリ最適化は取り込み率を上げない。(Source: [[Scaling Telemetry Workloads in Cloud Applications]], [[@2025__VLDB__Approximation-First Timeseries Monitoring Query At Scale]]) - **近似は TSDB のコスト-精度トレードオフを開く第 3 の軸**: 既存 TSDBMS(Prometheus/VictoriaMetrics)は厳密クエリを前提に取り込み・ストレージ・並列化で速くする。[[PromSketch]] は「ダウンストリーム(アラート・オートスケール)は 5% 程度の誤差を許容する」という前提を突き、スケッチで運用コストを 2 桁削減する。厳密性を要件から外せるかどうかが、TSDB 最適化の到達点を分ける。(Source: [[@2025__VLDB__Approximation-First Timeseries Monitoring Query At Scale]]) - **ドメイン固有 TSDB の「ビルトイン解析」は汎用 TSDB に対して 73〜97% のランタイム短縮をもたらす第 4 の軸**: [[Chronix]]（[[@2017__FAST__Chronix - Long Term Storage and Retrieval Technology for Anomaly Detection in Operational Data]]）は、汎用 TSDB が持たないドメイン固有の高水準解析関数（outlier・trend・frequency・sax・fastdtw）をサーバーサイドで実行することで、クライアントサイド模倣（追加クエリ + クライアント処理）と比べて 73〜97% のランタイム短縮を達成した（表8）。これは [[HeteroTSDB]] の「取り込み最適化」、[[PromSketch]] の「クエリ冗長性最適化」、[[PromSketch]] の「近似」とは独立した第 4 の軸——ストレージとアプリケーション解析の**協調設計（co-design）**——を示す。InfluxDB がサーバーサイドの事前計算値（avg・max 等）を持つ場合は Chronix を上回ることがあり、「サーバーサイド実行の有無」が生データ転送コストの支配因子になる。(Source: [[@2017__FAST__Chronix - Long Term Storage and Retrieval Technology for Anomaly Detection in Operational Data]] §5) - **汎用データモデルの欠如（ログ・トレースの非数値型サポートなし）が異常検知の探索性を制約する**: Chronix（[[@2017__FAST__Chronix - Long Term Storage and Retrieval Technology for Anomaly Detection in Operational Data]]）は 2017 年に、汎用 TSDB（InfluxDB・OpenTSDB・KairosDB）が数値スカラー値しか扱えないため `lsof`・`strace` データをタグ/タイムスタンプに強制エンコードせざるを得ず、ナノ秒精度の欠落・コード追加・クエリ意味の歪みを招くことを実証した（§5 Storage Efficiency）。これは 2021 年の ODMS（Karumuri ら）が「MELT（Metrics/Events/Logs/Traces）の統合管理」を要件とした問題意識と直接接続する——4 年後の ODMS ビジョンが回答しようとした問題を、ドメイン固有 TSDB はストレージレイヤーの設計で先取りしていた。(Source: [[@2017__FAST__Chronix - Long Term Storage and Retrieval Technology for Anomaly Detection in Operational Data]] §5, [[@2021__SIGMOD Record__Towards Observability Data Management at Scale]]) - **超高次元監視 TSDB では「データ点の圧縮」より「メタデータ(系列キー)の圧縮」がボトルネックになる**: [[ByteSeries]]([[@2020__SoCC__ByteSeries - An In-Memory Time Series Database for Large-Scale Monitoring Systems]], SoCC 2020)の実測では、[[ByteDance]] の本番メトリクス監視システム(100 億次元超)においてメタデータ(系列キー・タグ)がメモリの 80% 以上を占める。Gorilla([[@2015__VLDB__Gorilla - A Fast, Scalable, In-Memory Time Series Database]])の設計知見は「データ点の XOR 圧縮」に焦点を当てているが、次元数が 1000 倍以上になると系列キーの増大がデータ点圧縮の利益を凌駕することを ByteSeries は定量化した。Compressed Inverted Index(double-array trie + p4nzenc64 整数圧縮)によりメタデータを 60% 削減する一方でデータ点には同じ Gorilla XOR 圧縮を採用しており、「メタデータ問題は高次元監視固有」という認識が出発点にある。(Source: [[@2020__SoCC__ByteSeries - An In-Memory Time Series Database for Large-Scale Monitoring Systems]] §1-§3) - **多次元 group-by クエリに最適化したインデックスはデータ圧縮と集計を統合できる**: 汎用 TSDB のインデックスはレンジクエリ(1 次元)向けに設計されており、「`env=prod` かつ `region=us` かつ `service=auth` の全次元の p99」のような多次元 group-by では一致する系列キーをスキャン・フィルタしてからデータ集計する。[[ByteSeries]] の Compressed Inverted Index は系列キーの各タグ値→次元オフセット配列の構造であるため、group-by 軸に沿った倒立索引参照でオフセット集合をそのまま得られ、デコード前に集合演算(AND/OR)が完結する。これにより既存システム比で 1.8〜10.7 倍の多次元クエリ高速化を実現した。圧縮と集計のデータ構造一致が性能向上の核心であり、これは [[Chronix]] の「ビルトイン解析と co-design」論理の延長線上にある。(Source: [[@2020__SoCC__ByteSeries - An In-Memory Time Series Database for Large-Scale Monitoring Systems]] §3-§4) - **Active Buffer → Static Segment → Compressed Segment の段階的変換はデータ構造最適化のコストを取り込みから切り離す設計パターンである**: ByteSeries の Data Conversion Scheduler(DCS)はバックグラウンドスレッドで AS→SS の軽量変換(Compactor)・SS→SS のマージ(Merge Processor)・SS→CS の完全圧縮(Compressor)を行い、取り込みスレッドと分離する。これは Gorilla が「取り込みとメモリ管理を同一スレッドで行う」ことで生じるスパイクを回避する構造であり、HeteroTSDB が TTL ベースで memory-KVS→disk-KVS に非同期的にフラッシュするフロントエンド/バックエンド分離と同じ設計哲学を別次元(メモリ内圧縮段)で適用したものだ。(Source: [[@2020__SoCC__ByteSeries - An In-Memory Time Series Database for Large-Scale Monitoring Systems]] §4, [[Scaling Telemetry Workloads in Cloud Applications]]) - **共有なし + 共有ストレージのハイブリッドは「ノードスケーリング時のデータ移動ゼロ」と「any-node からの全データアクセス」を同時に実現する第 5 の軸**: 純粋共有なし TSDB（TDengine・Monarch 等）はノード増設時にデータ再分散が必要で I/O 圧力が高い。純粋共有ストレージ型はスケーリング容易だが計算ノード間でのキャッシュ競合が起きやすい。[[Lindorm TSDB]]（[[@2023__PVLDB__Lindorm TSDB - A Cloud-native Time-series Database for Large-scale Monitoring Systems]]）は「タイムスタンプ軸でシャードグループを切る」設計により過去データを移動せず新シャードグループを追加するだけでスケールアウトできる（Figure 3）。結果として Figure 11b が示すようにノード追加前後でスループット変化なし、かつ 2→4→6 ノードで直線以上のスケール（Table 11: 2 ノード 5.05 M/s → 4 ノード 11.55 M/s → 6 ノード 19.78 M/s）を達成した。これは「取り込み最適化（HeteroTSDB）」「クエリ冗長性最適化（PromSketch）」「近似（PromSketch）」「ビルトイン解析 co-design（Chronix）」に続く第 5 の軸——エラスティックなアーキテクチャ分離——を示す。(Source: [[@2023__PVLDB__Lindorm TSDB - A Cloud-native Time-series Database for Large-scale Monitoring Systems]] §4.1・Figure 3・Figure 11・Table 11) - **書き込み時集計（前処理ダウンサンプリング）はクエリレイテンシを 80% 削減しストレージ代償を 8% に収める書き込み/クエリトレードオフの具体例**: [[Lindorm TSDB]] は書き込み時に 1 分・10 分・60 分等の集計値を事前計算してストレージに保持する（Lindorm TSDB §4.4 Pre-downsampling）。`SAMPLE BY 30min` のようにキャッシュされた粒度の倍数になるクエリも上位集計を組み合わせて元データスキャンを回避できる。本番導入でクエリレイテンシ 80% 削減・ストレージ増加 8%・CPU 増加 5% 未満を確認（Lessons Learned §7）。InfluxDB の Continuous Query（クエリ時間ごとに実行する push 型集計）と異なり、コンパクション時にのみ計算するため取り込みパスへの影響が最小。これは「書き込みコストを先払いしてクエリを後払いゼロにする」設計であり、取り込みスループット重視のワークロードとクエリレイテンシ重視のワークロードが共存する監視系 TSDB の代表的なトレードオフ選択である。(Source: [[@2023__PVLDB__Lindorm TSDB - A Cloud-native Time-series Database for Large-scale Monitoring Systems]] §4.4・§7) - **インデータベース ML は時系列 ML の推論・訓練コストをネットワーク転送排除で約 2 倍短縮できることを大規模本番で実証した**: 既存の Oracle ML・Azure Data Explorer・BigQuery ML はリレーショナルデータモデル向けであり、時系列特有の「大量の homogeneous 時系列を同一アルゴリズムで並列処理する」特性を活かしていない。[[Lindorm TSDB]] の Lindorm ML は TrainingOp・InferenceOp をパイプライン演算子として組み込み、TSCore にプッシュダウンすることで生データを外部転送せず near-data 訓練・推論を実現する（§5）。Table 8 が示すように OneShotSTL 異常検知で外部 ML 実行比 1.86〜2.17× の速度向上（規模が大きいほど差が拡大）。これは「TSDB の機能をストレージ+クエリから分析まで拡張する」方向性の実証であり、[[時系列基盤モデル]] の推論を TSDB に組み込む可能性（未解決の問い）への具体的先行事例となる。(Source: [[@2023__PVLDB__Lindorm TSDB - A Cloud-native Time-series Database for Large-scale Monitoring Systems]] §5・Table 8) - **産業用ワークロードに特化したベンチマークは、IT 監視向けに設計された TSDA が産業用途で壊滅的に失敗しうることを露わにした**: Goldschmidt ら(IEEE CLOUD 2014、[[@2014__IEEE CLOUD__Scalability and Robustness of Time-Series Databases for Cloud-Native Monitoring of Industrial Processes]])はスマートグリッドドメインの PMU Write・SmartMeter Write ワークロードで 3 OSS TSDB を評価し、OpenTSDB(HBase バックエンド)がデータ量依存のメモリ不足により再現可能な測定さえできなかったことを報告した。これは YCSB 等の汎用 NoSQL ベンチマークでは検出されない「産業ワークロードの高持続書き込み密度」という特性が、TSDA のメモリ管理設計の欠陥を顕在化させることを示す。IT 監視向けに設計されたシステムは産業用途で失敗しやすく、ドメイン固有ベンチマークが選定の必須要件になる。(Source: [[@2014__IEEE CLOUD__Scalability and Robustness of Time-Series Databases for Cloud-Native Monitoring of Industrial Processes]] §V-A, [[@2023__PVLDB__TSM-Bench - Benchmarking Time Series Database Systems for Monitoring Applications]] §1) - **TSDA の自己防衛(バックプレッシャー)設計品質が産業用途での信頼性を決定する**: Goldschmidt ら(IEEE CLOUD 2014)の評価では、[[KairosDB]] は Cassandra のキュー状態を監視してクライアントの応答時間を自然に増やすことでスロットリングを実現し、過負荷時もグレースフルデグラデーションを示した。一方 [[OpenTSDB]] はバックエンド(HBase)が機能不全になってもクライアントへの通知なく受け入れを続けた。この「バックプレッシャー(back-pressure)の有無」は TSDB ベンチマークの標準指標(TSM-Bench の 7 クエリ型)には含まれていないが、産業用途の連続書き込みシナリオでは根本的な選定基準になる。(Source: [[@2014__IEEE CLOUD__Scalability and Robustness of Time-Series Databases for Cloud-Native Monitoring of Industrial Processes]] §V-A・§V-B, [[@2023__PVLDB__TSM-Bench - Benchmarking Time Series Database Systems for Monitoring Applications]]) - **単一のアーキテクチャがすべてのワークロードで最適にはなれない——クエリ選択性・データセット規模・挿入レートの 3 軸が最良設計を決定する**: TSM-Bench の 7 システム比較（ClickHouse・Druid・eXtremeDB・InfluxDB・MonetDB・QuestDB・TimescaleDB）で定量的に確認された。オフラインでは eXtremeDB のシーケンス格納がフィルタ・集計・ウィンドウ操作で最速だが、多系列データセット(D-MULTI)ではジョイン処理が遅くなる。ClickHouse はスパースインデックス+SIMD で大規模高選択性クエリに強いが、eXtremeDB の低選択性クエリには劣る。高挿入レートではInfluxDB のLSM ツリーが最も安定する。(Source: [[@2023__PVLDB__TSM-Bench - Benchmarking Time Series Database Systems for Monitoring Applications]] §5・§6) - **オンラインワークロード（同時挿入＋クエリ）は TSDB のアーキテクチャの隠れた弱点を顕在化させる**: オフライン評価では競争力があった eXtremeDB はオンライン挿入時に「シーケンス末尾への付加」でクエリ不安定性を示し、TimescaleDB は非圧縮データを読み返すコストでクエリが遅延する。InfluxDB・MonetDB は高挿入レートでもクエリを維持する。監視アプリケーションの選定にはオンラインワークロード評価が必須。(Source: [[@2023__PVLDB__TSM-Bench - Benchmarking Time Series Database Systems for Monitoring Applications]] §5.3) - **監視 TSDB は CAP トレードオフで「AP」を選び、一貫性をデータ部分欠落として許容する**: [[Monarch]]([[@2020__VLDB__Monarch - Google's Planet-Scale In-Memory Time Series Database]])は可用性(A)を一貫性(C)より優先する設計を明示し、遅延書き込みを棄却しクロスゾーン・クエリは部分データを返す可能性を許容する。根拠は「アラートが正確なデータより届くことの方が重要」という監視ドメイン固有の優先順位だ。この方針は [[Gorilla]] の「書き込み失敗より部分的なデータを返す」方針と同根であり、CP 型(強一貫性)の汎用 TSDB が監視用途で選ばれにくい理由を説明する。(Source: [[@2020__VLDB__Monarch - Google's Planet-Scale In-Memory Time Series Database]] §1) - **プラネットスケール監視 TSDB はインメモリを選ばなければ「循環依存」の罠に落ちる**: [[Monarch]] が Bigtable や Spanner などの永続ストレージに依存しないインメモリ設計を採る理由は、「すべての Google ストレージシステムが Monarch に依存しているため、Monarch が外部ストレージに依存すると循環依存が生じ可用性を損なう」という構造的必然による。これはプラネットスケール監視 TSDB に固有の制約であり、単一リージョン・中小規模の TSDB には存在しない問題だ。Gorilla が Facebook のプライマリ TSDB として HBase(永続)と切り離してインメモリ層のみを担う設計とは異なる motivation だが、「インメモリ = 高可用性の第一の砦」という帰結は共通する。(Source: [[@2020__VLDB__Monarch - Google's Planet-Scale In-Memory Time Series Database]] §1) - **Collection Aggregation(36:1 圧縮)はプラネットスケール TSDB で raw 系列数の爆発を防ぐ取り込み側の構造的解**: [[Monarch]] の Collection Aggregation は、複数の raw 時系列(delta + バケット + admission window)を 1 系列に集約し平均 36:1 の圧縮を達成する。代替手法(事前集約なし)比で CPU を 25% まで削減し、ゾーン内 Leaf の系列数を管理可能に保つ。これは [[ByteSeries]] の「メタデータ 60% 削減」とは設計軸が異なる——ByteSeries は取り込み済み系列のメタデータ表現を圧縮するが、Monarch は取り込み前に系列数そのものを削減する。観測単位(raw 系列 vs 保存系列)をどこで定義するかが TSDB のスケーリング戦略の分岐点になる。(Source: [[@2020__VLDB__Monarch - Google's Planet-Scale In-Memory Time Series Database]] §5) - **FHI(Field Hints Index)はプラネットスケール・クエリファンアウト抑制の実用解であり、数 GB 以下のトライグラムインメモリ索引が 99.5% のファンアウトを除去する**: [[Monarch]] の Field Hints Index(FHI)は target フィールドのトライグラムを Ingestion Router がインデックス化し、クエリ時にマッチしない Leaf・zone を事前枝刈りする。ゾーンレベルで 99.2〜99.6%、ルートレベルで 75.8% のファンアウトを抑制し、最大ゾーンでもインデックスサイズは 808 MB に収まる。[[ByteSeries]] の Compressed Inverted Index がメモリ内の多次元クエリを高速化するのと類比的だが、FHI は TSDB 内部のデータ構造ではなくクエリルーティング層の索引であり、目的はデータ転送量そのものの削減だ。(Source: [[@2020__VLDB__Monarch - Google's Planet-Scale In-Memory Time Series Database]] §6.3・Table 2) - **クエリプッシュダウン(95% がゾーン完結)は監視 TSDB をネットワーク分断耐性にする最も効果的な手法**: [[Monarch]] の Query Pushdown は、standing query の 95% をグローバル query エンジンを経由せずにゾーン内で評価し完結させる。これにより ゾーンが global plane から分断されていても監視・アラートが継続する。評価される standing query のうちゾーン評価 95%・global クエリ 5% と、leaf/zone への計算プッシュダウンが圧倒的多数を占める(Table 3)。クロスゾーン集計が必要なアドホック診断クエリは global plane を経由せざるを得ないが、アラート等の定常クエリはゾーン完結で信頼性を確保する——この目的別クエリ経路の二重化は障害耐性設計の重要なパターンだ。(Source: [[@2020__VLDB__Monarch - Google's Planet-Scale In-Memory Time Series Database]] §6.2・Table 3) - **リレーショナル時系列データモデル(Target schema + Metric schema + distribution 型)はアドホック診断の表現力を大幅に向上させる**: [[Gorilla]]・[[Prometheus]] 等はラベルセット(文字列 key-value)でメトリクスを識別する平坦なモデルを採る。[[Monarch]] はリレーショナルスキーマ(テーブル定義 = Target schema × Metric schema)を導入し、同一 target に属する複数メトリクスの intra-target join を Leaf レベルで完結させる(辞書順シャーディングの性質による)。さらに distribution をファーストクラス値型としてヒストグラム + Exemplar(バケットごとの代表トレース)を格納でき、99 パーセンタイルレイテンシなどの統計的解析が単一クエリで完結する。スキーマ化とクエリ言語の表現力向上が、プラネットスケール TSDB に「分析基盤」としての性格を与えることを示す最初の大規模実証だ。(Source: [[@2020__VLDB__Monarch - Google's Planet-Scale In-Memory Time Series Database]] §3・§4) - **「協調そのものの回避」は、取り込み最適化・クエリ最適化・近似・ビルトイン解析・エラスティック分離に続く第 6 の軸である**: [[Mach]]([[@2022__CIDR__Mach - A Pluggable Metrics Storage Engine for the Age of Observability]])は、既存ストレージエンジンが複数ライターを mutex で協調させる設計を採り、この mutex 獲得だけで Prometheus の書き込みオーバーヘッドの約 25% を占めることを指摘した上で、各データソースを単一ライタースレッドに固定し疎結合(loosely coordinated)に振る舞わせることで協調オーバーヘッドそのものを排除した。これは [[HeteroTSDB]] の「インデックス構造選択による取り込み最適化」や [[ByteSeries]] の「メタデータ圧縮による取り込み最適化」とは異なる軸——書き込みパスの同期プリミティブ自体を設計から除去する——であり、単一ノードで最大 480M f64/秒(既存手法の約10倍)を達成した。(Source: [[@2022__CIDR__Mach - A Pluggable Metrics Storage Engine for the Age of Observability]] §3.1) - **「読み取りが書き込みをブロックしない」設計は、逆に「書き込みが読み取りをブロックする」場合があるという非対称なトレードオフを伴いうる**: [[Mach]] のスナップショット機構は、リーダーが先頭ポインタとカウンタ値を取得するだけの短く決定的なクリティカルセクションで完結し、既存の多くのシステムのように「クエリ全体(ディスク I/O 含む)の間ロックを保持する」設計を回避する。しかし逆に、アクティブセグメントが満杯になり圧縮処理に入る際にはスナップショットロックで並行リーダーをブロックしうる——「読み取りは書き込みを非決定的にブロックしない」が「書き込みは読み取りを(圧縮中に限り)ブロックしうる」という非対称性を意図的に受け入れている。これは [[Monarch]] の「一貫性より可用性を優先しデータ欠落を許容する」設計判断や [[Gorilla]] の「書き込み失敗より部分データ返却を優先する」判断と同様、鮮度バイアスの強い監視ワークロードに特化したトレードオフ選択の一例である。(Source: [[@2022__CIDR__Mach - A Pluggable Metrics Storage Engine for the Age of Observability]] §3.4) - **アクティブセグメント単位の一括圧縮は、Gorilla 系の「サンプル到着ごとの逐次圧縮」に対するもう一つの設計軸を示す**: Gorilla・ByteSeries はサンプル到着のたびに XOR/デルタ圧縮を適用するのに対し、Mach は 256 サンプル(既定)のアクティブセグメントが満杯になった時点でセグメント全体を一括圧縮する。これによりコストが多数サンプルに償却されるが、セグメントが満杯になるまで対象データは非圧縮のままインメモリに滞留する。「即時圧縮でメモリ使用量を抑えるか、遅延一括圧縮で圧縮率とスループットを取るか」は書き込みパス設計のもう一つの分岐点であり、多変量データではこの遅延一括圧縮の恩恵がさらに大きくなる(値がまとまって償却されるため)。(Source: [[@2022__CIDR__Mach - A Pluggable Metrics Storage Engine for the Age of Observability]] §3.3) - **ストレージ構造そのものをインデックス化する設計は、Monarch の FHI や ByteSeries の Compressed Inverted Index のような「別置きインデックス」に対するもう一つの軸を示す**: [[BTrDB]]([[@2016__FAST__BTrDB - Optimizing Storage System Design for Timeseries Processing]])は、時間区分・バージョン注釈付き copy-on-write の k-ary ツリーそのものをストレージとインデックスの両方として使う。内部ノードに min/mean/max/count の統計サマリを埋め込むため、統計クエリは指定解像度のノード数にのみ比例した対数時間で完結し、別途インデックス構造(トライグラム索引・倒立索引)を構築・同期する必要がない。[[Monarch]] の FHI(§6.3)や [[ByteSeries]] の Compressed Inverted Index(§3-4)は「ストレージ本体」と「クエリ加速用の副インデックス」を分離するのに対し、BTrDB は両者を統合することで副インデックスの整合性維持コストそのものを消去している。ただし BTrDB のツリーはリーフへの生ポイント到達に O(log n) を要する点で、Monarch の FHI が実現する「99.5% のファンアウト除去」のような読み取り経路の劇的な枝刈りとは性格が異なる。(Source: [[@2016__FAST__BTrDB - Optimizing Storage System Design for Timeseries Processing]] §4, [[@2020__VLDB__Monarch - Google's Planet-Scale In-Memory Time Series Database]] §6.3, [[@2020__SoCC__ByteSeries - An In-Memory Time Series Database for Large-Scale Monitoring Systems]] §3-4) - **書き込み時の統計事前計算には「別演算としてスケジュールする」方式と「ツリー更新に無償で相乗りさせる」方式の2系統がある**: [[Lindorm TSDB]] の前処理ダウンサンプリング(§4.4)は 1分・10分・60分といった固定粒度の集計をコンパクション時に別途計算し、クエリレイテンシを80%削減する代わりにストレージ8%・CPU5%未満のコストを払う。対照的に BTrDB の統計サマリ計算は、リーフ更新に伴う内部ノードのコピー(copy-on-write によりどのみち必要)に相乗りするため「free」だと明言されている(§4)――統計計算の追加コストが実質ゼロになる代わりに、対象は複数の子から導出できる結合的(associative)な演算に限られ、Lindorm のような任意粒度の再集計や機械学習パイプライン(Lindorm ML)への拡張は素朴には効かない。「事前計算をいつ・どこで相乗りさせるか」は監視 TSDB のコスト構造を分ける設計選択の一つだ。(Source: [[@2016__FAST__BTrDB - Optimizing Storage System Design for Timeseries Processing]] §4, [[@2023__PVLDB__Lindorm TSDB - A Cloud-native Time-series Database for Large-scale Monitoring Systems]] §4.4) - **「一貫性より可用性」路線とは異なる、copy-on-write による厳密な整合性保証というもう一つのトレードオフ軸がある**: [[Monarch]](§1)は一貫性(C)より可用性(A)を優先し、クロスゾーンクエリでの部分データ返却を許容する。[[Gorilla]] も書き込み失敗より部分データ返却を優先する。これに対し BTrDB は copy-on-write ツリーの性質を利用し、「統計値の計算に失敗すればルートノードが書かれずオーバーレイ全体が到達不能になる」ことで観測可能な統計が常に基礎データと整合することを保証する(§4)。可用性を犠牲にはしないが(旧バージョンは常に読める)、単一障害点である root map(§5.6)への依存というかたちで、プラネットスケールの Monarch とは異なる一貫性・可用性のバランス点を選んでいる。BTrDB は単一ノード〜小規模クラスタ(<6サーバ)を想定範囲としており(§2)、Monarch のようなグローバル分散スケールとはそもそも設計射程が異なる点に注意が必要。(Source: [[@2016__FAST__BTrDB - Optimizing Storage System Design for Timeseries Processing]] §2・§4・§5.6, [[@2020__VLDB__Monarch - Google's Planet-Scale In-Memory Time Series Database]] §1) - **バージョン注釈付きエッジによる差分計算(ComputeDiff)は、下流の分析パイプラインが「最終処理済みバージョン」という定数サイズの状態だけで整合性を保つ、既存のジャーナル再生方式に代わる設計である**: BTrDB のツリーの各リンクにはそのリンクを導入したバージョン番号が注釈され、ComputeDiff(FromVersion, ToVersion, Resolution) は生データを読まずに変更範囲を返す。これにより distillation パイプラインの各段はストリームあたり8バイトのバージョン番号のみを保持すればよく、著者らは「既存システムなら未処理操作のジャーナルを再生する必要がある水準の一貫性保証」と位置づける(§3-4・§6.4)。これは [[時系列データベース]] 概念全体で見た場合、取り込み最適化・クエリ最適化・近似・ビルトイン解析 co-design・エラスティック分離に続く**第7の軸**――「派生データ(distillate)の一貫性コストを、生データとは独立した最小限の状態で管理する」――として位置づけられる。(Source: [[@2016__FAST__BTrDB - Optimizing Storage System Design for Timeseries Processing]] §3-4・§6.4) - **高精度タイムスタンプ特有の圧縮課題は Gorilla とは異なる解法(delta-delta + Huffman)で攻められている**: [[Gorilla]] のデルタ・オブ・デルタ圧縮はタイムスタンプの96%を1ビットに圧縮するが、これは秒精度・定期スクレイプという前提に立つ。BTrDB はナノ秒精度のタイムスタンプと高精度センサ値を扱うため、単純な delta coding や run-length encoding では「大きいが類似したデルタ列」(ジッタ)を圧縮できないという問題に直面し、各デルタを「直前デルタ群の窓の平均からの差分」として符号化する delta-delta coding + 固定 Huffman 木を採用した(§5.4)。浮動小数点値は仮数部・指数部に分解して独立に圧縮する。定量的な比較評価は本文スコープ外だが、本番データで2.9倍の全体圧縮率を達成している。「精度が上がるほど既存の圧縮スキームが機能しなくなる」という制約は、[[時系列基盤モデル]]のような高頻度データを扱う後続システムにも共通する課題になりうる。(Source: [[@2016__FAST__BTrDB - Optimizing Storage System Design for Timeseries Processing]] §5.4, [[@2015__VLDB__Gorilla - A Fast, Scalable, In-Memory Time Series Database]]) - **TSDB 本体の最適化(取り込み・クエリ・近似・co-design・エラスティック分離・派生データ一貫性)とは独立に、TSDB の「前段」にセマンティックキャッシュ層を置く第 8 の軸が存在する**: 本概念の他知見はいずれも TSDB 内部のストレージ・インデックス設計を対象とするが、[[STsCache]]([[@2025__VLDB__STsCache - An Efficient Semantic Caching Scheme for Time-series Data Workloads Based on Hybrid Storage]])は TSDB を書き換えずに前段の cache-aside 層でクエリのセマンティクスと結果を再利用し、[[InfluxDB]]・[[TimescaleDB]] のスループットを 4.8-10.8 倍に押し上げる。TSDB 側の co-design(Chronix・ByteSeries)が「ストレージとアプリケーション解析の統合」を志向するのに対し、セマンティックキャッシュは TSDB を不可侵のブラックボックスとして扱う「非侵襲的な性能改善レイヤー」であり、既存 TSDB を変更できない運用環境(SaaS 版 TSDB 等)でも適用できる利点を持つ。(Source: [[@2025__VLDB__STsCache - An Efficient Semantic Caching Scheme for Time-series Data Workloads Based on Hybrid Storage]] §1, §5.3) - **append-only・write-once という時系列データの性質は、TSDB 本体だけでなく前段キャッシュの設計単純化にも寄与する**: [[Lindorm TSDB]]・[[Monarch]]・[[Gorilla]] は「一貫性より可用性」(データ欠落の許容)という形でこの性質を活かすが、[[STsCache]] は同じ append-only 性を「キャッシュコヒーレンシ機構が不要」という形で活かす——キャッシュされたクエリ結果は元データが更新・削除されない限り恒久的に有効なため、invalidation を設計から排除できる。これは一般的なセマンティックキャッシュ研究(更新頻度の高い Web・DB クエリを対象とする)には無い時系列固有の単純化である。(Source: [[@2025__VLDB__STsCache - An Efficient Semantic Caching Scheme for Time-series Data Workloads Based on Hybrid Storage]] §4.3, [[@2020__VLDB__Monarch - Google's Planet-Scale In-Memory Time Series Database]] §1) - **タグ再利用によるコスト償却という TSDB の中核前提が、オブザーバビリティの構造化イベントでは成立せず「カーディナリティ爆発」を招く——これは取り込み最適化・クエリ最適化・近似・co-design・エラスティック分離・派生データ一貫性・セマンティックキャッシュのいずれの軸でも解決できない、データモデルそのものの限界である**: 本概念のこれまでの知見(Gorilla・HeteroTSDB・Monarch 等)は、同一タグの組み合わせが繰り返し出現し新規時系列作成コストが償却されることを暗黙の前提としている。しかし *Observability Engineering* 第13章([[@2026__OReilly__Observability Engineering 2E - Chapter 13 Efficient Data Storage with Retriever]])は、各構造化イベントのタグ組み合わせがほぼ一意であるオブザーバビリティワークロードでは、この償却が成立せず行(時系列)作成のオーバーヘッドがイベント数に対して線形に発生することを指摘する。これは [[Chronix]] が 2017 年に示した「汎用データモデル(数値スカラーのみ)がログ・トレースの非数値型を表現できない」という限界(§5)とは異なる軸の限界——次元の**値**ではなく次元の**組み合わせ数**そのものが TSDB のスケーラビリティ前提を破壊する——であり、Honeycomb Retriever はこれへの回答として TSDB とは別のデータモデルである列指向ハイブリッドストア(→ [[列指向OLAPデータベース]])へ切り替える設計を取る。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 13 Efficient Data Storage with Retriever]], [[@2017__FAST__Chronix - Long Term Storage and Retrieval Technology for Anomaly Detection in Operational Data]] §5) - **「取り込み最適化」「クエリ最適化」の軸に加え、ストレージエンジンの物理設計(疎インデックス vs 配列 vs LSM vs B-Tree)が時系列の「規則性(等間隔性)」を活かせるかどうかで、同じワークロードへの適性が逆転しうる**: [[@2026__arXiv__Six Dimensions of Benchmarking Time-Series Databases]](SciTSv2)は、正則(等間隔)時系列に特化したベクターストア [[DataLayerTS]] が規則性を利用して178 MB/sの取り込みとサブミリ秒クエリを達成する一方、[[ClickHouse]] は正則データでは疎インデックスのパーツ集中によりディスク競合が増え、不規則データより取り込みレートが低下するという反直感的な結果を示した。[[InfluxDB]]・[[TimescaleDB]] のシャーディング設計は規則性からわずかな利得しか得られない。これは本概念で蓄積してきた「取り込み最適化(HeteroTSDB)」「クエリ最適化(PromSketch)」「近似(PromSketch)」「ビルトイン解析co-design(Chronix)」「エラスティック分離(Lindorm TSDB)」「派生データ一貫性(BTrDB)」「セマンティックキャッシュ(STsCache)」に続く**第9の軸**——データの物理的規則性とストレージエンジンの整合(または不整合)——として位置づけられる。(Source: [[@2026__arXiv__Six Dimensions of Benchmarking Time-Series Databases]] §6.1.1, §7) - **SLO 実装という利用者側の視点は、TSDB を「柔軟性・テスト可能性・鮮度・コスト・信頼性・組織の制約」という 6 軸で構造化イベントデータベース(ログ)と対置し、本概念のこれまでの知見が扱ってこなかった「TSDB を選ばない理由」を明示する**: 本概念のこれまでの知見はいずれも TSDB 内部のストレージ・インデックス設計(取り込み最適化・クエリ最適化・近似・co-design 等の軸)を対象にしてきたが、[[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 7 SLIとSLOの計測]] は SLO を実装するアプリケーション側から TSDB を評価する。TSDB は柔軟性(key:value タグ・多次元分析)・コスト(生イベント頻度がコストにほぼ影響しない)・信頼性(組織が既存 TSDB に強い関心を持つ)で優れる一方、テスト可能性(生のイベントデータにアクセスできないためバックテストできない)で劣る——これは Karumuri ら(2021、[[@2021__SIGMOD Record__Towards Observability Data Management at Scale]])が示した「クエリの 97% 超が直近 24 時間を対象とする鮮度バイアス」と補完的な観察で、SLO のような長期(月次)コンプライアンス計算では TSDB の「過去データを再評価できない」制約がより重い意味を持つ。TSDB がネイティブなヒストグラム型を持たない場合、count・total・bucket_count というタグ付きカウンタでパーセンタイルを近似する手法(§7.2.1.3)は、本概念が扱う圧縮・インデックス設計とは異なる「アプリケーション側の回避策」の層に位置する。(Source: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 7 SLIとSLOの計測]], [[@2021__SIGMOD Record__Towards Observability Data Management at Scale]]) - **HeteroTSDB の本番運用障害は、KairosDB のベンチマーク評価が示した「バックプレッシャー設計の欠如」という抽象的な失敗モードが実運用でも顕在化することを裏づける**: Goldschmidt ら(IEEE CLOUD 2014、[[@2014__IEEE CLOUD__Scalability and Robustness of Time-Series Databases for Cloud-Native Monitoring of Industrial Processes]])は評価実験で KairosDB(スロットリングによるグレースフルデグラデーション)と OpenTSDB(通知なき受け入れ継続)をバックプレッシャーの有無で対比したが、これは負荷注入実験に基づく観察である。[[HeteroTSDB]] の本番運用(Mackerel、[[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 4 Time Series Data-Intensive Application by Automated Data Tiering in Heterogeneous Key-Value Stores]])では、単一ノードへの書き込み負荷集中がメモリベース KVS のメモリ上限到達と OS によるプロセス強制終了を招き、メッセージブローカーからの再処理でデータを復旧するという事後対応を要した。バックプレッシャー機構を持たない TSDA が陥る失敗モードは、評価実験だけでなく実運用でも同じ形で顕在化することを示す実例であり、TSM-Bench の標準指標にバックプレッシャー評価が含まれていないという既存の未解決の問いに、実運用データという追加の裏付けを与える。(Source: [[@2014__IEEE CLOUD__Scalability and Robustness of Time-Series Databases for Cloud-Native Monitoring of Industrial Processes]] §V-A・§V-B, [[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 4 Time Series Data-Intensive Application by Automated Data Tiering in Heterogeneous Key-Value Stores]]) - **取り込み最適化の価値は、合成ベンチマークの相対スループット差だけでなく、実ワークロード規模に当てはめた運用資源(ホスト数)の削減量で評価するとより実務に近い意思決定情報になる**: [[HeteroTSDB]] は自身の測定値(8 ノードで KairosDB の 3.98 倍)を Slack 級のワークロード(秒間 1,200 万データ点、[[@2021__SIGMOD Record__Towards Observability Data Management at Scale]] が報告する規模と同系統)に当てはめ、必要ホスト数を 915 台から 229 台に削減できると翻訳した([[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 4 Time Series Data-Intensive Application by Automated Data Tiering in Heterogeneous Key-Value Stores]])。TSM-Bench([[@2023__PVLDB__TSM-Bench - Benchmarking Time Series Database Systems for Monitoring Applications]])のような合成ワークロード比較は相対的なスループット差を報告するにとどまり、この「実ワークロードボリュームへの翻訳」を欠く。(Source: [[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 4 Time Series Data-Intensive Application by Automated Data Tiering in Heterogeneous Key-Value Stores]], [[@2023__PVLDB__TSM-Bench - Benchmarking Time Series Database Systems for Monitoring Applications]]) - [InfluxDBの本番運用実績] HPCジョブモニタリング PIKA は約1,800ノード・71,000コアの本番クラスタで、短期/長期の2段構成InfluxDBに1ノードあたり平均172値/分を書き込み週10GBを消費する実測値を報告し、単一InfluxDBインスタンス(SSD1台・インメモリインデックス)がバッチサイズ・送信間隔の調整で最大10,800台のシミュレートノードのメトリクス受信を処理できたことを示した(Source: [[@2020__CLUSTER__PIKA - Center-Wide and Job-Aware Cluster Monitoring]] §II-E, §II-G)。 - [Round Robin型ストレージ] **MRTG/RRDtool(1998)は、事前確保した固定サイズの循環領域(Round Robin Archive)へポインタ更新だけで書き込む設計により、TSDBMS的な専用ストレージエンジンの源流を成す。** MRTG-2はログファイル全体を毎回読み込み・処理し・書き戻す方式で約600ポート/5分間隔が性能限界だったが、後継のRound Robin Database(RRD)はRRAへの1回の書き込みで更新が完結し、解像度別のRRAを複数持たせることで段階的な統合(consolidation)を行単位の書き換えなしに実現する。(Source: [[@1998__LISA__MRTG - The Multi Router Traffic Grapher]]) - [ダウンサンプリングと保持期間] **RRDtoolの前身であるMRTG-2のlossyログファイルは、時間経過に応じて解像度を落としながら過去2年分だけを保持する設計を1998年時点で採用しており、Gorilla(2015)などの後発TSDBが採る時間ベースの粒度低下・保持期限ポリシーの初期の実例である。** ログ解像度をWebページのグラフ解像度に合わせることで、描画時のデータ削減処理を不要にしディスクI/Oを最小化する狙いがあった。(Source: [[@1998__LISA__MRTG - The Multi Router Traffic Grapher]]) ## 未解決の問い - HeteroTSDB の本番障害(単一ノードへの書き込み集中による OOM 停止)はメッセージブローカー前置という事後対応で緩和されたが、KairosDB が示すような能動的スロットリング(バックプレッシャー)を Ingester 層に組み込む設計と、メッセージブローカーによる緩和のどちらが TSDA にとって優れた解になるか。 - 重複データ点による挿入クエリ肥大化(HeteroTSDB の本番障害の 2 件目)は実運用でのみ顕在化したバグだった。この種の異常な API 呼び出しパターンは influxdb-comparisons や TSM-Bench のような合成ワークロード生成ツールで再現できるか。ベンチマークの現実性(realism)をどう評価・改善すべきか。 - Gorilla は ACID 保証を持たず、クラッシュ時に数秒分のデータを失う可能性がある。監視データ以外の用途（金融・コンプライアンス等）でインメモリ TSDB を使う場合、どの水準の永続化保証が必要か。 - HeteroTSDB は到着順格納のためクエリ時に timestamp のソートを要し、disk-KVS の balanced tree より遅い。取り込み最適化と読み出し性能のトレードオフを両立するインデックス設計はあるか(クエリ性能評価は論文でも将来課題)。 - 将来のテレメトリは機械学習(異常検知・予測)による分析クエリが増え、繰り返しの学習が取り込みと競合しうる。学習ワークロードを前提にした TSDB の設計は何か([[時系列基盤モデル]] の推論を TSDB に組み込む可能性)。 - TSDA は front-end↔KVS 間の通信オーバーヘッドが TSDBMS に対する不可避の不利になる。この差を埋める手法(co-location・in-process 化)はあるか。 - [[PromSketch]] の中間結果キャッシュ(クエリ最適化)と [[HeteroTSDB]] の tiering(取り込み最適化)は同じ TSDB スタックに同居できるか。取り込み層・キャッシュ層・ストレージ層を貫く統合設計はどうあるべきか。 - 近似クエリキャッシュ([[近似クエリ処理]])を前提にした場合、厳密値が必要なクエリと近似で十分なクエリをシステムが自動判別できるか。誤差予算(error budget)を SLO のように運用する仕組みは何か。 - Chronix が示した「ビルトイン解析と汎用データモデルの協調設計」は 2017 年の実証だが、現代の TSDB（InfluxDB 3.x・TimescaleDB・VictoriaMetrics）はどこまでこれを採り入れたか？ - ByteSeries は Compressed Inverted Index を Compressed Segment にのみ適用するが、Active Buffer と Static Segment ではハッシュテーブルを使う。圧縮インデックスへの変換コストが高いため段階構造を採るが、write-heavy と read-heavy のワークロードが混在する場合、Active Buffer のうちにインデックスを構築し始める何らかのヒューリスティックは成立するか。 - ByteSeries の Compressed Inverted Index が trie を採用するのはタグキーのプレフィックス共有を利用するためだが、プレフィックス共有が薄い(e.g., UUID ベースのタグ値)環境では圧縮率が下がる。そのような非構造的タグ空間に適した代替索引設計は何か。 - Lindorm TSDB の前処理ダウンサンプリングは固定粒度（1 分・10 分・60 分等）を事前に定める。クエリ需要が変化したとき（例えば本番で突然 15 分集計が多発する）に動的にサンプリングレートを追加学習できるか、あるいはコンパクション時に再計算するコストはどれほどか。 - Lindorm TSDB の Seriescache は MD5 エンコードで衝突リスクを内包する。10 億超の時系列を扱う環境で MD5 衝突確率はどの程度か、また衝突を検知・回避するメカニズムは何か。 - Lindorm ML の TrainingOp プッシュダウンは「時系列パーティション単位の並列訓練」に依存する。モデルが複数時系列の相関を学習する必要がある場合（例: 多変量異常検知）に同じアーキテクチャは成立するか。 - Monarch の FHI(トライグラムインデックス)はゾーンレベルで 99.5% のファンアウトを削減するが、root レベルでは 75.8% にとどまる。より高いルートレベル精度を達成するには、ゾーンをまたぐクエリのパターンをどう索引化すればよいか。 - Monarch の Collection Aggregation は平均 36:1 の系列圧縮を達成するが、これは計測ユニットが細粒度なワークロードにしか機能しない。大規模マイクロサービスで単一メトリクスが少数の細かい集計軸しか持たない場合、圧縮率はどのくらい下がるか。 - Monarch はクロスゾーンクエリが部分データを返す可能性を許容するが、アラートルールがゾーン境界をまたぐ条件(例: 複数リージョン合計の SLO)を持つ場合に誤アラートを防ぐにはどうすればよいか。 - Goldschmidt ら 2014 が評価したのは成熟前の OSS 版(KairosDB 0.9.1・Databus 1.1.0)だが、現在の KairosDB や後継ツールはどこまで進歩し、TSM-Bench との比較はどうなるか。 - 産業用ワークロード(PMU・スマートメータ)の特性(持続的高密度書き込み・ピーク需要・長時間蓄積)は IT 監視ワークロード(低頻度スクレイプ・ランダム読み取り)とどのようにシステム要件が異なり、それが TSDB 選定基準に与える影響はどこに現れるか。 - TSDA(KairosDB/OpenTSDB)の「バックプレッシャー有無」は現在の TSM-Bench で評価されているか。過負荷時の挙動をベンチマーク指標として標準化すべきか。 - Mach の疎結合アーキテクチャ(各ソースを単一ライタースレッドに固定)は、単一ソースへの書き込みレートがそのライタースレッドの処理能力を超える極端なホットスポットワークロードでどう振る舞うか。スレッド間の動的な再割り当ては可能か。 - Mach のブロックインデックスは連結リストであり、著者ら自身が将来的な代替データ構造の検討を課題としている。[[Monarch]] の FHI(トライグラムインデックス)や [[ByteSeries]] の Compressed Inverted Index のような索引構造は Mach のブロックインデックスにも適用可能か。 - Mach はログ・イベント・トレースへの拡張を将来課題としているが、トレースには根本的に異なるデータモデル(グラフベース)が必要と著者らは述べる。[[時系列データベース|TSDB]] の疎結合アーキテクチャ(スレッドごとの独立状態)は、グラフ構造を持つトレースデータにどこまで応用できるか。 - BTrDB の root map(UUID+バージョン→アドレス解決)は単一障害点であり、著者ら自身がフラットファイルでのレプリケーションを示唆しつつ実装では見送っている。[[Monarch]] のような CAP の「AP」側に倒す設計や、[[Lindorm TSDB]] のような共有ストレージ型アーキテクチャの知見を root map に適用すれば、この単一障害点は解消できるか。 - BTrDB の統計サマリ埋め込みは「結合的(associative)な演算」に限定される(§4)。[[Lindorm TSDB]] の Lindorm ML のような機械学習パイプライン(訓練・推論)の中間結果を、同様に copy-on-write ツリーの更新に「無償で」相乗りさせる一般化は可能か、それとも結合律を満たさない演算では原理的に不可能か。 - BTrDB の k-ary ツリーのパラメータ k=64 は実装上の選択であり、定量的な感度分析(k を変えた場合のクエリレイテンシ・圧縮率・IO 回数のトレードオフ)は論文に含まれない。[[ByteSeries]] の Compressed Inverted Index や [[Monarch]] の FHI のような索引パラメータのチューニング手法は、BTrDB の k 選択にも応用できるか。 - BTrDB の delta-delta + Huffman 圧縮はナノ秒精度タイムスタンプ・高精度センサ値を主眼に設計されている。[[Gorilla]] のデルタ・オブ・デルタ+XOR 圧縮(秒精度・低精度値向け)と統合し、精度に応じて圧縮方式を動的に切り替えるハイブリッド設計は現実的か。 - [[STsCache]] は append-only 前提でキャッシュ一貫性を不要としたが、TSDB 側でバックフィル補正・欠損値の事後挿入・削除が発生する運用(本概念の他知見が扱う TSDB 群でも一般的)では、前段のセマンティックキャッシュ層にどのような invalidation 機構が必要になるか(詳細は [[セマンティックキャッシュ]] を参照)。 - Retriever が示す「TSDB を捨てて列指向ハイブリッドストアへ移行する」という解は、メトリクス専用ワークロード(アラート・SLO・ダッシュボード用の低カーディナリティ集計)に対しても優位なのか、それとも構造化イベント・トレース固有の解であり従来型 TSDB(Gorilla・Monarch 等)がメトリクスでは引き続き最適なのか。両者を同一ワークロードで比較した定量評価はあるか。 - MRTGのRound Robin Database(固定サイズ循環領域+複数解像度RRA)の設計は、後発のTSDBMS(Gorilla・Prometheus・InfluxDB等)のストレージエンジン設計にどの程度直接的な影響を与えたか、系譜を辿れるか。 ## 関連 - ソース: [[@2015__VLDB__Gorilla - A Fast, Scalable, In-Memory Time Series Database]] / [[@2021__SIGMOD Record__Towards Observability Data Management at Scale]] / [[Scaling Telemetry Workloads in Cloud Applications]] / [[@2025__NeurIPS2025__This Time is Different - An Observability Perspective on Time Series Foundation Models]] / [[@2025__VLDB__Approximation-First Timeseries Monitoring Query At Scale]] / [[@2017__FAST__Chronix - Long Term Storage and Retrieval Technology for Anomaly Detection in Operational Data]] / [[@2020__SoCC__ByteSeries - An In-Memory Time Series Database for Large-Scale Monitoring Systems]] / [[@2023__PVLDB__Lindorm TSDB - A Cloud-native Time-series Database for Large-scale Monitoring Systems]] / [[@2023__PVLDB__TSM-Bench - Benchmarking Time Series Database Systems for Monitoring Applications]] / [[@2014__IEEE CLOUD__Scalability and Robustness of Time-Series Databases for Cloud-Native Monitoring of Industrial Processes]] / [[@2022__CIDR__Mach - A Pluggable Metrics Storage Engine for the Age of Observability]] / [[@2016__FAST__BTrDB - Optimizing Storage System Design for Timeseries Processing]] / [[@2025__VLDB__STsCache - An Efficient Semantic Caching Scheme for Time-series Data Workloads Based on Hybrid Storage]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 13 Efficient Data Storage with Retriever]] / [[@2026__arXiv__Six Dimensions of Benchmarking Time-Series Databases]] / [[@2011__OReillyJapan__ウェブオペレーション - Chapter 3 インフラとアプリケーションのメトリクス]] / [[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 4 Time Series Data-Intensive Application by Automated Data Tiering in Heterogeneous Key-Value Stores]] / [[@2020__CLUSTER__PIKA - Center-Wide and Job-Aware Cluster Monitoring]] / [[@1998__LISA__MRTG - The Multi Router Traffic Grapher]] - 概念: [[テレメトリ]] / [[時系列基盤モデル]] / [[多変量時系列予測]] / [[近似クエリ処理]] / [[メインメモリデータベース]] / [[専用データベースシステム]] / [[セマンティックキャッシュ]] / [[列指向OLAPデータベース]] / [[時系列データベースベンチマーク]] / [[メトリクス削減]] - エンティティ: [[Gorilla]] / [[HeteroTSDB]] / [[Graphite]] / [[Mackerel]] / [[BOOM]] / [[Prometheus]] / [[VictoriaMetrics]] / [[PromSketch]] / [[Chronix]] / [[ByteSeries]] / [[tsdc]] / [[Lindorm TSDB]] / [[Monarch]] / [[Borgmon]] / [[eXascaleInfolab]] / [[KairosDB]] / [[OpenTSDB]] / [[Databus]] / [[ABB Corporate Research]] / [[Mach]] / [[BTrDB]] / [[STsCache]] / [[TSCache]] / [[BSCache]] / [[Retriever]] / [[Honeycomb.io]] / [[InfluxDB]] / [[TimescaleDB]] / [[DataLayerTS]] / [[ClickHouse]] / [[Ganglia]] - 関連 MOC: [[SRE - MOC]] ## 出典 - [[@2016__FAST__BTrDB - Optimizing Storage System Design for Timeseries Processing]](時間区分・バージョン注釈付き copy-on-write ツリーによるストレージ=インデックス統合・統計サマリの無償埋め込み・ComputeDiff による派生データ一貫性・delta-delta+Huffman 圧縮・4ノード EC2 で挿入53M/秒クエリ119M/秒・本番2.1兆点実績) - [[@2025__VLDB__STsCache - An Efficient Semantic Caching Scheme for Time-series Data Workloads Based on Hybrid Storage]](TSDB 前段のセマンティックキャッシュ層・時系列クエリセマンティクスの形式的定義・ハイブリッドストレージ・InfluxDB/TimescaleDB 比スループット 4.8-10.8 倍) - [[@2015__yuuk.io__High-Performance-Graphite]](Mackerel の Graphite/whisper 運用・RRD 設計・carbon-cache のマルチコア限界・ページキャッシュ圧迫・consistent-hashing クラスタ・2018 年 HeteroTSDB 移行) - [[@2015__VLDB__Gorilla - A Fast, Scalable, In-Memory Time Series Database]](Gorilla インメモリ TSDB の設計・圧縮・耐障害性・本番実績) - [[Scaling Telemetry Workloads in Cloud Applications]](§4.1–4.7 HeteroTSDB、TSDA/TSDBMS 分類・tiering・TTL migration) - [[@2025__VLDB__Approximation-First Timeseries Monitoring Query At Scale]](Prometheus/VictoriaMetrics のルールクエリのボトルネック分析、中間結果キャッシュ PromSketch) - [[@2021__SIGMOD Record__Towards Observability Data Management at Scale]](§2 MELT 各型のストレージ特性・表1 Slack 規模データ・§4 ODMS ポリストア型アーキテクチャ設計原則) - [[@2017__FAST__Chronix - Long Term Storage and Retrieval Technology for Anomaly Detection in Operational Data]](ドメイン固有 TSDB 設計・DDC 圧縮・ビルトイン解析関数・コミッショニング方法論・汎用 TSDB との性能比較) - [[@2020__SoCC__ByteSeries - An In-Memory Time Series Database for Large-Scale Monitoring Systems]](ByteDance 本番 100 億次元超監視向けインメモリ TSDB・Compressed Inverted Index・3 段メモリ構造・メタデータ圧縮 60% 削減・多次元クエリ最適化) - [[@2023__PVLDB__Lindorm TSDB - A Cloud-native Time-series Database for Large-scale Monitoring Systems]](Alibaba 本番 10 億超時系列監視・共有なし + 共有ストレージ・Seriescache・前処理ダウンサンプリング・Lindorm ML インデータベース ML・InfluxDB/TimescaleDB 比書き込み 10× クエリ 16× 高速化) - [[@2020__VLDB__Monarch - Google's Planet-Scale In-Memory Time Series Database]](Google 本番 950 億時系列・750 TB インメモリ・CAP:AP 設計・リレーショナルデータモデル・Collection Aggregation 36:1・FHI 99.5% ファンアウト抑制・クエリプッシュダウン 95% ゾーン完結) - [[@2023__PVLDB__TSM-Bench - Benchmarking Time Series Database Systems for Monitoring Applications]](7 TSDB 比較・TS-LSH データ生成・3 層ワークロード・アーキテクチャ別設計指針・監視アプリ向けベンチマーク) - [[@2022__CIDR__Mach - A Pluggable Metrics Storage Engine for the Age of Observability]](疎結合マルチライターアーキテクチャ・追記主体高速パス・セグメント一括圧縮・既存手法比書き込み10×/読み取り3×) - マット・マッシー、ジョン・オルスポー, 「3章 インフラとアプリケーションのメトリクス」, 『ウェブオペレーション ―サイト運用管理の実践テクニック』, オライリー・ジャパン, 2011, §3.1(RRD によるデファクトスタンダードな時間分解能の段階的低下), §3.9.2.3(gmond の UDP・非信頼配送設計), §3.9.2.5([[Ganglia]] gmetad の RRDtool 保存)。 - [[@2026__OReilly__Observability Engineering 2E - Chapter 13 Efficient Data Storage with Retriever]](構造化イベントに対する TSDB のカーディナリティ爆発問題・タグ再利用前提の不成立) - [[@2026__arXiv__Six Dimensions of Benchmarking Time-Series Databases]](SciTSv2: 時系列規則性を含む6次元ベンチマークで InfluxDB・TimescaleDB・ClickHouse・DataLayerTS を評価。正則データでのClickHouseの反直感的な性能低下・DataLayerTSの規則性依存性を実証) - [[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 4 Time Series Data-Intensive Application by Automated Data Tiering in Heterogeneous Key-Value Stores]](HeteroTSDB のプロトタイプ設計・評価・Mackerel 本番運用のLessons Learned。KairosDB比取り込みスループット3.98倍、本番障害2件と対処)