# Databus National Renewable Energy Laboratory(NREL)が開発したオープンソースの時系列データベース。エネルギー監視用途に特化して設計されており、1 秒粒度での大量データ収集・格納を主要機能とする。Cassandra 1.2.8 をストレージ層に使用する。 データモデルとして 2 種類のテーブルを持つ: - **Stream テーブル**: 時系列データ用 - **Relational テーブル**: リレーショナルデータ用 さらに SQL モジュール・スプライン計算モジュールなどの変換モジュールをサポートする。Mozilla Public 2.0 ライセンス。 [[@2014__IEEE CLOUD__Scalability and Robustness of Time-Series Databases for Cloud-Native Monitoring of Industrial Processes]] での評価バージョンは 1.1.0(95,418 LOC、アクティビティ 113 コミット / コミッタ 2 名、2013 年 10〜12 月)。LOC が他 2 システムより大幅に大きい。 ## ベンチマーク結果(IEEE CLOUD 2014) 3 種の被評価システムのうち、[[KairosDB]] と OpenTSDB の中間的な結果を示したが、重大な制限が確認された。 **スケーラビリティ(PMU Write)**: - 36 ノードで線形スケールが崩れ(原因を特定できず、著者への問い合わせでも不明) - 24 ノードでの最大容量は約 65 PMU(Figure 7)——KairosDB 比で 1/6 程度 **スケーラビリティ(SmartMeter Write)**: - 線形性は維持するが処理スマートメータ数は KairosDB の約 1/10(Figure 9) - HTTP 接続スロットリング機構がピーク需要への柔軟な対応を阻害する **HTTP 接続スロットリング機構**: Databus は HTTP 接続を受け入れた後、前のバッチの書き込みが Cassandra に完了するまで本文の読み取りを開始しない。これにより Cassandra バックエンドへの非同期書き込みとクライアント読み取りが分離されず、ピーク需要時の柔軟性が制限される。 **リソース特性**: - CPU バウンドだが効率が低い: Cassandra:Databus = 30%:70%(KairosDB の各 50%:50% と対照的) - 個別ノード単位では CPU の均一分散を達成 **ロバスト性の課題**: - 急激なトラフィック増加時にノードが Databus 側 CPU で 100% 張り付きになり、接続終了後も数時間回復しないケースがある——並行接続処理のバグが疑われる - JVM メモリ不足が発生(ヒープ 1GB → 4GB に増やすことで解決) **読み取り試験**: 15 時間の投入フェーズで繰り返し問題が発生したため実施できなかった。 ## 関連 - 概念: [[時系列データベース]] / [[時系列データベースベンチマーク]] - 論文: [[@2014__IEEE CLOUD__Scalability and Robustness of Time-Series Databases for Cloud-Native Monitoring of Industrial Processes]] - 比較対象: [[OpenTSDB]] / [[KairosDB]]