2016-10-02 9 views
0

クラスタセットアップモードとプロダクションレディで自由に使用できる分散型時系列データベースを探していますが、それはhadoopエコシステムに適しています。リアルタイムアナリティック時系列データベース

私は10時間または1時間ごとにデータを送信するセンサーが基本的に約150kであるIOTプロジェクトを持っていますので、メトリックの集計、ダウンサンプリング、事前収集などの便利な機能を持つ時系列データベースを調べようとしています。私はこのGoogleのスタイルシート文書time series database comparativeでこの比較を見つけました。私はOpentsdb、hbaserowkeyのデータモデルをテストしている

は本当に私のユースケースに合った:しかし敷居必要が私のユースケースのために開発される機能は以下のとおりです。

  • 集計倍数メトリック
  • が行うロールアップ

私はまた、より豊富なAPIとopentsdbのフォークですkeirosDBをテストして、それが事は彼らのAPIは私が倍数の指標を問い合わせるロールアップダウンサンプリングを探しているものをすべてと多くのないことであるバックエンドストレージとしてカサンドラを使用しています。

ここではWarp10.ioとApache Phoenixをテストしましたが、Hortonworks linkはAmbari Metricsで使用されるので、時系列データにも適していると思います。

私の質問は、すべてのタイプのリクエストに対して1S未満のリクエストパフォーマンスでリアルタイムアナリティックを実行するのに最適な時系列データベースです。たとえば、以下の期間に50個のセンサーによって送信された集計データの平均が必要です。 5か月ごとに再サンプリングされますか?

私はこのような要求を1Sで行うことはできないと考えていますので、私はいくつかのロールアップ/事前集約メカニズムが必要だと信じていますが、そこには多くのツールがあり、私の必要性に合ったものを決めてください。

答えて

4

私はWarp 10のリードですので、私の答えは敬意を表します。

150kセンサは10分ごとにデータを送信しますが、5秒間に平均250データポイント、40B未満です。このようなボリュームは、単純なWarp 10スタンドアロンに簡単に収まることができます。また、後で大規模なインフラストラクチャが必要な場合は、Hadoopに基づいた分散Warp 10に移行できます。

リクエストに関しては、データがすでにリサンプリングされている場合、50センサーの5年間の月間データをフェッチするのは3000データポイントだけです。ワープ10はこれを1秒未満で実行できます。自動ロールアップは単なる問題です毎月のようにWarpScriptコードをスケジューリングします。

最後に、Hadoopエコシステムとの統合の観点から、Warp 10は、Pig、Spark、Flink、StormにWarpScript言語を統合したものです。 Warp10InputFormatを使用すると、Warp 10プラットフォームからデータを取得できます。また、他のInputFormatを使用してデータをロードし、WarpScriptを使用してデータを操作することもできます。 OVHで

0

我々はWarp10/HBaseのに頼る@OvhMetricsのヘビーユーザーである、と私たちは私がWarp10に興味がないんだOpenTSDB/WarpScript/PromQL/...

とプロトコルの抽象化を提供し、それ私たちにとって大きな成功を収めています。スケーリングの課題と、WarpScriptがカバーできるユースケースの両方について。

ほとんどの場合、お客様のニーズはリアルタイムのWarpScript APIで容易に解決されるため、hadoop/flinkの統合を活用することさえありません。