TimescaleDB vs. InfluxDB Part-1

TimescaleDB vs. InfluxDB: purpose built differently for time-series data

Published in

Orangesys

15 min readDec 26, 2018

データモデル、クエリ・ランゲージ、信頼性、パフォーマンス、エコシステム、運営管理、会社やコミュニティーのサポートなど色々な場面について、どのようにこの二つ（TimescaleDB と InfluxDB）の優れた時系列データが積み重なっているかということについての詳しいお話をしたいと思います。

時系列データは、IoT, DevOps、ファイナンス、卸売業、流通業、オイルやガス、製造業、自動車関連、航空宇宙産業、SaaS、更には機械学習やAIなどを含むアプリケーションにおいてよく見られるようになりました。特に最近では時系列データへの注目がかろうじてメトリック、モニターに移り、今日ではソフトウェアのデベロッパーたちは、色々なオペレーショナル・ワークロードのためにデザインされた本格的な時系列データベースが必要だと思っています。

もしあなたが時系列データベースに投資をしているのであれば、それはあなたが意味のある量の時系列データベースを素早く貯めていて、それを保存したり分析したりする場所が必要だということです。ご自身のビジネスの将来を決めるのは自分で選んだデータベースにかかっているということをご存知だと思います。

How to choose a time-series database

自分のワークロードのための時系列データベースを比較するためには色々な要因を熟慮する必要があります。

データモデル
クエリ・ランゲージ
確実性
パフォーマンス
エコシステム
運営管理
企業とコミュニティー

この記事では、私たちはこの二つの優れた時系列データベースであるTimescaleDB と InfluxDBを比較したいと思います。ソフトウェアのデベロッパーたちが時系列データベースを選ぶ際に自分のニーズにあった最適なものを選ぶ助けになればと思っています。

典型的なデータベースを比較するときには、パフォーマンスのベンチマークに注目します。しかし、パフォーマンスはただの全体像にしかすぎません。つまり、もしデータベースがその商品で使えなくても、ベンチマークがどのくらい優れているかということは関係ありません。というのも、それは、それが比較不可能なデータモデルであるか、もしくはクエリ・ランゲージ、もしくは信頼性が不足しているからです。そういうことを念頭において、パフォーマンスのベンチマークを掘り下げてお話する前に、私たちはTimescaleDB と InfluxDBを比較することから始めたいと思います。データモデル、クエリ・ランゲージ、確実性という３つの特徴を切り口としてみていきます。それから、データベースエコシステム、運営管理、企業やコミュニティーのサポートという局面から比較して、まとめたいと思います。

もちろん、私たちはTimescaleDBのデベロッパーなので、この比較にはバイアスがかかっていると思うかたもいると思います。しかし、分析結果を見ていただくとこの比較が客観的なものだとお分かりいただけると思います。実際に私たちが比較した結果TimescaleDBよりもInfluxDBの方がより優れているという場面もいくつかありました。

またこの比較はものすごく理論的なものではありません。弊社はIoTのプラットフォームとして始まりました。最初は自分たちのセンサーデータを保存するためにInfluxDBを使っていました。しかし、下に列挙した私たちの目的とは異なる部分も出てきたため、不本意ながらInfluxDBを使うことにしました。そのため私たちは自分たちのニーズに合った最初の時系列データベースとしてTimescaleDBを開発しました。そして、そのデータベースをオープンソースにしようと決めたとき、TimescaleDBを私たち意外にも必要としている人もいることが分かりました。その時から１年と５か月後の今、TimescaleDBは既に何百回、何千回とダウンロードされ、世界中の製品でデプロイされています。（TimescaleDBの始まりについてのより詳しい説明はこちらからどうぞ)そして最後に、自分のニーズに合った最適な時系列データベースを決めるお役に立ちたいというのが私たちの目的です。

What about “scalability”?

上のリストをよく見てもらうと「スケーラビリティ」や「クラスタリング」という言葉が入っていないことに気づかれたでしょうか。デベロッパーがそれらの三つの必要な条件を求めているということが分かりました。その３つの条件というのはa)パフォーマンスメトリック b)高い確実性 c)保存容量これらの３つです。この３つを包括的にまとめてお話するよりも、一つ一つを個別に話をする方がより分かりやすいと思いました。

Data model

データベースは独特です。データベースがモデルと自分のデータを保存するときの選択の仕方で、自分がそれで何ができるかということが決まってきます。

データモデルに関して言えば、TimescaleDB とInfluxDBは２つのすごく異なるこだわりを持っています。TimescaleDBは関係データベースですが、一方InfluxDBはよりむしろカスタム、NoSQL、非リレーショナルデータベースです。これはTimescaleDBがリレーショナルデータモデルに依存していて、一般的にPostgreSQL, MySQL, SQL サーバー, Oracleの中で見られるということを意味しています。その反面、InfluxDBは自信のカスタムデータモデルを開発しました。我々はそれをタグセットデータモデルと呼んでいます。

