時系列データベース-TSDB

Published in

Orangesys

12 min readJul 8, 2017

近年、TSDB(時系列データベース)が人気上昇中。

仕事関係のため、最近では、時系列データベースについていくつかを読んで、もちろん、私も参照したのはオープンソースのTSDBです。ハネムーン期間が後退していない間、いくつかの情報を整理することを望んで。もし、あなたにもこの辺の情報を収集されてるところなら、役に立つかもしれない

1 時系列データベースとは（time series database）?

最初、時系列データベースを聞くと、ほとんどの方は、すぐに運用と監視システムを関連付けることがあります。

確かに、多くの運用、や監視システムは、データベースシステムとしての時間の膨大な量を格納するために TSDB を使用すると、ある程度、様々な指標の非常に単純構造 (英語はmetric、measurement、または他の単語に似ている) データ。

1.1 TSDBの定義とは

これはウィキペディアの説明です:

A time series database (TSDB) is a software system that is optimized for handling time series data, arrays of numbers indexed by time (a datetime or a datetime range).

訳とは、時系列データを配列データベースに格納し、時間 (ドットまたは間隔) でインデックスを作成するときに使用されるソフトウェアです。 ”

そして、時系列DBの定義が下記となります。

ユニークに識別できるシーケンス名/ID（例 cpu.load.1）及び meta-data
一連のデータポイント{timestamp, value}。timestampはUnix タイムスタンプ、普通は精度が高い、例えば、influxdbの場合は、ナノ秒です。一般的なTSDBは秒以上の精度を持ってます。

時系列DBは下記の2つ特徴があります。

単純なデータ構造
大量のデータ

単純なデータ構造とは、1つの時での値を持つだけであることです。

大量のデータは、サーバ、iot デバイス、端末、アプリなど、多数のデータソースが監視され、時系列のデータが生成、収集、送信されるため、もう1つの重要な機能です。

2、TSDBの特性

時系列なデータ最適化のために設計されたデータベースとして、TSDB は、パラダイムやトランザクションを気にしないなど、多くの点で従来の rdbms および nosql データベースと同じではありません。

その他の特性には、次のポイント

2.1 データの書き込み

読み取り以上の書き込み:95%-99% の操作は書き込み操作です
シーケンシャル書き込み: 時系列データなので、データは追加書き込みよりも多く、ほとんどすべてのリアルタイム書き込みであるため、数日前にデータが書き込まれることはあまりないです。
更新されない: データが書き込まれた後、更新されません。
ブロック (一括) 削除: 基本的にランダムな削除がありません、時間内のポイントの時点からのすべてのデータの削除をします。たとえば、先月または7日前にデータを削除します。ジャンプ期間のデータ削除や、一定的な期間中に、一つのデータを削除にもありません。

ブロックの削除は、別のファイルにチャンクで別々に格納することができるように、最適化することは簡単ですので、チャンクを削除するだけでファイルを削除する必要がある、コストは比較的低くなります。

2.2 データの読み取り(search)

TSDB の読み取り操作は次のように特徴付けられます。

シーケンシャル・リード: 基本的に時系列でデータを読み込みます。
読み取りデータ大量: 基本的なデータは、メモリサイズよりも大きい、全部読み取りが不可能となり、そのの一部を選択するには、ランダムの場合はが多い、ほとんどキャッシュできない。
読み取りが少ないですが、応答時間が厳しいです。バックグラウンドレポートの生成以外、対話型の操作がある場合は、迅速な応答を要求する必要があります。

読み取りの応答時間を改善するために、2つの戦略があります:

まず、書き込みのパフォーマンスが優先され、読み取りストレージの最適化ではなく、分散と同時読み取りを通じて、読み取り速度を向上させます。

次の読み取りパフォーマンスの問題は、統一された指標は、時間帯のデータは、データの同じブロックに書き込まれるときに書き込むには、読み取りの最適化を書くことです。

2.3 分散システム

TSDB は、分散およびパーティション分割の特性を考慮して、大規模なデータ収集およびクエリ要求をサポートするために、ストレージとクエリを異なるサーバーに配布する必要があります。

