# 時系列データベース ## 定義 時系列データベース(TSDB)は、(1) timestamp・value・任意の tags からなる行を保存し、(2) 複数の時系列をまとめて保存し、(3) 行をクエリでき、(4) クエリに timestamp / 時間範囲を含められる DBMS(Bader らの定義)。時系列は「系列識別子 + (timestamp, value) のデータ点列」で表される。([[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]) アーキテクチャは 2 系統に大別される: **TSDA(Time Series Data-Intensive Application)** は汎用 DBMS(HBase/Cassandra 等の KVS)上に取り込み/クエリのインタフェースを載せたアプリ(OpenTSDB・KairosDB)で、自動クラスタ管理を活かし運用が楽。**TSDBMS(Time Series DBMS)** は時系列特化のストレージエンジンを持つ DBMS(Gorilla・InfluxDB・Prometheus・VictoriaMetrics)で、Gorilla 圧縮等で高い取り込み率を出すが運用は自前。([[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]) ## 横断的知見 - **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]]) - **シングルスレッド書き込みデーモンとマルチコアスケーリングの解はクラスタシャーディングだが、多段構成は可用性・保守性トレードオフを生む**: [[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]]（[[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]）でも Flusher がディスク KVS への書き出しに採用しており、事実上の監視 TSDB 圧縮標準として機能している。（Source: [[@2015__VLDB__Gorilla - A Fast, Scalable, In-Memory Time Series Database]], [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]） - **「オブザーバビリティ 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 して両取りする。([[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]) - **保持する DB と予測するモデルが同じ観測時系列を別軸で扱う**: TSDB(本概念)は観測テレメトリの「取り込み・保持・範囲クエリ」を効率化する。[[時系列基盤モデル]]([[Toto]]・[[Falcon-X]])は同じ観測時系列の「ゼロショット予測」を担う。[[BOOM]] は本番テレメトリを予測ベンチマーク化したが、そのテレメトリを生成・保持する側が TSDB であり、両者は観測データのライフサイクルの別段を占める(保持 → 予測)。(Source: [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]], [[@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: [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]], [[@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, [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]) - **共有なし + 共有ストレージのハイブリッドは「ノードスケーリング時のデータ移動ゼロ」と「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) ## 未解決の問い - 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]] の疎結合アーキテクチャ(スレッドごとの独立状態)は、グラフ構造を持つトレースデータにどこまで応用できるか。 ## 関連 - ソース: [[@2015__VLDB__Gorilla - A Fast, Scalable, In-Memory Time Series Database]] / [[@2021__SIGMOD Record__Towards Observability Data Management at Scale]] / [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]] / [[@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]] - 概念: [[テレメトリ]] / [[時系列基盤モデル]] / [[多変量時系列予測]] / [[近似クエリ処理]] / [[メインメモリデータベース]] / [[専用データベースシステム]] - エンティティ: [[Gorilla]] / [[HeteroTSDB]] / [[Graphite]] / [[Mackerel]] / [[BOOM]] / [[Prometheus]] / [[VictoriaMetrics]] / [[PromSketch]] / [[Chronix]] / [[ByteSeries]] / [[tsdc]] / [[Lindorm TSDB]] / [[Monarch]] / [[Borgmon]] / [[eXascaleInfolab]] / [[KairosDB]] / [[OpenTSDB]] / [[Databus]] / [[ABB Corporate Research]] / [[Mach]] - 関連 MOC: [[SRE - MOC]] ## 出典 - [[@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 の設計・圧縮・耐障害性・本番実績) - [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]](§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×)