> [!abstract] 概要(arXiv abstract の日本語訳) > 時系列データベース(TSDB)は特定のワークロード特性に最適化された多様なストレージアーキテクチャを採用しており、その結果、従来のベンチマーク手法では見えにくい固有の性能プロファイルとボトルネックが生じる。堅牢なデータバックエンドを設計するシステムアーキテクトは、自分たちのパイプラインにとってどのストレージエンジンが効率的で、どれが将来のスケーラビリティ制約に直面するリスクが最も低いかを理解する必要がある。本論文は SciTSv2 を提示する。これは接続並列性(connection parallelism)・バッチ取り込み(batch ingestion)・時系列の規則性(time-series regularity)・多変量系列(multi-variate series)・混合ワークロード(mixed workloads)・システムメトリクス(system metrics)という 6 つのワークロード次元にわたって時系列データベースを評価するベンチマークフレームワークである。我々は SciTSv2 を用いて、異なるストレージエンジンを代表する 4 つの TSDB を系統的に評価した: InfluxDB(Time-Structured Merge tree)、TimescaleDB(リレーショナルデータベースベース)、ClickHouse(カラム指向)、DataLayerTS(正則時系列に特化)。各次元が、単一軸に特化した専用ベンチマークでは覆い隠されるアーキテクチャ的挙動——規則性依存のトレードオフ、同時実行される読み取りと書き込みの競合、CPU・I/O・ディスク帯域幅それぞれに束縛された固有のボトルネック——を明らかにすることを示す。きめ細かなシステムメトリクスと組み合わせることで、SciTSv2 はアーキテクトに、性能の帰結を根底にあるアーキテクチャ上の原因へと遡って追跡するための診断ツールを提供し、経験的でワークロード固有の根拠に基づいたストレージエンジン選定を支える。 ## 論文情報 - タイトル: Six Dimensions of Benchmarking Time-Series Databases - 著者: Jalal Mostafa・Sandro Melissano(共同筆頭著者)・Nicholas Tan Jerome・Suren Chilingaryan・Andreas Kopmann(全員 [[Karlsruhe Institute of Technology]] 所属) - 媒体: arXiv プレプリント(EDBT '27, 6-9 April 2027, Lille, France への採録原稿。EDBT は査読付き国際会議 International Conference on Extending Database Technology) - 発表年: 2026年(arXiv 投稿日 2026-08-02) - arXiv ID: 2608.01459(cs.DB) - コード: [SciTS リポジトリ](https://github.com/sandrosano/scits)(本文脚注1で言及) - 謝辞: Helmholtz Association および BMBF(助成番号 05A23PMA・05A23PX2・05A23VK2・05A23WO6)の支援を受けた。 ## 概要 本論文は、科学計測(scientific instrumentation)ユースケース向けに開発された TSDB ベンチマーク SciTS の後継である SciTSv2 を提示する。既存の TSDB ベンチマークがいずれも接続並列性・バッチ取り込み・多変量系列・混合ワークロード・システムメトリクスのうち一部しかカバーせず、特に「時系列の規則性(等間隔性)」を評価軸として扱っていない点を課題として指摘し、6 次元すべてを統一的に扱う唯一のベンチマークとして SciTSv2 を設計した。InfluxDB・TimescaleDB・ClickHouse・DataLayerTS の 4 つの異なるストレージアーキテクチャを持つ TSDB を評価し、各次元がそれぞれ異なるアーキテクチャ上のボトルネック(CPU 律速・I/O 律速・ディスク帯域幅律速)を露呈することを実証した。 ## 問題設定 時系列データは (1) timestamp でインデックスされ、(2) 範囲クエリまたは集計・ダウンサンプリングによって参照され、(3) 書き込み集約的(write-intensive)な要求を持ち、(4) 連続する2データ点間の時間間隔が一定である「等間隔(regular/equidistant)」な場合がある、という特性を持つ。DataLayerTS のような新興 TSDB はこの規則性を利用してディスク書き込み量を削減し取り込みレートを高めるが、既存ベンチマークにはこの規則性次元を評価する枠組みが存在しなかった。SciTSv2 は、KATRIN(カールスルーエ・トリチウム・ニュートリノ実験)のような約10万センサーが10 Hz〜0.1 Hzでデータを生成し続ける科学計測環境を想定ユースケースとする。KATRIN は当初リレーショナルデータベース(Microsoft SQL・MySQL)を用いていたが、ACID 制約がデータ量増大時の取り込み・検索のボトルネックとなったため、TSDB への移行を検討している。 ## 提案手法 ### アーキテクチャ SciTSv2 は C# によるクロスプラットフォーム実装で、オブジェクト指向設計・抽象化レイヤー・耐障害性のある設定機構により高い拡張性を持つ。 **Figure 1: SciTSv2 のアーキテクチャ** ![[_attachments/arxiv-2608.01459/fig01-architecture.png]] (Figure 1. Configurator がワークロード定義ファイル(workload.xml)を読み込み、最低1つのデータベースクライアントを起動する。各クライアントの Workload Manager が Ingestion Workload・Query Workload コンポーネントを組み合わせて最終ワークロードを構成する(混合ワークロードの実現方式)。Data Generator Abstraction は Regular/Irregular の2種類のデータ生成器を抽象化し、Database Abstraction は各 TSDB の DML 実装に応じた Database Implementation を介して Target Database Server と通信する。Statistics Collection は Glances Server から収集したシステムメトリクスと合わせて results.csv・sys-resources.csv の2つの CSV ファイルに結果を保存する。Source: Figure 1.) 前身の SciTS は多スレッド非同期ワークロード実行・バッチベース取り込み・並列接続・Glances クライアントによるシステムメトリクス収集を実装しており、6次元のうち接続並列性・バッチ取り込み・システムメトリクスの3つをサポートしていた。SciTSv2 はこれに regularity・multi-variate series・mixed workloads の3次元を追加する。 ### 6つのベンチマーク次元 1. **Connection Parallelism**: 接続クライアント数の関数として TSDB 性能を調べる。 2. **Batch Data Ingestion**: 挿入バッチサイズの違いによる TSDB の挙動を調べる。 3. **Time-Series Regularity**(新規次元): 等間隔性(regularity/equidistance)を利用することで、不規則(irregular)な時系列と比較して取り込み率向上・クエリレイテンシ低下に寄与するかを調べる。 4. **Multi-Variate Series**: 1行に格納される値の数(例: 加速度計の3軸)の関数として TSDB 性能を調べる。 5. **Mixed Ingestion-Querying Workloads**: 取り込みとクエリが同時に発行される現実的な負荷下での性能を測る。 6. **System Metrics**: CPU・メモリ・ディスク使用率等を収集し、ボトルネックを特定する。 混合ワークロードの設計上の工夫として、SciTSv2 は「クライアントの何%が取り込み・何%がクエリを実行するか」という接続数ベースの分割ではなく、**挿入・検索されたデータ点数の比率**に基づいてワークロードを配分する。これにより TSDB が並列クライアントを処理する際に生じうるボトルネックを回避し、「TSDB の本来の目的である時系列データ点の管理」に着目した公平な測定を可能にする。 ### ワークロード定義パラメータ **(Table 2. SciTSv2 ワークロードのユーザー定義パラメータ)** | Name | Description | Workload Type | |---|---|---| | TargetDatabase | 対象データベースサーバの種類(例: InfluxDB, ClickHouse) | Ingestion/Query | | DaySpan | テーブル内時系列全体の長さ(日数) | Ingestion/Query | | StartTime | 保存/取得する最も古いタイムスタンプ | Ingestion/Query | | BatchSizeOptions | 1回の操作で挿入するバッチサイズ | Ingestion | | ClientNumberOptions | 並列クライアント数 | Ingestion | | SensorNumber | シミュレートするセンサー数(カーディナリティ) | Ingestion | | QueryType | クエリ種別(Q1〜Q5)を表す enum | Query | | TestRetries | クエリテストの繰り返し回数 | Query | | DurationMinutes | 時系列データの長さ(分) | Query(Q1〜Q5) | | AggregationIntervalHour | ダウンサンプリング関数を適用する時間窓の長さ | Query(Q3〜Q5) | | SensorsFilter | クエリでフィルタするセンサーID一覧 | Query(Q1〜Q5) | | MaxValue | Q2で使うセンサー値の上限境界 | Query | | MinValue | Q2で使うセンサー値の下限境界 | Query | | IngestionType | 時系列データ生成における規則性 | Ingestion | | MixedWLPercentageOptions | 混合ワークロードの取り込み対クエリ比率 | Ingestion/Query | | DataDimensionsNrOptions | 多変量系列における変数の数 | Ingestion/Query | | Mode | ベンチマークモード(ingestion/query/mixed) | — | ### サポートされるクエリ(KATRIN ユースケースに着想) - **Q1-A(単変量 raw データ取得)**: 1つ以上のセンサーの第1次元の生値を期間指定で取得。 - **Q1-B(多変量 raw データ取得)**: 1つ以上のセンサーの全次元の生値を期間指定で取得。 - **Q2(範囲外クエリ)**: 特定センサーの値が定義範囲外だった期間を検出。 - **Q3(データ集計)**: 1つ以上のセンサーの値を集計関数(標準偏差・平均等)で1値に集約。 - **Q4(データダウンサンプリング)**: 1つ以上のセンサーをサンプリング関数でダウンサンプリング。 - **Q5(2ダウンサンプリング済みセンサー間の演算)**: 2センサーをそれぞれダウンサンプリングし、比較関数(例: 減算)で比較。 ## 新規性 **(Table 1. SciTSv2 と既存ベンチマークの6次元カバレッジ比較)** | Dimension | YCSB-TS | Smart | IoTDB | TS-Bench. | SciTS | TSM | TSBS | SciTSv2 | |---|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:| | Time-Series Regularity | | | | | | | | ✓ | | Multi-variate Series | ✓ | | ✓ | ✓ | | ✓ | ✓ | ✓ | | Mixed Workloads | ✓ | ✓ | ✓ | | ✓ | | | ✓ | | Connection Parallelism | ✓ | | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | Batch Data Ingestion | | | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | System Metrics | | | | ✓ | ✓ | | | ✓ | 既存の TSDB ベンチマーク(YCSB-TS・SmartBench・IoTDB-Benchmark・TS-Benchmark・SciTS・TSM-Bench・TSBS)はいずれも6次元をすべて備えていない。特に time-series regularity はどのベンチマークにも実装されておらず、DataLayerTS のような配列ベースストアの性能特性を評価する枠組みが存在しなかった。SciTSv2 は6次元を統一する初のベンチマークであり、各次元を独立に制御可能な実験変数として扱うことで、性能挙動を特定のシステム特性へ体系的に帰属できる診断レンズを提供する。 ## 実験設定 - **クラウド環境**: IONOS パブリッククラウド上で専用サーバー機2台を占有利用。 - **サーバー機(TSDB稼働)**: Intel Xeon Platinum 8370C @ 2.80GHz(8論理コア、48MB L3キャッシュ)、32GB DDR4 ECC、1TB NVMe SSD(XFS フォーマット)。Glances サーバーを併走させシステムメトリクスを記録。 - **クライアント機(SciTSv2 実行)**: Intel Xeon Platinum 8370C @ 2.80GHz(64論理コア、2 NUMA ノードにまたがる96MB L3キャッシュ×2)、512GB DDR4 ECC。 - **ClickHouse v22.1.3.7**: 1日単位でパーティション分割、主キー (timestamp, sensor_id) でソート、両フィールドにインデックス。max_server_memory_usage_to_ram_ratio=0.9、async_insert=off、index_granularity=8192行。 - **InfluxDB v2.1.1**: Line protocol で挿入。storage-wal-fsync-delay=0、storage-cache-max-memory-size=1048MB、storage-cache-snapshot-memory-size=100MB。 - **TimescaleDB v2.5.1**: TigerData 推奨に基づき12時間チャンク間隔のハイパーテーブル(チャンクがメインメモリの25%以下)。圧縮は7日ごとにホットデータをコールドデータ(カラム形式)へ変換、timestamp・sensor_id でソート。timescaletune で shared_buffers=7994MB、maintenance_work_mem=2047MB、max_parallel_workers=8。PgBouncer で接続プーリング。 - **DataLayerTS**: 正則時系列専用設計。互換性のため不規則時系列もサポートするが、開発者は高負荷ワークロードでの使用を推奨しておらず、本論文でも公平な比較のためDLTSの不規則時系列評価は行っていない。 ## 実験結果 ### 専用取り込みワークロード(単変量・正則/不規則) **Figure 2: バッチサイズ・並列クライアント数の関数としての正則/不規則単変量時系列の取り込みレート** ![[_attachments/arxiv-2608.01459/fig02-ingestion-rate-mono-variate.png]] (Figure 2. CH・DLTS・IF は高い取り込みレートを達成する一方、TS は小バッチで約1 MB/s、大バッチで最大4 MB/sにとどまり、並列クライアント数を増やすとPgBouncerを使っていてもPostgreSQLの並行接続管理の欠陥により約1 MB/s未満まで低下しうる。IF は小バッチ1 MB/sから大バッチ10 MB/sの範囲。CH は疎インデックスと低オーバーヘッドのカラムストレージエンジンにより最大約21 MB/sを達成。DLTS はクライアント数64・128、大バッチで最大約178 MB/sに達するが、小クライアント数・小バッチでは1 MB/s未満まで落ち込む(WAL のチェックポイントで全配列を再書き込みするため)。Source: Figure 2.) **Figure 3: 正則/不規則時系列取り込みにおけるシステムリソース** ![[_attachments/arxiv-2608.01459/fig03-system-resources.png]] (Figure 3. (a)(b) IF・TS・DLTS はCPU使用率75%超に達する一方、CH は同一ワークロードでも25%未満に収まる。(c) メモリ使用量も CH が最も低い。(d) 128クライアント時のディスク帯域幅は DLTS が2〜2.5 GB/sと突出して高く、CH・IF は500 MB/s未満に収まる。CH は高い取り込みレートと低いCPU・メモリ・ディスク使用率を両立しており、資源効率が際立って高い。これは書き込みを直接ディスクに行うMergeTreeアーキテクチャと、時系列インデックス計算にCPUを消費しない軽量な疎インデックスによる。Source: Figure 3.) **Figure 4: 単変量専用取り込み実験全体における取り込みレート対ディスク書き込み帯域幅** ![[_attachments/arxiv-2608.01459/fig04-ingestion-vs-disk-bw.png]] (Figure 4. 並列クライアント数(1, 8, 32, 64, 128)とバッチサイズ(250, 1k, 5k, 15k, 30k, 90k)の全組み合わせをプロット。IF・CH はディスク使用効率が最良(同じ取り込みレートに対しディスク書き込み量が少ない)。DLTS・TS は取り込みレートとの明確な相関なくディスク書き込み帯域幅が高く、Disk Write Amplification(実際に書き込まれるデータ量が論理サイズの倍数になる現象)を示す。DLTSの最大レート約178 MB/sでは実書き込み量が1 GB/s、すなわち意図した書き込み量の5.7倍に達した。これはWALと履歴配列のマージ時に配列全体を再書き込みするアルゴリズムに起因する。Source: Figure 4.) 正則・不規則時系列間で CH・IF・TS の取り込みレートに明確な傾向差は見られなかった。これらのTSDBはバッチサイズ約15000で取り込みレートの上限に達するが、DLTS のみさらに大きなバッチサイズでスケールし続けた。 ### 多変量時系列(専用取り込み) **Figure 5: 1データ点あたりの変数数の関数としての取り込みレート(バッチサイズ15000・並列クライアント64)** ![[_attachments/arxiv-2608.01459/fig05-ingestion-vs-num-variables.png]] (Figure 5. TS・CH・IF は変数数の増加とともに取り込みレートが漸増する。TS は単変量正則時系列での低い取り込みレート(約1.89 MB/s)から、24変数で正則38.21 MB/s・不規則37.99 MB/sに達し IF を上回る。IF は1変数8.98 MB/s(正則)/8.33 MB/s(不規則)から6変数で26.47 MB/s(正則)/24.73 MB/s(不規則)まで増加するが、その後鈍化し12変数30.2 MB/s(正則)、24変数27.39 MB/s(正則)・25.51 MB/s(不規則)にとどまる。CH は24変数で最高(正則68.76 MB/s・不規則58.18 MB/s)を達成。DLTS は12変数まで37.96→59.67 MB/sと増加するが24変数で10.75 MB/sへ急落する。正則時系列はIF(最大約3 MB/s)・TS(最大約5 MB/s)でわずかな取り込み向上をもたらす一方、CH では正則時系列の方が不規則時系列より最大約10 MB/s低下する——これはCHのパーツ構築アルゴリズムが正則データでは連続2データ点を同一パートに集中させディスク競合を増やすため。Source: Figure 5.) **Figure 6: 変数数の関数としてのディスク書き込み増幅係数** ![[_attachments/arxiv-2608.01459/fig06-disk-write-amplification.png]] (Figure 6. TS の増幅係数は1変数の824倍(不規則)/517.26倍(正則)から24変数で40.65倍(不規則)/29.35倍(正則)へ減少する——これはB-Treeインデックスのサイズが一定である一方、変数増加で書き込みデータ量が増えるため増幅率が希釈されるからである。CH・IF は高変数数でも最も低い増幅率を維持する(IF: 20.71倍→6.38倍(不規則)、15.24倍→5.20倍(正則); CH: 9.38倍→5.55倍(不規則)、12.93倍→3.42倍(正則))。対照的にDLTSの増幅係数は1変数21.22倍から24変数238.12倍へ増加する——DLTSは変数ごとに独立したベクターファイルを作成するため、複数変数が別々のブロックに書き込まれランダムディスク書き込みが増えるため。Source: Figure 6.) ### 専用クエリワークロード(単変量) **Figure 7: 単変量時系列のクエリレイテンシ(Q1-A〜Q5)** ![[_attachments/arxiv-2608.01459/fig07-query-latency-mono-variate.png]] (Figure 7. CH は全クエリで最も高いレイテンシを示す(Q2〜Q5で約45〜48 ms、Q1-Aで最大66 ms)。これはCHの疎インデックスが粒度の細かいクエリ結果に対してグラニュール(既定8192行)全体のフルスキャンを要するため。対照的にDLTSは全クエリクラスで最低レイテンシを達成し、Q2の約2.47 msからQ3・Q4・Q5では1 ms未満まで低下する。DLTSは正則性を利用し時系列を連続した等間隔ベクターとしてディスクに保存するため、範囲の端点インデックスを計算するだけで対応するベクタースライスを抽出できる。TS・IFは中間の性能帯にあり、Q1-A・Q2ではTSがIFを上回る(11.15 ms対25.63 ms、9.55 ms対24.54 ms)が、Q3(11.3 ms対11.3 ms)でほぼ収束しQ5(16.7 ms対26.61 ms)で再び乖離する。IFのTSMツリーはタグ(sensor_id)に基づくインデックスで、中程度のカーディナリティのタグフィルタには効率的だがカーディナリティ増大でレイテンシが増加する。TSはPostgreSQLの複合主キー (sensor_id, time) のB-Treeインデックスを効率的に活用する。Source: Figure 7.) **Figure 8: 単一変数(Q1-A)と全変数(Q1-B)のデータ取得クエリレイテンシ(変数数の関数)** ![[_attachments/arxiv-2608.01459/fig08-query-latency-q1a-q1b.png]] (Figure 8. Q1-A(単一変数のみ取得)ではどの TSDB もレイテンシの増加を示さず、変数数はデータ点の1変数取得性能に影響しないことを示す。一方 Q1-B(全変数取得)では全 TSDB でレイテンシが増加するが反応は大きく異なる: IF は1変数23.69 msから24変数698.3 msへ指数的に増加。TS も同様だが緩やかに増加(1変数9.76 ms→24変数38.52 ms)。CH は87 ms→259.43 ms。DLTS は1.35 ms→8.5 msと最も効率的にスケールする。Source: Figure 8.) ### 混合ワークロード **Figure 9: 正則時系列・256並列クライアント(取り込み128+クエリ128)の混合ワークロード性能** ![[_attachments/arxiv-2608.01459/fig09-mixed-workload-perf.png]] (Figure 9. (a) 専用取り込みが53.37 MB/sを達成するのに対し、混合ワークロードでは Ingestion + Q1-B 1:1 で1.35 MB/sまで低下し、Ingestion + Aggregation では最大11 MB/sまで向上する。IF・DLTSも同様の傾向(それぞれ最大9.3 MB/s・8.27 MB/s)を示す。DLTSはCHより取り込みレートが低くなり(§6.1の傾向と逆転)、fractional Q1-B混合ワークロードでは専用取り込みの31.51 MB/sから10 MB/s未満へ急落する——配列ベースストレージにおいて取り込みとクエリがアレイを奪い合うため。TSはPostgreSQLの並行接続管理限界により混合ワークロードでほぼ中立(有意な増減なし)。(b) 高い並列度・混合ワークロードはクエリレイテンシを少なくとも2桁増加させる。CH は最高取り込みレートと同時に全混合ワークロードで最低クエリレイテンシ(Ingestion + Q1-B 1:6で5.72秒〜Ingestion + Q1-B 1:1で6.73秒)を達成。IFはIngestion + Q1-B 3:1(11.156秒)からAggregation(8.55秒)まで挿入データ点数に相関して減少。TSはfractional Q1-Bワークロードで15.54〜15.57秒とほぼ一定、Aggregationのみ17.67秒に増加。Source: Figure 9.) **Figure 10: 混合ワークロードにおけるシステムメトリクス** ![[_attachments/arxiv-2608.01459/fig10-system-metrics-mixed.png]] (Figure 10. (a) CH・IF・TSのディスク書き込みスループットは0.07〜0.29 GB/s台と低く、CH・IFの高い取り込みレート(53.37〜64 MB/s)と合わせてディスク書き込み増幅が最も効率的であることを示す。(b) DLTS・IFはCPU使用率が90%・98%まで達する。IFのCPU使用時間の大半(42.6〜95%)はユーザー空間、DLTSは12.5〜22%がシステム時間。fractional Q1-Bワークロードの読み取りデータ点比率を上げるほどDLTSのシステム時間比率は増加(Ingestion + Q1-B 3:1で12.54%→1:1で14.25%→1:6で22%)し、I/O待機CPU使用率も最大8.53%まで増加する——ingestion checkpointとqueryが同一ベクターファイルを奪い合うため、DLTSは混合ワークロードに主要なボトルネックを抱える。CHは最も高いスケーラビリティを示し、OLAP設計により高い取り込みレート・低いクエリレイテンシ・低いCPU・効率的なディスク使用を両立する。Source: Figure 10.) ## 考察 - **Connection Parallelism & Batch Ingestion**: クライアント数・バッチサイズを変えることで粒度感度が明らかになった。DLTS は高並列・大バッチで卓越するが小バッチ(<1 MB/s)では配列全体のチェックポイント再書き込みにより実用不可能になる。CH・IF・TS は早期に飽和し、TS は中程度以上の並列度でPostgreSQLバックエンドが停滞、IF はTSMファイルのソートに過剰なCPUを費やす。 - **Time-Series Regularity**: 反直感的な限界を発見した——CH は正則データでは疎インデックスされたパーツが少数ファイルに書き込みを集中させ競合を増やすため、むしろ性能が悪化する。DLTS は規則性で繁栄するが不規則データでは崩壊し、狭い特化性を露呈する。IF・TS はわずかな利得しか示さず、それらのシャーディング設計が等間隔性を根本的には活用していないことを証明する。この次元がなければ「規則性は常に有益」という誤った前提を置いてしまう。 - **Multi-Variate Series**: 変数数のスイープにより取り込み限界が露呈した。TS・CH はカーディナリティに対して正のスケールを示す(インデックスオーバーヘッドの償却)が、TS は依然として極端なディスク増幅に苦しむ。IF は6変数でピークに達しその後横ばいとなり、TSMの広いスキーマへの弱さを露呈する。DLTS は各追加変数が別々のベクターファイルとして保存されランダム書き込みを誘発するため24変数で崩壊する。クエリ面では InfluxDB のレイテンシが指数的に増加し、タグベースインデックスが高次元ルックアップに不向きであることを露呈する。 - **Mixed Ingestion-Query Workloads**: 同時読み書き構成(取り込み/クエリ比率のスイープ)は、読み書き競合(read-write contention)が支配的な限界であることを明らかにした。DLTS の単一配列アーキテクチャは著しく劣化する——クエリと取り込みチェックポイントが同一ベクターファイルを奪い合うためCPUシステム時間が22%まで急増する。IF はクエリレイテンシが挿入強度に正比例して増加し、専用テストでは見えない共有資源競合を示す。TS は中立だが低スループットにとどまり、安定性はあるが性能はない。CH のみが混合負荷下で高い取り込みと低いレイテンシを両立し、リアルタイム監視向けのOLAP設計を裏付ける。 - **System Metrics**: CPU・メモリ・ディスクI/Oをファーストクラス市民として収集することで、生の性能数値が診断的証拠に変わった。根本ボトルネックが明確になった: IF はインデックスソートによりCPU律速(最大98%使用率)、TS はチャンクごとのB-Tree書き込みによりディスク増幅が824倍に達するI/O律速、DLTS は配列再書き込みによりディスク帯域幅律速(2〜2.5 GB/s)、CH は高い資源効率を持つ。 ## 強み / 弱点・課題 **強み** - 6つのベンチマーク次元を統一的にサポートする初のTSDBベンチマークであり、既存ベンチマーク(YCSB-TS・TSBS・TS-Benchmark・IoTDB-Benchmark・SmartBench・TSM-Bench・SciTS)のいずれも欠く「時系列規則性」を新規次元として導入した点が最大の貢献。 - 各次元を独立に制御可能な実験変数として扱うことで、性能挙動を特定のアーキテクチャ特性へ系統的に帰属できる診断ツールとして機能する。 - きめ細かなシステムメトリクス(CPU・メモリ・ディスクI/O)の収集により、単なる性能数値ではなく根本原因(CPU律速・I/O律速・ディスク帯域幅律速)まで特定できる。 - KATRIN実験のような科学計測ユースケースの実運用ワークロードに着想を得たクエリ設計(Q1〜Q5)により現実的な評価が可能。 **弱点・課題** - 評価対象は InfluxDB・TimescaleDB・ClickHouse・DataLayerTS の4システムに限られ、他の主要TSDB(Prometheus・VictoriaMetrics・TDengine 等)は含まれない。 - 実験は IONOS パブリッククラウド上の専用サーバー2台という単一環境構成であり、異なるハードウェア構成やクラウドプロバイダでの再現性・一般化可能性は検証されていない。 - DataLayerTS は開発者自身が不規則時系列での高負荷利用を推奨しておらず、本評価でも不規則時系列でのDLTS評価を意図的に除外している——「公平な比較」の代償として、DLTSが最も苦手とする条件下での定量データが得られていない。 - ベンチマークの根拠となるクエリ(Q1〜Q5)はKATRIN実験のユースケースに強く紐づいており、KATRIN以外の科学計測・産業IoT用途への一般化可能性は本文中で明示的に検証されていない。