同時に、それはまた拡張し、自動失敗の切換え (フォールトトレラント) できるべきである。データの量が増えるにつれて、必要なサーバーの数が増加し、動的または減少するサーバーは基本的な要件になります。同時に、サーバーの増加に伴い、様々なサーバーやネットワーク障害が発生する確率を高めることができる、この時間の障害の切り替えも重要ではなく、マシンの障害のためにクラスタ全体が動作しない原因となります。

2.4 基本的なデータ分析のサポート

TSDB データは分析に使用されるので、TSDB はデータ分析を行うために必要な各種の操作や変換も提供します。たとえば、従来の rdbms のように、シーケンシャル列のデータを合計して平均すると便利な場合があります。

3. オープンソースの時系列データベースを選定基準

ケースバイケースですが、私は次の要因を考える、参考になると幸いです。

除了功能上能满足、性能上撑得住，运（售）维（后）等也是我们准备长期使用所必须面临的问题。

機能満足に加えて、性能、運用コスト、メンテナンスなどにも、長期的な選定時、考慮しないといけないポイントです。

私自分の評価基準が下記のポイントを含まれてます。

3.1 パフォーマンス

これは、主に読み取りと書き込みのパフォーマンスです、前文、すでに紹介されてるTSDBの機能です。

前分を通じて、TSDBは書き込みが99.9%、書き込みのパフォーマンスが最重要となり、書き込みの遅延が許さない、読み取り操作でブロックすることもできませんし、読み取り操作がすぐに最新のデータを返すことができることを知っている。

また、多くのユーザーは、クラウド上で運用されていますが、iopsの部分を考慮しないといけないです。

3.2 ストレージ (またはエンジン)

ストレージは、主に読み取り/書き込みのパフォーマンス、クラスタリングの展開の容易さ、およびトランスポートディメンションの複雑さによって影響を受けます。典型的なストレージスキームは、hdfs、hbase、Cassandra、LevelDB、BoltDB、などです。

3.3 クラスタ機能

一般来说，集群主要集中为存储和查询的集群功能，也代表其可扩展性，因为时序列数据库的数据量很可能很大，并且增长趋势不可预测，尤其是随着大数据和物联网的兴起，GB 已经算入门，TB 也是刚起步。

一般的には、クラスタとはストレージとクエリの部分、要は、スケーラビリティの機能です。時系列データベースのデータが巨大化になり、特にビッグデータと iot の発展に伴い、成長傾向は予測不可能であり、スタートラインはGB、TB対応にも必須となります。

3.4 api (http api およびクライアントライブラリ)

TSDBがカスタマイズする必要の場合、または単にストレージを作るために TSDB を使用する,apiの完成度は非常に重要なポイントとなります.

さいわい、ほとんどの TSDB は http api を提供し、単純なテキスト形式に加えて、json 形式の入力と出力に対する多くのサポートがあります。

さらに、クライアントライブラリがあれば、再開発コストを抑えます。

3.5 sql のようなクエリ言語

同じような従来の sql によってメトリックを照会できる場合は、TSDBの学習コストを抑えし、分かりやすいし。

select mean(value) from metric where role=’user’ and time >= xxx and time <= yyy group by dc

3.6 チームの経験

つまり、導入が容易で、特に製品として、多くのエンタープライズ製品の導入や、時間を費やしてアップグレードのインストールでは絶対にありえないです。したがって、簡単な展開は、単一ボタン展開であるかどうか、スタンドアロン展開などの重要指標です。依存関係コンポーネントが追加されているかどうかなど。

同時に、導入コストには、今後メンテナンスコストにも関係があります。

3.7 完成度

ソフトウェア自体の完成度、もしくはecosystemの完成度。

3.7.1 生態系

ecosystemは、主に周囲のツール、プラグインの豊かさ、およびアクティブなコミュニティの度合いを指します。

ソフトウェアの生態系は、オープンメカニズムで、プラグイン (拡張) メカニズムは、直接、サードパーティは非常にシステムに拡張するために便利なことができるかどうかを決定する、非常に大きいです。

3.7.2 開発活動

これは、TSDB プロジェクトの送信レコード (github からの開発ステータスなど)、問題の解決、プル要求のマージ、およびリリースの頻度から確認できます。

