> [!abstract] 概要(Abstract の日本語訳) > 時系列データはサプライチェーン・株式データ分析・スマート製造などの場面で広く使われている。大量の時系列データを管理・照会するために数多くの時系列データベースシステムが考案されてきた。既存の時系列データベースベンチマークは、パターンマッチングや傾向予測といった複合分析のワークロードに焦点を当てており、その性能はバックエンドのデータベースよりもデータ分析アルゴリズムに大きく左右されることを我々は観察した。しかし時系列データベースの多くの実アプリケーションでは、人々はデータ注入スループットやクエリ処理時間といった性能指標により関心を持つ。こうした指標において時系列データベースの性能を広範に比較するベンチマークが依然として必要とされている。我々は主に風力タービンのデバイス監視シナリオを適用する TS-Benchmark と呼ぶベンチマークを導入する。DCGAN ベースのデータ生成モデルを提案し、一部の実時系列データから大量の時系列データを生成する。ワークロードはデータロード(バッチ)・ストリーミングデータ注入・履歴データアクセス(典型的なクエリ向け)の 3 種類に分類される。我々はこのベンチマークを実装し、InfluxDB・TimescaleDB・Druid・OpenTSDB という 4 つの代表的な時系列データベースを比較する。結果を報告し分析する。 ## 論文情報 - タイトル: TS-Benchmark: A Benchmark for Time Series Databases - 著者: Yuanzhe Hao・Xiongpai Qin・[[Yueguo Chen]](責任著者)・Yaru Li・Xiaoguang Sun・Yu Tao・Xiao Zhang・Xiaoyong Du - 所属: [[Renmin University of China]] Key Laboratory of Data Engineering and Knowledge Engineering (MOE) - 媒体: 2021 IEEE 37th International Conference on Data Engineering(ICDE 2021) - DOI: 10.1109/ICDE51399.2021.00057 - コード: https://github.com/dbiir/TS-Benchmark(論文脚注 1 記載のオープンソースリポジトリ) ## 概要 TS-Benchmark は、既存の時系列データベース(TSDB: Time Series Database)ベンチマークが複合分析クエリに偏重しデータ注入性能を軽視している問題に対処するため、風力発電ウィンドファームのデバイス監視という IoT シナリオに基づいてデータロード・データ注入・データフェッチの 3 ワークロードを体系的に測定するベンチマークである。DCGAN(Deep Convolutional GAN)ベースのデータ生成モデルにより実データに酷似した合成時系列を大量・高スループットに生成し、InfluxDB・TimescaleDB・Druid・OpenTSDB という代表的な 4 TSDB を比較評価する。 ## 問題設定 大規模ウィンドファームからのセンサデータ処理パイプラインを想定する。各風力タービン(デバイス)には最大数百個のセンサが搭載され、1 ウィンドファームあたり 50 デバイスがデータを独立にデータセンターへ送信すると仮定する。大手風力発電会社は数千のウィンドファーム、すなわち数十万デバイスからのデータを処理する必要がある。ストリーミングデータはストリーム処理システム(監視用)と TSDB(永続化用)の双方にルーティングされる(Fig. 1)。 **Figure 1: 風力タービンから収集される時系列データの典型的な処理パイプライン** ![[_attachments/TS-Benchmark_A_Benchmark_for_Time_Series_Databases/fig01-pipeline.png]] (Fig. 1. センサデータはキューを経てストリーミング処理(ダッシュボード表示・診断・最適化・予測)と時系列データベース(TSDB)の双方に送られる。TS-Benchmark が対象とするのは図中の TSDB(Time Series Database)部分であり、ストリーム処理システム自体は対象外。Source: Adapted from 論文 Fig. 1.) TSDB が永続化データへのアクセスを要求される典型的な場面として、論文は 4 種を挙げる: (1) **問題特定**: センサ読み取り値が閾値を超えた際、原因特定や異常発生頻度の確認のため障害発生時点周辺のデータを取得する。(2) **運用最適化**: 直近で最も性能が良いタービンを特定するため、発電関連の主要センサ読み取り値を深く分析する。(3) **問題予測**: 近い将来の予測分析のため、より多くの直近データを必要とする。(4) **相関分析**: 異なるデバイス間・同一デバイスの異なるセンサ間で相関分析を行うため、同一期間の履歴データを読み取る。 論文は、上位層ソフトウェア(パターンマッチング等、DB性能に無関係な処理)と TSDB 自体が担うべき処理(データの出し入れ)を明確に分離すべきだと主張する。IoTAbench・Linear Road は前者寄りの複合分析クエリに偏っており、データ注入性能を測定しない。InfluxDB-comparison・Time Series Benchmark Suite (TSBS) はデータ注入を継続的にはテストしない。Analytics in Motion (AIM) は TSDB 専用ではなく混合ワークロード向けである。TS-Benchmark はこのギャップを埋めるため、書き込み性能と純粋な読み取り性能の両方を体系的に評価する。 ## 提案手法 ### DCGAN ベースのデータ生成モデル 大量の高品質センサ読み取りデータを高スループットに生成するため、以下の 4 段階からなるフレームワークを提案する。 1. 実時系列データからシードフラグメント(部分系列)を作成する(データサイズに制限がある)。 2. 敵対的生成ネットワーク(GAN)モデルにより実シードから合成フラグメントを生成する。 3. 合成フラグメントの有向グラフを構築する。 4. 合成フラグメントの有向グラフ上でランダムウォークにより時系列を連続生成する。 後半 2 段階はストリーミング時系列の生成用であり省略可能。 GAN モデルは生成器 G と識別器 D の 2 部からなる敵対的モデルで、価値関数 V(G, D) の minimax ゲームにより同時最適化される(式 (1))。TS-Benchmark が用いる GAN は DCGAN(Deep Convolutional GAN)ベースであり、生成器は逆畳み込み層、識別器は畳み込み層で構成される(Fig. 2)。CNN により、時系列中の位置に依存しない特徴学習が可能になる。出力次元は式 (2) `(W − K + 2P) / S + 1`(W: 入力次元数、K: カーネル/フィルタサイズ、S: ストライド、P: パディング量)で計算される。 **Figure 2: 時系列生成のための GAN アーキテクチャ** ![[_attachments/TS-Benchmark_A_Benchmark_for_Time_Series_Databases/fig02-gan-architecture.png]] (Fig. 2. ランダムノイズを入力とする生成器 G が合成フラグメント(generated data)を生成し、識別器 D が実データ(real data)と合成データを判別する。訓練完了後、生成器は潜在表現 z から現実的なフラグメント x へのマッピング G(z) を学習しているが、逆写像 μ(x) は自動では得られない。Source: Adapted from 論文 Fig. 2.) 合成データの品質は (a) 識別器の出力(実データとの類似度)と (b) 対象実フラグメントとの類似度の両方で決まる。識別器損失は式 (3) `L_D(z_γ) = Σ|f(x) − f(G(z_γ))|`(f(·) はフラグメントの統計量)、類似度損失は式 (4) `L_R(z_γ) = Σ|x − G(z_γ)|` で定義され、最終損失は式 (5) `L(z_γ) = (1−λ)·L_R(z_γ) + λ·L_D(z_γ)` の重み付き和(λ=0.5 に設定)である。論文は LSTM ベースの GAN(生成器・識別器の一方または両方が LSTM)も試したが、特に非周期的な時系列で生成フラグメントがノイズだらけになったため不採用とし、DCGAN ベースの結果のみを報告する。 ### 合成フラグメントの有向グラフとランダムウォーク 大量の合成フラグメントをストリーミング時系列として連続生成するため、接続可能なフラグメント間にエッジを持つ有向グラフを構築する。フラグメント a から b への接続可能性は、a の末尾 a_t と b の先頭 b_h(いずれも長さ l)のユークリッド距離に基づく類似度 `sim_l(a_t, b_h)` として式 (6) で定義される。閾値 s̄ を超える類似度を持つフラグメント集合 N_a = {b | s(a,b) > s̄} が a の接続可能フラグメント集合となり(N_a が空の場合は最大類似度の 1 点のみを採用)、エッジ (a, b) には確率的重み w(a,b) が式 (7) で割り当てられる(Fig. 3)。 **Figure 3: シーケンスによって構築される有向グラフ** ![[_attachments/TS-Benchmark_A_Benchmark_for_Time_Series_Databases/fig03-directed-graph.png]] (Fig. 3. 各ノードが合成フラグメントを表し、エッジの重み w1〜w10 は接続可能性に基づく確率的な遷移重みを表す。ランダムウォークにより、開始シードから確率 w(a,b) でノード b が次の系列として選ばれる。Source: Adapted from 論文 Fig. 3.) 初期シード a からランダムウォークで後続系列 b を選ぶ際、隣接フラグメント a・b は式 (8) `c_i = (1−σ_i)a_i + σ_i b_i`(σ はシグモイド関数)によって滑らかに接続される。実時系列に稀に現れる外れ値的な形状は DCGAN では模倣困難なため、ユーザが両端が滑らかな異常形状セグメントを手動作成し、有向グラフのランダムウォークに組み込むことで異常形状も生成可能にする。 ### ベンチマークアーキテクチャと実装 TS-Benchmark は Java で実装される(Fig. 4)。データ生成モジュールがデータロード用の基本データセットを生成し、ロードモジュールが対象システムへのロード性能をテストし、クエリ生成モジュールが生成したクエリをクエリモジュールが対象データベースに対して実行し、注入モジュールがデータストリームを対象システムへ送る。「データベースアダプタ」モジュールが対象システムの違いを吸収する統一インタフェースを提供し、インタフェースを継承したドライバの実装により新規データベースを追加テストできる。 **Figure 4: TS-Benchmark のアーキテクチャ** ![[_attachments/TS-Benchmark_A_Benchmark_for_Time_Series_Databases/fig04-benchmark-architecture.png]] (Fig. 4. ベンチマークツール内部でクエリ生成・データ生成(メモリ内データ・データファイル)がそれぞれクエリ/注入/ロードの各処理を経てデータベースアダプタへ渡され、[[InfluxDB]]・[[TimescaleDB]]・[[Druid]]・[[OpenTSDB]] 等の対象システムに送られる。結果はレポートとして出力される。Source: Adapted from 論文 Fig. 4.) ### ワークロード設計 3 種のワークロードを定義する。 **(1) データロード(バッチ)**: 2 つの基本データセットをテキスト形式で生成する。データセット 1 は 2 ウィンドファーム×50 デバイス×50 センサ、1 週間分で 4.32×10^8 データ点(合計 3.9GB)。データセット 2 は 50 ウィンドファーム×50 デバイス×150 センサ、1 週間分で 3.24×10^10 データ点(合計 284.5GB)。データセットサイズはウィンドファーム数・デバイス数・センサ数の 3 スケールファクタで動的に設定でき、ウィンドファーム数を主要スケールファクタとすることを推奨する。 **(2) 連続データ注入**: バッチロード後、マルチスレッド(1 スレッド=1 ウィンドファーム分の接続)でデータ注入を行う。スレッド数を 1 から 512 まで段階的に増やし、システムが飽和する点を観測する。デフォルトの更新間隔は 7 秒。 **(3) データフェッチ(6 種のクエリ)**: 問題特定用の Query 1.1(単一デバイス・単一センサの 1 時間ウィンドウ範囲取得)・Query 1.2(センサ閾値超過タイムスタンプの 1 週間ウィンドウ検索)、運用最適化用の Query 2.1(電力センサの時間別平均、GROUP BY 集計)・Query 2.2(発電関連の複数センサの 1 時間ウィンドウ取得)、問題予測用の Query 3(ウィンドファーム全デバイスの 15 分ウィンドウ取得、フィルタなしのフルスキャン)、相関分析用の Query 4(固定ウィンドウサイズでの全センサ値の反復取得、30 回のスライディングウィンドウクエリ)。OpenTSDB は標準 SQL をサポートしないため、6 クエリを対象データベースの等価なクエリ言語に変換する。 **Table I. 各クエリの選択性(Selectivity)** | Query | Dataset 1 | Dataset 2 | |---|---|---| | Query 1.1 | 1.18×10⁻⁶ | 1.58×10⁻⁸ | | Query 1.2 | 1.00×10⁻² | 1.33×10⁻³ | | Query 2.1 | 1.00×10⁻² | 1.33×10⁻³ | | Query 2.2 | 2.98×10⁻⁴ | 1.19×10⁻⁵ | | Query 3 | 7.44×10⁻⁴ | 2.98×10⁻⁵ | | Query 4 | 2.98×10⁻³ | 1.19×10⁻⁴ | (Table I. データセット 2 はデータセット 1 より規模が大きいぶん、同じクエリ条件でも選択性(該当行の割合)が全クエリで 1〜2 桁小さくなる。) ## 新規性 既存 TSDB ベンチマーク(IoTAbench・Linear Road・InfluxDB-comparison・Time Series Benchmark Suite)は複合分析クエリに焦点を当て、TSDB 自体の書き込み性能を軽視または無視してきた。TS-Benchmark は (1) データロード・データ注入(書き込み)・データフェッチ(読み取り)を明確に区分してすべて測定する点、(2) DCGAN による高品質・高スループットな合成データ生成モデルを備える点、(3) 風力発電ウィンドファーム監視という具体的な IoT シナリオに基づき現実的なデータ分布を保証する点で先行研究と異なる。特に Time Series Benchmark Suite が現実データ分布を保証せずランダム生成する点と対比される。 ## 実験設定 - **ハードウェア**: Intel(R) Xeon(R) CPU E5-2620 @ 2.00GHz(12 コア)、32GB メモリ、2TB 7200rpm SAS HDD の CentOS 7.6 サーバ 2 台(1 台がデータベース、もう 1 台がベンチマークツール)。10 Gbit/s Ethernet の同一 LAN 上で C/S モデルとして動作。 - **監視ツール**: Prometheus・Grafana。 - **対象システム**: [[InfluxDB]] V1.7、[[TimescaleDB]] V1.2.1、[[Druid]] V0.13、[[OpenTSDB]] V2.3。InfluxDB のクラスタ版は有償、TimescaleDB にはクラスタ版が存在しないため、全システムをシングルノード版で公平に比較する。 - **手順**: (1) 基本データセットをロードしてスループット・圧縮率を測定、(2) ストリーミング時系列を継続生成しながらウィンドファーム数を変えて注入テストを実行、(3) 6 種のクエリでレイテンシを測定(各クエリはパラメータを変えて 10 回実行し平均応答時間を算出)。 ## 実験結果 ### データ生成結果 500 点のスライディングウィンドウで実データからシードフラグメントを切り出し、DCGAN モデルを訓練して大量の合成フラグメントを生成した後、高頻度ジッタを持つ合成系列にカルマンフィルタを適用する。合成フラグメントの生成は有向グラフとランダムウォークによるメモリ内処理のため非常に高速であり、論文はデータ生成自体のスループット実験は実施していない。 **Figure 5: 実(赤)・合成(青)フラグメントの例(3 形状 × データ生成モデルの各段階)** ![[_attachments/TS-Benchmark_A_Benchmark_for_Time_Series_Databases/fig05-real-synthetic-fragments.png]] (Fig. 5. (a)(d)(f) が shape 1〜3 の実フラグメント、(b)(g) が対応する DCGAN 生成フラグメント(basic)、(c)(h) がカルマンフィルタ適用後(synthetic)。shape 2 は (e) が直接 synthetic。3 形状いずれも合成フラグメントは実フラグメントの全体形状に酷似している。Source: Adapted from 論文 Fig. 5.) **Figure 6〜8: 実・合成の連続時系列(shape 1〜3)** ![[_attachments/TS-Benchmark_A_Benchmark_for_Time_Series_Databases/fig06-shape1-timeseries.png]] (Fig. 6. shape 1(周期的なのこぎり波状パターン)の実(赤)・合成(青)の連続時系列。有向グラフのランダムウォークにより長い連続系列が生成されている。Source: Adapted from 論文 Fig. 6.) ![[_attachments/TS-Benchmark_A_Benchmark_for_Time_Series_Databases/fig07-shape2-timeseries.png]] (Fig. 7. shape 2(高頻度ノイズを伴う準周期パターン)の実・合成の連続時系列。Source: Adapted from 論文 Fig. 7.) ![[_attachments/TS-Benchmark_A_Benchmark_for_Time_Series_Databases/fig08-shape3-timeseries.png]] (Fig. 8. shape 3(緩やかなトレンド変化を伴うパターン)の実・合成の連続時系列。Source: Adapted from 論文 Fig. 8.) ### データロード結果 **Table II. データセット 1(3.9GB)でのロード性能** | Database | Throughput (points/s) | Throughput (MB/s) | Compression Ratio | |---|---|---|---| | InfluxDB | 69,722 | 0.660 | 68% | | TimescaleDB | 124,138 | 1.175 | 118% | | Druid | 142,339 | 1.346 | 135% | | OpenTSDB | 38,652 | 0.366 | 366% | **Table III. データセット 2(284.5GB)でのロード性能** | Database | Throughput (points/s) | Throughput (MB/s) | Compression Ratio | |---|---|---|---| | InfluxDB | 66,215 | 0.610 | 69% | | TimescaleDB | 1,093,302 | 10.072 | 102% | | Druid | 133,016 | 1.225 | 111% | | OpenTSDB | NULL | NULL | NULL | InfluxDB は両データセットで最良の圧縮率(68〜69%)を示す。データ型ごとに異なる圧縮アルゴリズム(浮動小数点に Facebook Gorilla、タイムスタンプに simple8b エンコーディング、文字列に snappy 等)を使い分けるためである。Druid も類似の型別圧縮戦略を持つが、分散ファイルシステム上の永続バックアップ「deep storage」にセグメントを複製するためストレージ消費が拡大する。OpenTSDB はキーバリューモデルの HBase 上に構築されるため、"metric" 名などのキーを繰り返し保存する冗長性から圧縮率が最も悪い(3.6 倍に拡大)。データセット 2 では TimescaleDB の専用ロードツール「timescaledb-parallel-copy」がトランザクション処理とインデックス同期を無効化して複数リソース・スレッドを活用するため、スループットが Druid の約 1 桁上回る。OpenTSDB はデータセット 2 のインポートに失敗した(HBase がクラッシュ)。この実験はシングルノード版での結果であり、分散アーキテクチャ前提の OpenTSDB には不利な可能性がある点に論文は留意している。 ### データ注入結果 スレッド数(ウィンドファーム数のスケールファクタ)を 1〜512 で段階的に増加させ、各段階 35 秒間注入して平均スループットを測定した。 **Figure 9: データ注入の結果** ![[_attachments/TS-Benchmark_A_Benchmark_for_Time_Series_Databases/fig09-injection-throughput.png]] (Fig. 9. (a)(b) はデータセット 1・2 でのスレッド数(=ウィンドファーム数)に対する注入スループット(対数軸)。(c)(d) は 8 スレッド固定・デバイス数(50〜300)を増やした場合のスループット。Source: Adapted from 論文 Fig. 9.) データセット 1(小規模)では OpenTSDB が 2〜256 スレッドで最良のスループットを維持し(93,931〜16,199,638 points/s、ほぼスレッド数に線形)、256 スレッドで飽和し始め 512 スレッドでもほぼ頭打ちになる。TimescaleDB は 512 スレッドでも飽和せず、最高スループット 27,765,420 points/s を達成する。Druid は最低スループットで 64 スレッドで飽和し 1,032,805 points/s にとどまる。データセット 2(大規模)に切り替わると Druid の書き込み性能は著しく低下し、64 スレッドで大規模書き込み要求を処理できなくなる。TimescaleDB はスレッド数 32 以上で InfluxDB の性能を上回るようになる。デバイス数を増やす実験(Fig. 9c/d)では InfluxDB が両データセットで最良の性能を示し、データセット 1 では 300 デバイスでも飽和しない。 **Table IV. バッチサイズ別の注入スループット** | interval (sec.) | # of rows | InfluxDB | TimescaleDB | Druid | OpenTSDB | |---|---|---|---|---|---| | 0.1 | 35 | 6,392 | 5,973 | 2,083 | 5,482 | | 1 | 350 | 10,470 | 8,362 | 7,692 | 8,978 | | 7 | 2,500 | 43,427 | 41,136 | 30,981 | 31,972 | | 14 | 5,000 | 81,036 | 83,003 | 31,271 | 78,367 | (Table IV. 注入間隔を 0.1〜14 秒に変えてバッチサイズを 35〜5,000 点に変化させた実験。小バッチ・短間隔では InfluxDB が最速だが、バッチが大きくなるにつれ TimescaleDB が InfluxDB を上回るようになる。スループットはバッチサイズに比例せず、ネットワークプロトコル等の追加オーバーヘッドが存在することを示唆する。) **Figure 10: データセット 1 でのリソース使用状況(データ注入中)** ![[_attachments/TS-Benchmark_A_Benchmark_for_Time_Series_Databases/fig10-resource-usage-dataset1.png]] (Fig. 10. 4 データベース(InfluxDB・TimescaleDB・Druid・OpenTSDB)の CPU 使用率(a〜d)・メモリ使用率(e〜h)・ディスク入力帯域(i〜l)の時系列。InfluxDB は注入飽和付近で CPU 使用率がほぼ 100% に達する(a)。TimescaleDB は CPU・メモリともにスレッド数増加に対し比較的安定している(b, f)。OpenTSDB は散発的なコンパクション操作により巨大なディスク入力帯域コストが発生する(l)。Source: Adapted from 論文 Fig. 10.) InfluxDB の優れた書き込み性能は、書き込み時にインデックスを構築する時系列構造化マージ(TSM: Time-Structured Merge)ツリー設計とバックプレッシャー機構に由来する。TimescaleDB はデータ量に基づく適応的タイムチャンクにより CPU を節約しメモリスワッピングを削減する。OpenTSDB は HBase の LSM ツリーにより小規模データセットで優れた書き込み性能を示すが、HBase への格納時に即座に圧縮されないため散発的なコンパクション操作が巨大なディスク入力コストを生む。Druid のストリームデータ処理は tranquility に依存するが、tranquility は高並行性下で性能が振るわず、これが Druid の書き込みボトルネックの一因になっていると論文は分析する。 **Figure 11: データセット 2 でのリソース使用状況(データ注入中)** ![[_attachments/TS-Benchmark_A_Benchmark_for_Time_Series_Databases/fig11-resource-usage-dataset2.png]] (Fig. 11. 大規模データセット(284.5GB)での InfluxDB・TimescaleDB・Druid の CPU/メモリ/ディスク入力帯域。データセット 1 に比べ全般に CPU 使用率が低く抑えられる一方、変動が大きくなる傾向が見られる(OpenTSDB はデータセット 2 のロードに失敗しているため対象外)。Source: Adapted from 論文 Fig. 11.) ### クエリ結果 各クエリを異なるパラメータで 10 回実行し平均レイテンシを測定した。OpenTSDB は閾値条件付きクエリ(Query 1.2)をサポートしないため応答時間を NULL とする。 **Table V. データセット 1(3.9GB)でのクエリレイテンシ(ミリ秒)** | Query | InfluxDB | TimescaleDB | Druid | OpenTSDB | |---|---|---|---|---| | Query 1.1 | 22 | 63 | 65 | 117 | | Query 1.2 | 146 | 422 | 69 | NULL | | Query 2.1 | 387 | 1,861 | 1,102 | 1,666 | | Query 2.2 | 367 | 56 | 17 | 204 | | Query 3 | 2,946 | 297 | 118 | 376 | | Query 4 | 103,110 | 9,358 | 4,248 | 14,061 | **Table VI. データセット 2(284.5GB)でのクエリレイテンシ(ミリ秒)** | Query | InfluxDB | TimescaleDB | Druid | OpenTSDB | |---|---|---|---|---| | Query 1.1 | 242 | 5,977 | 2,833 | NULL | | Query 1.2 | 357 | 19,683 | 3,741 | NULL | | Query 2.1 | 4,020 | 5,681 | 34,331 | NULL | | Query 2.2 | 590 | 38,977 | 62 | NULL | | Query 3 | 11,209 | 1,039 | 298 | NULL | | Query 4 | 381,106 | 37,565 | 11,026 | NULL | InfluxDB は Query 1.1・1.2・2.1(いずれもファーム/デバイス/センサ ID を絞り込むフィルタ付きクエリ)で絶対的な優位性を示す。これは TSM インデックスによりクエリ時間範囲に該当するファイルを絞り込んだ後、TSM インデックスの二分探索でデータブロックを特定できるためである。Druid は Query 2.2・3・4(センサ集合指定・フィルタなしフルスキャン・反復取得)で明確な優位性を示す。これはセグメント単位のデータ分離とカラムへのビットマップインデックスに由来する。TimescaleDB は行指向ストレージを PostgreSQL から継承しており、大規模データに対するフィルタ付きクエリで不利になる。またチャンク単位の分割はあるが、カラムへの自動インデックス作成を行わない。OpenTSDB のクエリはリクエストを HBase に転送し結果を受け取って返す構成のため、シリアライズ/デシリアライズのオーバーヘッドで性能が劣る。 ## 考察 論文は以下の知見を整理している。 1. **TS-Benchmark は上位層ソフトウェアの処理(パターンマッチング等、DB 性能に無関係)と TSDB 自体が担うべき処理(データの出し入れ)を明確に分離してテストする**設計であり、ストリーム処理システムそのものの評価は対象外(あくまで TSDB へのデータ操作を測定する)。 2. DCGAN ベースのデータ生成モデルにより、実世界のシードデータから任意規模の高品質合成データセットを高スループットに生成できる。 3. InfluxDB(TSM ツリー、LSM ツリーの変種)・TimescaleDB(PostgreSQL ベース、行指向ストレージ)・Druid(カラム型ストレージ、注入時インデックス構築)・OpenTSDB(HBase ベース、キーバリューモデルの代表)という設計思想の異なる 4 TSDB を代表として選定している。 4. 総合的な結論として: (I) InfluxDB は TSM ツリーにより高い注入スループットと高いクエリスループットの両方を享受する(書き込み時にインデックスを構築するため読み取りも高速)。(II) Druid の tranquility はデータをセグメント分割し前処理でビットマップインデックスを構築するため高速なデータ注入をサポートせず高並行性下でも性能が振るわないが、カラム型ストレージとインデックスが後のクエリ性能で報われ、場合によっては InfluxDB を上回る。(III) TimescaleDB は PostgreSQL 由来の行指向ストレージのためクエリ性能が劣り、カラムへの自動インデックスも作成しないが、適応的タイムチャンクにより連続データ注入では非常に高い書き込み性能を達成する。(IV) OpenTSDB はカラム型ストレージの利点を持つ HBase を利用するが、HBase と上位層間の頻繁なシリアライズ/デシリアライズ、およびセルのキー(カラムファミリ・カラム修飾子)の冗長な格納により InfluxDB・Druid に匹敵するクエリ性能を達成できない。HBase は本来シングルノードでなく大規模クラスタ向けに設計されている。 データ圧縮戦略(データ型ごとに異なる圧縮アルゴリズムを使い分けるほど圧縮率が向上)、LSM ツリー(並行書き込み性能を大きく改善するが読み取り性能とリソース消費を犠牲にする)、適応的チャンク分割(書き込み性能とリソース使用の両方を改善しうる)、時間軸に基づくデータチャンキングと二次インデックス(範囲クエリの大幅な性能向上をもたらす)といった、各 TSDB の設計上の工夫が性能差の根本要因であると論文は総括する。 ## 強み / 弱点・課題 **強み** - データロード・データ注入(書き込み)・データフェッチ(読み取り)を体系的に分離して測定する初のベンチマークであり、既存ベンチマークが軽視していた書き込み性能の測定ギャップを埋める。 - DCGAN + 有向グラフ + ランダムウォークによるデータ生成モデルは、実データの形状的特徴を保持しつつ任意規模の合成データを高速生成できる実用的な設計であり、生成過程自体はメモリ内のランダムウォークのため極めて高速。 - 風力発電ウィンドファーム監視という具体的な IoT シナリオに基づき、選択性(Table I)まで含めてクエリ設計の妥当性を明示している。 - 4 つの設計思想が異なる代表的 TSDB(TSM ツリー・PostgreSQL 拡張・カラム型・HBase ベース)を選定し、CPU/メモリ/ディスク入力までモニタリングして性能差の技術的要因を分析している。 **弱点・課題** - 実験は全てシングルノード版の TSDB で行われており、分散アーキテクチャ前提で設計された OpenTSDB(HBase ベース)には不利な可能性があると論文自身が認めている。 - OpenTSDB はデータセット 2(284.5GB)のロードに失敗しており、大規模データでの 4 システム完全比較ができていない(Table III・Table VI で OpenTSDB の値が NULL)。 - ストリーミング処理システム自体は評価対象外であり、TS-Benchmark は TSDB へのデータ操作性能に限定される(論文冒頭でも明記されている制約)。 - GAN モデルの評価は生成波形の視覚的な類似性(Fig. 5〜8)が中心で、生成データの統計的忠実性(相関係数等の定量指標)による評価は報告されていない。