Relational data model

relational data model（リレーショナルデータモデル）は数十年前から利用されています。 TimescaleDBにあるリレーショナルモデルを伴っていて、それぞれの時系列測定はそれ自身の中に今は記録されます。いくつもの他のフィールドにフォローされている時間フィールドを伴って、その他のフィールドというのはfloats, ints, strings, booleans, arrays, JSON blobs, geospatial dimensions, date/time/timestamps, currencies, binary data, またもっと複雑なデータタイプのものである可能性もあります。どのフィールドの上でもインデックス（スタンダードインデックス）、マルチプルフィールド（コンポジットインデックス）、機能のようなexpressionを作れるもの、またもあります。インデックスに行のサブセットの制限をかけること（部分インデックス）もあります。それらのどのフィールドも第二テーブルへの外部キーとして使われます。そして、追加したメタデータを保存することが可能です。

下に例を表示します。

このアプローチのメリットは、すごくフレキシブルなところにあります。

狭い、もしくは広いテーブルどのくらいのデータ、どのくらいのメタデータがリーディングごとに記録されるか
クエリをスピードアップするたくさんのインデックス、もしくはディスクの使用を減らす少ない数のインデックスか
測定の列の非正規のメタデータ、もしくはセパレートテーブルの中にある正規データはどちらもいつでもアップデート可能です。（ただ後者の方が簡単にできます）
入力タイプを検証するリジッドスキーマ、もしくはインテレーションのスピードを上げるスキーマレスのJSON blob
例えば独自性、non-null 値をチェックするというように、入力を検証するCONSTRAINT (テーブル

このアプローチのデメリットは開始をすることです。スキーマを選ぶ必要があるものもあります。そしてインデックスがあるかないかをはっきりと決めます。

補足：過去何年間で、それはスケーラブルではないということを主張することで、リレーショナルモデル（関係モデル）を批判してきたことで有名になってきました。しかし既に見てきたように,これは真実ではありません。リレーショナルデータベース（関係データベース）は時系列データをすごくきちんと計測することができるのです。

Tagset data model

InfluxDB のターゲットデータモデルを同時に使用すると、それぞれの計測にはタイムスタンプ、関連したターゲットのセット（タグセット）、フィールドのセット（フィールドセット）が持てます。フィールドセットは値を読む実際の計測を意味します。一方で、タグセットは測定を表示するためのメタデータを意味します。フィールドデータタイプのものは、float, ins, string, booleanなどに制限をかけます。そしてデータを書き換えないと変更することはできません。タグセットの値はフィールドセットの値がインデックスされていないとインデックスされません。またタグセットの値はいつもstringを意味していて、アップデートされません。

下に例を挙げています。

このアプローチのメリットは、もしあるデータがタグセットモデルにフィットしたら、始めるのがとても簡単だというところです。スキーマやインデックスの作成を心配する必要がありません。逆に、このモデルのデメリットとしては、フレキシブルさがあまりないことと制限があることです。追加でインデックスを作成することができないし、継続的なフィールド（例えばnumerics)でインデックスを作れない、また事後にメタデータをアップデートする、データ妥当性検証を強制するなどです。特に、このモデルは「スキームレス」というような感じがするけれども、実際にはスキーマが基盤となっていて、それはインプットデータから自動作成されます。そのスキーマは自分が希望したスキーマとは違ったものになるかもしれません。

Data model summary

もし自分のデータが完璧にタグセットデータモデルにフィットするのであれば、そして、将来的に変更するためにフィットすることを期待していないのであれば、InfluxDBを使うことを検討してみてはいかがでしょうか。というのもこのモデルは始めるのが簡単だからです。しかし、リレーショナルモデルはもっと用途が広く、もっと多くの機能があり、フレキシビリティがありコントロールが簡単です。自分のアプリケーションが進化するとこれは特に重要です。そして自分のシステムをプランニングするときには、今と将来の両方のことを考える必要があります。

Query language

一般的に、データベースクエリランゲージの世界では、二つの極論が存在しています。一つはフルSQLサポート、そしてもう一つは完全なカスタムランゲージ（これは「NoSQL」として知られています）です。

より詳細を知りたい方は、最近公開したSQL vs. Fluxの比較をご覧ください。

最初から、TimescaleDBはしっかりとスペクトラムのSQL endで存在していました。day 1からのランゲージを完全に取り込んでいます。そして、その後よりそれを広めていき、時系列分析をシンプルにします。このおかげでTimescaleDBが新しいユーザーにとって最小限のラーニングカーブ（学習曲線）を描くようになります。そして、サードパーティの全てのSQLシステム、コネクター、視覚化オプションなどを引き継ぐことを可能にします。そしてそれは他のどの時系列データベースよりも大きいです。