ロードマップを提供するいくつかの TSDB プロジェクトがあり、我々はロードマップを介してソフトウェアの将来の方向性と機能を学ぶことができます。

3.7.3 コミュニティパックのアクティビティ

主にドキュメントの豊かさなど、関連するブログが十分であるかどうかを確認するために google で検索することができます、また、関連する議論に stackoverflow を見ることができます。

最も重要なコメントは、専門のコミュニティ (ops 関連のディスカッショングループやコミュニティなど) に表示される TSDB の頻度と、関心の度合いです。

3.7.4 導入事例(ユースケース)

大規模な、大企業の実際の生産環境の展開ケースはありますか? どのように大規模な、パフォーマンス、問題はありませんが、重要要因です。大企業の信頼の裏書があり、多くの救助の選択に、より少なく絡まっている。

たとえば、ホームページ上のドルイドは、ドルイドを使用して企業の多くを示しています:

http://druid.io/druid-powered.html

3.8 可視化とアラート機能

TSDB になると、簡単に考えられる2つの機能は、視覚化とアラートです。 TSDB は、強力なビジュアルコンポーネントとアラームのサポートを持っている場合, それは多くの開発コストを節約することができます, より簡単にユーザーを引き付ける. 開発でも、開発プロセス中にデバッグと検証を容易に行うことができます。

ELKを流行ってる理由とは、強力な機能に加えて、配置がシンプルで、完全に機能する魅力的な場所です。

3.9 使用される技術スタック

メインプログラムは、どのようなプログラミング言語が使用され、どのサードパーティ製のモジュールが利用可能です。いくつかの java で書かれている、いくつかの使用 Golang、いくつかの hbase を使用して、いくつかの独自のストレージスキームを使用して、いくつかの豊富な ui を持って、いくつかのだけで簡単にデバッグインターフェイスを提供します。

技術スタックは、TSDB によって使用される技術は、開発と輸送の寸法の複雑さに影響を与えるので、考慮する必要がある要因でもあり、また、既存の資産に影響されます。たとえば、hbase に精通した人がおらず、java 言語に不慣れな場合は、おそらく Influxdb の方が適しています。

3.10 リテンション・ポリシー (リテンション・ポリシー、または自動削除、圧縮)

自動削除は、データの ttl を設定し、指定された ttl は、クエリのパフォーマンスを改善しながら、ストレージ領域を節約するために関連するデータを自動的に削除されます。

如果不删除数据，也可以对数据进行压缩，或者再采样（Resampling），比如对最近 1 天的数据我们可能需要精确到秒，而查询 1 年的数据时，我们只需要精确到天，这时候，海量的数据一年只需要 365 个点来存储，大大节省了存储空间。

データを削除しない場合は、データを圧縮したり、リサンプリング (リサンプリング) したりすることもできます。たとえば、1日のデータを検索すると、精度は秒間単位、1年のデータを検索すると、日単位で十分となります、そうすると、1年データを保存すると、365データポイントだけ、大幅ストレージ容量を抑えます。

3.11 開発会社の裏側

商業会社のフルタイムの開発、両刃の剣かもしれません。

利点は、プロジェクトのメンテナンスを心配することなく、バグがあれば、修復にも期待できます。

但し、今後もメンテナンスコストが高くかもしれない。たとえば、elasticsearchは、ELKを構築する、比較的簡単ですが、プロダクション環境利用すると、権利やバグなど自立で対応しないといけない、もしくはelasic社のサポートを購入する。

3.12 ライセンス

これは最も弱い要因の一つかもしれませんが、それを商品化したいのであれば、それはまた非常に重要であり、致命的な要因でもあります。

3.13マルチテナントサポート

需要が少ないかもしれませんが、SaaSサービス運用の場合は、物理的な隔離は理想的ですが、残念ですが、既存のTSDB商品はここまで対応していない。

3.14 セキュリティ

例: 権限管理、アクセス制御など

セキュリティ基本的な必要性は、インターネット上に公開されてるサービスなら、セキュリティはかかせいないものです。

セキュリティ面にも、2つポイントがあります。1つのUI層、すなわち、管理インターフェイスまたはコントロールパネルです、一方では、api レベルのユーザー認証です。