# HeteroTSDB メトリクス保存のための [[時系列データベース]](TSDA)。[[Yuuki Tsubouchi]] らが提案。メモリベース KVS とディスクベース KVS を階層的に連合(federate)させ、取り込みスケーラビリティ・長期保持・保守性を両立する。プロトタイプ実装 xtsdb は github.com/yuuki/xtsdb で公開、Go + Redis Cluster + Apache Cassandra。 - メモリベース KVS(Redis)のハッシュテーブルインデックスで時系列を定数時間で挿入・更新し、メトリクス数増大に強い。ディスクベース KVS(Cassandra)へ古いデータを移してストレージコストを下げる。([[Scaling Telemetry Workloads in Cloud Applications]]) - 移行はメトリクス単位の **TTL + jitter** による細粒度方式。Flusher が時系列を Gorilla 圧縮して 1 トランザクションでディスクへ書き、jitter で移行負荷スパイクを回避。5 コンポーネント(Ingester / Flusher / Querier / memory-KVS / disk-KVS)。([[Scaling Telemetry Workloads in Cloud Applications]]) - 8 ノードで 1 million time series の取り込みスループットが KairosDB の **3.98 倍**(420k vs 105k pt/s)。時系列数増大時の劣化も小さい。([[Scaling Telemetry Workloads in Cloud Applications]]) - 2017 年 8 月に [[Hatena]] の監視 SaaS [[Mackerel]] に実投入(本番では DynamoDB + S3 の 3 層化・AWS Lambda 化)。([[Scaling Telemetry Workloads in Cloud Applications]]) ## ベンチマーク詳細と要求条件(第 4 章) - ホスト数に対するスケールアウト(100 万時系列): 1 ノードで 52k、8 ノードで 420k データ点/秒とほぼ線形にスケールし、KairosDB の 8 ノード 105k データ点/秒に対し 3.98 倍。([[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 4 Time Series Data-Intensive Application by Automated Data Tiering in Heterogeneous Key-Value Stores]]) - 時系列数に対するスケーラビリティ(単一ホスト): scale variable 1〜10,000 で両システムともスループットは低下するが、HeteroTSDB は KairosDB 比 2.32〜3.58 倍と劣化がより小さい。低下の主因は Redis の定数時間インデックスではなく、時系列数に比例して増える Redis 側の移行オーバーヘッドとみられる。([[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 4 Time Series Data-Intensive Application by Automated Data Tiering in Heterogeneous Key-Value Stores]]) - 移行スループット: TTL(10 分)失効までは 0、失効後にピーク 100,000 データ点/秒、平均 52,000 データ点/秒でディスクベース KVS(Cassandra)へ移行する。Redis メモリ使用量は移行開始後に増減を繰り返しながら上限に達せず推移する(事前割り当て戦略 + TTL ジッタの効果)。([[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 4 Time Series Data-Intensive Application by Automated Data Tiering in Heterogeneous Key-Value Stores]]) - Slack 級ワークロード(秒間 1,200 万データ点)に 3.98 倍のスループット差を当てはめると、必要ホスト数は KairosDB の 915 台に対し HeteroTSDB は 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]]) - メモリベース KVS への要求条件: バイナリ値の逐次追記書き込み・キー単位 TTL 設定。ディスクベース KVS への要求条件: RDBMS レコード・分散ファイルシステムのファイル・オブジェクトストレージのオブジェクトのいずれとも 1 対 1 対応しうる汎用性(HDD のような低速媒体も選択肢に入る)。([[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 4 Time Series Data-Intensive Application by Automated Data Tiering in Heterogeneous Key-Value Stores]]) ## 本番運用の知見(Lessons Learned、Mackerel 2017-08〜2018-08) - プロトタイプとの差異: Ingester 前段へのメッセージブローカー配置(クラスタ全体障害時のデータ損失緩和)、ディスクベース KVS を Amazon DynamoDB・第 3 層に Amazon S3 とする 3 層アーキテクチャ、Ingester/Flusher の AWS Lambda 化。([[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 4 Time Series Data-Intensive Application by Automated Data Tiering in Heterogeneous Key-Value Stores]]) - 障害 1: 特定ノードへの書き込み負荷集中でメモリベース KVS のメモリ消費が上限に達し、OS がプロセスを強制終了。複数メトリクスの時系列が一時的に失われ、メッセージブローカーに残る過去データからの再処理で復旧した。 - 障害 2: 誤った API 呼び出しにより同一メトリクス名・同一 timestamp のデータ点が異常件数挿入され、Redis クラスタへの挿入クエリがサイズ上限を超過してエラー・リトライによる処理遅延を招いた。取り込み前の重複排除で再発を防止した。 ## 関連 - 本ソース: [[Scaling Telemetry Workloads in Cloud Applications]] / [[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 4 Time Series Data-Intensive Application by Automated Data Tiering in Heterogeneous Key-Value Stores]] - 開発者: [[Yuuki Tsubouchi]] - 実運用: [[Mackerel]] / [[Hatena]] - 比較対象: [[KairosDB]] - 構成要素: [[Redis]](メモリベース KVS) / [[Apache Cassandra]](ディスクベース KVS) - 関連概念: [[時系列データベース]] / [[テレメトリ]] / [[アーカイバルストレージ]]