それに比較するとInfluxDBは「SQLのような」クエリランゲージ（InfluxQLと呼ばれる)とともに始まりました。それをスペクトラムの中心に置きます。そして、InfluxDBは最近新しいFlux クエリランゲージを伴った「カスタム」エンドに向かって大きな動きを見せました。これでInfluxDBが今まで体験したSQLの欠点をクリエイターが克服しようと主張してきた新しいクエリランゲージを生成できるようになりました。（Flux announcement、Hacker News reaction,そしてSQL vs. Fluxの比較をぜひ読んでみてください)

高いレベルにおいては、その二つのランゲージシンタックスが例のようにexponential moving average（指数平滑移動平均線）の計算方法を使ってどのように比較するのかを見てみましょう。

TimescaleDB (SQL)

SELECT time,exponential_moving_average(value, 0.5) OVER (ORDER BY time)FROM metricsWHERE measurement = 'foo' and time > now() - '1 hour';

InfluxDB (Flux)

from(db:"metrics")|> range(start:-1h)|> filter(fn: (r) => r._measurement == "foo")|> exponentialMovingAverage(size:-10s)

まとめ：ほとんどの使用例では、私たちは、SQLは時系列データベースのための正しいクエリランゲージだと思っています。

一方Fluxはタスクをより簡単にするかもしれません。カスタムクエリランゲージを使用するために重要なトレードオフがあります。実際は、新しいクエリランゲージは重要なオーバーヘッドを導入し、リーダビリティを下げます。それらが原因で新しいユーザーに急激なカーブのラーニングカーブを強いて互換性のあるツールの希少性を有するようになります。

そして、新しいクエリランゲージは実行可能な選択肢にさえもならないかもしれません。システムの再構築と、企業が新しいクエリランゲージを読んだり書いたりするように再教育するのは、あまり現実的ではありません。特にその企業がデータベースに加え、すでにSQLの互換性ツール（例えば視覚化のためのTableau ）を使っているのであれば余計です。だからこそSQL が一般的にデータ・インフラストラクチャーのためのクエリランゲージとして再び普及し始めているのです。

Reliability

データベースのその他の基本的なルール：データを破損したりデータを失ったりすることはできません。TimescaleDBとInfluxDBが用いるアプローチは全く正反対で、それはリライアビリティー（信頼性）に影響してきます。

そのスタートの時点で、InfluxDBは完全にGoの中で完全なデータベースを書き込もうとしました。実際、0.9のリリースで一か八かの賭けをすることにしました。完全にバックエンドストレージエンジンをリロートしました。（Influxの前のバージョンはLevelDや RocksDBなどを伴うプラガブルバックエンドのような方向に進んでいました）このアプローチには本当にメリットがあります。例えばInfluxDBがFacebookのGorillaエンコーティングの使用が終わったとき、特定の状況で使いやすい特定のドメイン圧縮アルゴリズムを構築することができる、などです。

しかし、それらの基本設計はリライアビリティーに影響する重要な意味を持っています。まず、InfluxDBはレプリケーション、高い可用性のある、そしてバックアップもしくはリストアを含むフォールトトレラントな（故障が起きてもバックアップシステムを使うなどして動作に支障がない）メカニズム一式を実装しなければいけません。次に、InfluxDBはディスク上の信頼性を担っています。例えば、全てのデータストラクチャーは耐久性があり、データ破損を食い止めます。（そして、エラーのリカバリーの間のエラーでさえも阻止してくれます）

そのアーキテクチュアル・デシジョン（構築的な決定）のために、一方では、TimescaleDBはむしろ本当に重要なアプリケーションをサポートすることのできる堅実なデータベース化を構築したPostgreSQL コミュニティーが取り組んできた慎重で熱心な25年以上に及ぶ技術に頼っています。

実際、これは私の共同創始者である人物のTimescaleDBについての発売に関する記事です。こちらをどうぞ「暇な時間は素晴らしい」。市民権のないマイクロサービスは壊れるかもしれないし、再起動するかもしれない、もしくは無駄にスケールアップしたり逆にスケールダウンしたりするかもしれません。実際、これが“リカバリーに根差したコンピューティング”フィロソフィーの全てです。新しい「サーバーレス」のデザインパターンを考えることと同じです。しかしあなたのデータベースは実際に永続データが必要であり、何かが壊れて朝の３時にあなたが起こされるべきではありません。

次回は、TimescaleDB vs. InfluxDB パート２に続きます。

Orangesys.ioでは、kuberneteの運用、DevOps、監視のお手伝いをさせていただいています。ぜひ私たちにおまかせください。