# 時系列データベースベンチマーク ## 定義 時系列データベースベンチマーク(TSDB Benchmark)とは、複数の時系列データベースシステム(TSDB)の性能・機能・スケーラビリティを統一条件で比較評価するための実験的枠組みである。ベンチマークは通常、(1) データセット、(2) クエリセット、(3) ワークロード、(4) 評価指標（クエリレイテンシ・取り込みスループット・圧縮率・スケーラビリティ等）の 4 要素で構成される（[[@2023__PVLDB__TSM-Bench - Benchmarking Time Series Database Systems for Monitoring Applications]]）。 優良なベンチマークが備えるべき要件として Khelifati ら (2023) は 3 つを挙げる: (1) 多様な性能指標（クエリレイテンシ・スループット・取り込みレート・スケーラビリティ）の実装、(2) 現実的なデータの大規模生成、(3) ボトルネックの根本原因をデバッグできる詳細結果。 ## 横断的知見 - **既存ベンチマークの共通課題は「オフライン評価のみ」「静的パラメータ」「狭い現実データ」のいずれかの制限**: SciTS・SmartBench は読み書き分離のオフライン評価しか提供せず、TS-Benchmark・IoTDB-Benchmark は動的なクエリパラメータ変動をサポートしない。YCSB-TS・TSBS・ClickBench は単純な集計クエリのみで、監視アプリケーションが必要とするアップサンプリング・相関・クロス平均等の複合クエリを欠く。(Source: [[@2023__PVLDB__TSM-Bench - Benchmarking Time Series Database Systems for Monitoring Applications]] Table 1) - **監視アプリケーションのベンチマークにはオンラインワークロード（同時挿入＋クエリ）が不可欠**: ストリーミングデータ環境では取り込みとクエリが競合するが、既存ベンチマークの多数はこれを無視して取り込みとクエリを別々に評価する。TSM-Bench がオンラインワークロード層を追加した結果、オフライン評価では明確でなかった「高挿入レート下での InfluxDB の優位性」や「eXtremeDB の挿入時クエリ不安定性」が顕在化した。(Source: [[@2023__PVLDB__TSM-Bench - Benchmarking Time Series Database Systems for Monitoring Applications]] §5.3) - **「単一の最適 TSDB は存在しない」という知見がベンチマークによって定量的に裏付けられた**: TSM-Bench の 7 システム比較では、クエリ選択性・データセット規模（長系列 vs 多系列）・挿入レートという 3 軸が最良システムを決定する。クエリキャラクタライゼーションなしにシステムを選定することが適切でないことをベンチマークが実証する。(Source: [[@2023__PVLDB__TSM-Bench - Benchmarking Time Series Database Systems for Monitoring Applications]] §6) - **産業用ワークロードによるクラウド TSDB ベンチマーク(2014)は IT 監視向けシステムが産業用途で失敗しうることを最初に示した**: Goldschmidt ら(IEEE CLOUD 2014、[[@2014__IEEE CLOUD__Scalability and Robustness of Time-Series Databases for Cloud-Native Monitoring of Industrial Processes]])はスマートグリッドドメムの 2 ワークロード(PMU Write・SmartMeter Write)を定義し、最大 36 ノードの AWS 上で 3 OSS TSDB を評価した。この研究は TSM-Bench(2023)より 9 年早く、クラウドインフラ上の TSDB に対して現実的な産業ワークロードを適用した最初の体系的ベンチマーク。TSM-Bench が IT 監視ワークロードに特化するのに対し、本研究は工場センサ・スマートメータという産業ワークロードの特殊性(持続的高密度書き込み・ピーク需要・長時間蓄積)を体系化した。(Source: [[@2014__IEEE CLOUD__Scalability and Robustness of Time-Series Databases for Cloud-Native Monitoring of Industrial Processes]] §III-A, [[@2023__PVLDB__TSM-Bench - Benchmarking Time Series Database Systems for Monitoring Applications]] Table 1) - **「過負荷時のロバスト性(グレースフルデグラデーション)」はスループット・レイテンシと同等に重要なベンチマーク指標だが、標準化されていない**: Goldschmidt ら(IEEE CLOUD 2014)は 5 仮説のうち仮説 4「レジリエンス」として過負荷時・ノード障害時の挙動を体系的に評価した。KairosDB がバックプレッシャーで安定したのに対し、OpenTSDB はバックエンド障害をクライアントに伝えずに受け入れを継続し、Databus は急激なトラフィック増加で CPU 張り付きから回復できなかった。TSM-Bench(2023)のベンチマーク体系にロバスト性評価は含まれておらず、この軸は TSDB 比較研究で現在もギャップとして残る。(Source: [[@2014__IEEE CLOUD__Scalability and Robustness of Time-Series Databases for Cloud-Native Monitoring of Industrial Processes]] §III・§V, [[@2023__PVLDB__TSM-Bench - Benchmarking Time Series Database Systems for Monitoring Applications]] §2) - **TS-Benchmark(ICDE 2021)は TSM-Bench(2023)より 2 年早く「データロード/データ注入(書き込み)/データフェッチ(読み取り)の 3 分割ワークロード」を提案し、書き込みスループットの体系的測定というギャップを先取りしていた**: TSM-Bench の課題整理(Table 1)は TS-Benchmark を「動的なクエリパラメータ変動をサポートしない」ベンチマークとして位置づけるが、TS-Benchmark 自体の主目的は複合分析クエリではなく、パターンマッチング等の上位層処理と TSDB 自体が担うデータの出し入れ(ロード・注入・フェッチ)を明確に分離して測定することにある。この設計思想は Goldschmidt ら(2014)の「産業ワークロードでの書き込み性能・ロバスト性評価」と方向性が近く、TSM-Bench の「オンラインワークロード(取り込み+クエリの同時実行)」による統合評価とは異なるアプローチで書き込み性能の測定ギャップに取り組んだ先行例といえる。(Source: [[@2021__ICDE__TS-Benchmark - A Benchmark for Time Series Databases]] §I, [[@2023__PVLDB__TSM-Bench - Benchmarking Time Series Database Systems for Monitoring Applications]] Table 1) - **InfluxDB・TimescaleDB・Druid・OpenTSDB という代表的 4 TSDB の性能特性は、評価シナリオ(IoT監視 vs 汎用ベンチマーク)によらず一貫した傾向を示す**: TS-Benchmark(2021、風力発電ウィンドファーム監視)と SciTSv2([[@2026__arXiv__Six Dimensions of Benchmarking Time-Series Databases]])はいずれも InfluxDB の TSM ツリーが高い書き込み・読み取り性能を両立する一方 CPU 使用率が高くなること、TimescaleDB が PostgreSQL 由来の行指向ストレージによりクエリで不利になることを共通して報告する。異なる年代・異なるワークロード設計の 2 つのベンチマークが同じ設計トレードオフ(TSM ツリー vs 行指向ストレージ)を独立に観測しており、TSDB のストレージエンジン選択が性能特性を支配する主要因であることの傍証となる。(Source: [[@2021__ICDE__TS-Benchmark - A Benchmark for Time Series Databases]] §IV-D〜F, [[@2026__arXiv__Six Dimensions of Benchmarking Time-Series Databases]] §5-6) - **「時系列の規則性(等間隔性)」は既存ベンチマークのいずれにも存在しなかった評価軸であり、これを欠くと「規則性は常に有益」という誤った前提を置いてしまう**: [[@2026__arXiv__Six Dimensions of Benchmarking Time-Series Databases]](SciTSv2)は、TSM-Bench を含む既存の7ベンチマーク(YCSB-TS・SmartBench・IoTDB-Benchmark・TS-Benchmark・SciTS・TSM-Bench・TSBS)のいずれも regularity 次元を実装していないことを Table 1 で示す。regularity 軸を実際に導入した結果、[[ClickHouse]] は正則(等間隔)時系列では疎インデックスのパーツ集中によりディスク競合が増え、むしろ不規則時系列より取り込みレートが低下するという反直感的な結果が判明した。一方 [[DataLayerTS]] は正則性への依存度が最も高く、不規則データでは性能が崩壊する。TSM-Bench の「クエリ選択性・データセット規模・挿入レートの3軸が最良システムを決める」という知見(既存記載)に、regularity という第4の軸を追加する必要があることを本論文は示す。(Source: [[@2026__arXiv__Six Dimensions of Benchmarking Time-Series Databases]] §2, §6) - **6次元(接続並列性・バッチ取り込み・規則性・多変量系列・混合ワークロード・システムメトリクス)を単一ベンチマークで統一するアプローチは、各次元を独立制御可能な実験変数として扱うことで性能挙動を特定アーキテクチャ特性へ体系的に帰属できる**: TSM-Bench(既存記載)は「多様な性能指標の実装・現実的データ生成・ボトルネックのデバッグ可能性」の3要件を掲げるが、次元を明示的に分離した設計ではない。SciTSv2 はワークロード定義パラメータ(ClientNumberOptions・BatchSizeOptions・IngestionType・DataDimensionsNrOptions・MixedWLPercentageOptions)によって各次元を独立にスイープできる点が異なり、結果として「[[InfluxDB]] はCPU律速(インデックスソート)」「TimescaleDB はI/O律速(チャンクごとのB-Tree書き込みでディスク増幅824倍)」「DataLayerTS はディスク帯域幅律速(配列再書き込みで2〜2.5 GB/s)」というTSDBごとに異なる根本ボトルネックまで診断できた。(Source: [[@2026__arXiv__Six Dimensions of Benchmarking Time-Series Databases]] §4, §6) - **混合ワークロードでの読み書き競合パターンはTSDBのストレージアーキテクチャによって定性的に異なる**: SciTSv2 はTSM-Bench の「オンラインワークロードが隠れた弱点を顕在化させる」という知見(既存記載、eXtremeDB・TimescaleDBの事例)を、単一配列ストレージ([[DataLayerTS]])・タグベースLSM([[InfluxDB]])・OLAPカラムストア([[ClickHouse]])という3つの異なるアーキテクチャで再確認・拡張した。DataLayerTS はingestion checkpointとqueryが同一ベクターファイルを奪い合いCPUシステム時間が22%まで急増、InfluxDBはクエリレイテンシが挿入強度に正比例、ClickHouseのみ混合負荷下でも高い取り込みと低いレイテンシを両立した。(Source: [[@2026__arXiv__Six Dimensions of Benchmarking Time-Series Databases]] §6.3) ## 未解決の問い - SciTSv2 の評価は InfluxDB・TimescaleDB・ClickHouse・DataLayerTS の4システムに限られる。TSM-Bench が評価した Druid・eXtremeDB・MonetDB・QuestDB や、Prometheus・VictoriaMetrics 系のTSDBMSにregularity次元を適用した場合、どのような結果になるか。 - DataLayerTS の開発者は不規則時系列での高負荷利用を推奨しておらず、SciTSv2 も公平な比較のためDLTSの不規則時系列評価を除外した。「規則性特化TSDBが不規則データでどこまで劣化するか」を定量化する評価設計はどうあるべきか。 - 混合クエリワークロード（Q1〜Q7 が同時に発行される）とマルチテナントシナリオ(TSM-Bench §7 の将来計画)でシステム順位はどう変わるか。 - エネルギー消費・クラウドコストを評価指標に加えたとき、最適なシステム選択は変わるか。 - 時系列基盤モデル([[時系列基盤モデル]])の推論をインデータベースで行う場合、既存 TSDB ベンチマークにどのような追加ワークロード（ML 推論クエリ）が必要か。 - 水位・温度センサーデータを対象とした TSM-Bench の知見は、IoT・ヘルスケア・電力グリッド等の他ドメイン監視データにどこまで一般化できるか。 - Goldschmidt ら 2014 が産業ワークロードで評価したのは 2013 年末時点の初期バージョンだが、10 年後の現代の KairosDB・OpenTSDB 後継(HBase 2.x ベース)は同等の産業ワークロードでどう動くか。TSM-Bench の枠組みに産業ワークロードを追加する標準化は検討されているか。 - 過負荷時ロバスト性(バックプレッシャー・グレースフルデグラデーション)は TSM-Bench や YCSB-TS に含まれていないが、産業・IoT 用途では重要な指標である。これをベンチマーク指標として定式化・標準化するアプローチはあるか。 - TS-Benchmark(2021)は全システムをシングルノード版で評価しており、分散アーキテクチャ前提の OpenTSDB(HBase ベース)には不利な可能性があると論文自身が認めている。分散クラスタ構成での再評価により、OpenTSDB の相対順位はどう変わるか。 - TS-Benchmark の DCGAN + 有向グラフ + ランダムウォークによるデータ生成モデルと、TSM-Bench の TS-LSH(GAN×LSH)は、いずれも GAN で生成したフラグメントを連結して長い時系列を作る点で共通する。TS-LSH は先行手法「TS-Graph」(グラフ構築が二次時間・時間シフトで相関低下)との比較優位を報告するが、TS-Benchmark 自身の有向グラフ構築の計算量やグローバルトレンド保持性は TSM-Bench の指標(Pearson相関等)で定量評価されていない。両者を同一データセットで比較した場合、データ品質・生成速度はどちらが優れるか。 ## 関連 - ソース: [[@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]] / [[@2026__arXiv__Six Dimensions of Benchmarking Time-Series Databases]] / [[@2021__ICDE__TS-Benchmark - A Benchmark for Time Series Databases]] - 概念: [[時系列データベース]] / [[時系列データ生成]] / [[専用データベースシステム]] / [[近似クエリ処理]] / [[SRE Benchmark]] / [[産業用監視システム]] - エンティティ: [[Abdelouahab Khelifati]] / [[eXascaleInfolab]] / [[University of Fribourg]] / [[Thomas Goldschmidt]] / [[ABB Corporate Research]] / [[KairosDB]] / [[OpenTSDB]] / [[Databus]] / [[InfluxDB]] / [[TimescaleDB]] / [[DataLayerTS]] / [[ClickHouse]] / [[Karlsruhe Institute of Technology]] / [[Druid]] / [[Renmin University of China]] ## 出典 - [[@2023__PVLDB__TSM-Bench - Benchmarking Time Series Database Systems for Monitoring Applications]]（TSM-Bench: 7 TSDB の包括比較・TS-LSH データ生成・3 層ワークロード・クエリ変動評価） - [[@2014__IEEE CLOUD__Scalability and Robustness of Time-Series Databases for Cloud-Native Monitoring of Industrial Processes]]（産業用ワークロード(PMU・スマートメータ)による初期クラウド TSDB ベンチマーク・5 仮説検証・ロバスト性評価） - [[@2021__ICDE__TS-Benchmark - A Benchmark for Time Series Databases]]（TS-Benchmark: 風力発電ウィンドファーム監視シナリオ・DCGAN データ生成・ロード/注入/フェッチの3ワークロード分離・InfluxDB/TimescaleDB/Druid/OpenTSDB 比較） - [[@2026__arXiv__Six Dimensions of Benchmarking Time-Series Databases]]（SciTSv2: 接続並列性・バッチ取り込み・時系列規則性・多変量系列・混合ワークロード・システムメトリクスの6次元を統一する初のTSDBベンチマーク。InfluxDB・TimescaleDB・ClickHouse・DataLayerTSの4TSDBを評価しCPU/I/O/ディスク帯域幅の律速要因を特定)