時系列DBの概略
歴史的経緯
約10年くらい？前から devopsという考え方がでてきた。そのアクティビティの一つに、可視化、特にアプリケーションメトリクス（例：サイトの現在の閲覧者数）や、インフラのメトリクス（CPU使用率等）を収集し、ほぼリアルタイムな可視化をすること、が盛り上がりを見せていた。
当時それを提唱・実行に移していたのが Etsy というECサイトのメンバで graphite と呼ばれる一連のツール(収集：carbon,格納:whisper,可視化:graphiteweb)や、それを効率よく集めるためのツールstatsd等でそれを見事に体現して見せた。
当時より（graphiteでは）メトリクスは、ドットで区切られる名前空間で識別されており、host.cpu.idleのようにCPU使用率を表したり、 clicks.item813 で商品のクリック数を識別するような形で、<メトリクス名, 時刻, 数値>というデータ、すなわち時系列データで表されていた。
運動に盛り上がりが見られた一方で、ツールとしてのgraphiteは開発が止まってしまっており、各種現場で得られたあらたな要求を満たすのが難しくなっているという状況があった。例えば以下のようなことが挙げられる。
- [収集] メトリクス名が多すぎ・長すぎるので構造化したい
- [格納] 過去のデータを後から入れたい
- [格納] 格納効率を上げたい
- [格納] もっとスケールしたい
- [可視化] もっとかっこよく、カスタマイズ可能なダッシュボードがほしい
ここまでが歴史的経緯と、課題観の共有。
時系列DB戦国時代
このような背景から、いくつもの時系列DBが提唱され、淘汰されていった。現在でも残っているのは、（個人的に有望と感じるものから順に）以下のようなものが挙げられる。
- influxdb: Go製 graphiteのよき後継者
- prometheus: Go製 Influxdbよりシンプルだが格納効率が高い
- elasticsearch: Java製 時系列DBではないが、時系列DBとしても使える。
- OpenTSDB: 古株。HBaseを利用することによって高い可用性を持つ
それぞれが独自のプロトコル（主にHTTP RESTが多い）を持つが、互換性はない。ただ、どれも簡易なプロトコルであるため、アプリケーションから時系列データを格納するのはそれほど難しくない。どの製品も基本機能は満たし、クラスタリングやレプリケーションなど応用的な機能にフォーカスしている。
時系列DBに格納されたデータを可視化する製品は、時系列DBに付属していることが多い。
- Grafana: Go製 Webサーバ機能を同梱し、単体で動作する. Kibanaからfork
- 各種時系列DBに付属の製品
- Kibana: ElasticSearchの可視化ツール。 Grafanaに多大な影響を与えた
とりわけGrafanaという製品は、前述の時系列DBすべてに対応しており、また開発が活発で機能も充実しているため、事実上のデファクトスタンダードになっている。
今とこれから
日本国内ではあまり技術的な資料がないが、Elasticseachに、fluetndで集めたログを送信して、Kibanaで可視化する方法はよく見られる。いわゆる EFKスタック （なお、欧米では fluentdではなく、 logstash を利用するので ELKスタックと呼ばれる）がある。
とはいえ、Elasticsearchはログ分析のソフトであって時系列DBではないし、Kibanaも若干機能性に不足感が否めないため、時代の潮流に乗って、 influxdb + Grafana や、prometheus + Grafana などに乗り換えるのが吉ではないかと考える