ユースケース：InfluxDB対Prometheus
Prometheusウェブページ に従うと、PrometheusとInfluxDBの主な違いの1つはユースケースです。一方、Prometheusは時系列のみを格納し、InfluxDBは個々のイベントの格納に適しています。 InfluxDBのストレージエンジンでいくつかの主要な作業が行われたので、これがまだ真実かどうか疑問に思います。
時系列データベースをセットアップし、プッシュ/プッシュモデル（およびおそらくパフォーマンスの違い）を除いて、両方のプロジェクトを分ける大きなものは見られません。誰かがユースケースの違いを説明できますか？
InfluxDBのCEOおよび開発者はこちら。 InfluxDBの次のバージョン（0.9.5）には新しいストレージエンジンが搭載される予定です。このエンジンを使用すると、単一のイベントデータまたは定期的にサンプリングされたシリーズのいずれかを効率的に保存できます。すなわち、不規則で定期的な時系列。
InfluxDBは、それぞれに異なる圧縮スキームを使用して、int64、float64、bool、およびstringデータ型をサポートします。 Prometheusはfloat64のみをサポートしています。
圧縮については、0.9.5バージョンの圧縮はPrometheusと競合します。場合によっては、表示内容に基づいてタイムスタンプの圧縮を変更するため、より良い結果が得られます。最良のシナリオは、正確な間隔でサンプリングされた定期的なシリーズです。デフォルトでは、8バイトの開始時間、デルタ（ジグザグエンコード）、およびカウント（ジグザグエンコード）として1kポイントのタイムスタンプを圧縮できます。
データの形状にもよりますが、圧縮後の平均は1ポイントあたり2.5バイト未満です。
タイムスタンプ、データ型、およびデータの形状に基づいたYMMV。たとえば、大きな可変デルタを持つナノ秒スケールのタイムスタンプを持つランダムフロートは最悪です。
タイムスタンプの可変精度は、InfluxDBのもう1つの機能です。秒、ミリ秒、マイクロ秒、またはナノ秒のスケール時間を表すことができます。プロメテウスはミリ秒に固定されています。
もう1つの違いは、InfluxDBへの書き込みは、成功応答がクライアントに送信された後も永続的であることです。 Prometheusはメモリへの書き込みをバッファリングし、デフォルトでは5分ごとにフラッシュします。これにより、潜在的なデータ損失のウィンドウが開きます。
InfluxDBの0.9.5がリリースされたら、Prometheusユーザーが（Prometheusと組み合わせて）長期的なメトリックストレージとして使用するのに適した選択肢になることを願っています。サポートはすでにPrometheusで行われていると確信していますが、0.9.5リリースがドロップするまでは少し不安定になるかもしれません。明らかに、私たちは協力して多くのテストを行う必要がありますが、それが私が望んでいることです。
単一サーバーメトリックの取り込みでは、データモデルがより制約されているため、インデックスを書き出す前にディスクに書き込みを追加しないため、Prometheusのパフォーマンスが向上することを期待します（ここではテストを行っておらず、数値もありません） 。
2つのクエリ言語は大きく異なります。私たちがまだサポートしていないことや、その逆をサポートしているかどうかはわかりませんので、両方のドキュメントを調べて、必要なことができるかどうかを確認する必要があります。長期的な目標は、InfluxDBのクエリ機能をGraphite、RRD、Prometheus、およびその他の時系列ソリューションのスーパーセットにすることです。スーパーセットとは、後でさらに分析関数に加えてそれらをカバーするためです。そこに着くまでに明らかに時間がかかります。
最後に、InfluxDBの長期的な目標は、クラスタリングを通じて高可用性と水平スケーラビリティをサポートすることです。現在のクラスタリング実装はまだ完全な機能ではなく、アルファ版のみです。しかし、私たちはそれに取り組んでおり、プロジェクトの中心的な設計目標です。クラスタリングの設計では、データは最終的に一貫性があります。
私の知る限り、Prometheusのアプローチは、HAに二重書き込みを使用し（最終的な一貫性の保証がない）、水平スケーラビリティにフェデレーションを使用することです。フェデレーションサーバー間でクエリを実行する方法がわかりません。
InfluxDBクラスター内では、ネットワークを介してすべてのデータをコピーすることなく、サーバーの境界を越えてクエリを実行できます。これは、各クエリが、オンザフライで実行される一種のMapReduceジョブに分解されるためです。
おそらくもっとありますが、それは現時点で私が考えることができるものです。
他の回答では、2社からのマーケティングメッセージを受け取っています。それを無視して、時系列データの悲しい現実の世界に戻りましょう。
いくつかの歴史
InfluxDBとプロメテウスは、過去の古いツール（RRDtool、グラファイト）を置き換えるために作成されました。
InfluxDBは時系列データベースです。 Prometheusは、そのために作成されたストレージエンジンを備えた、一種のメトリック収集および警告ツールです。 （実際には、ストレージエンジンを他の何かに再利用できるか（またはするべきか）わかりません）
制限事項
悲しいことに、データベースの作成は非常に複雑な作業です。これらの両方のツールが何かを出荷する唯一の方法は、高可用性とクラスタリングに関連するすべてのハード機能を削除することです。
率直に言って、それは単一のノードのみを実行する単一のアプリケーションです。
Prometheusには、クラスタリングとレプリケーションをサポートするという目標はありません。フェイルオーバーをサポートする公式の方法は、「2つのノードを実行し、両方のノードにデータを送信する」です。痛い。 （これは真剣に存在する唯一の方法であることに注意してください。公式文書には何度も書かれています）。
InfluxDBは、3月に公式に放棄されるまで、クラスタリングについて何年も語っています。 InfluxDBのクラスタリングはもうテーブルにありません。それを忘れて。それが完了すると（それが今までと同じように）、Enterprise Editionでのみ利用可能になります。
https://influxdata.com/blog/update-on-influxdb-clustering-high-availability-and-monetization/
今後数年以内に、レプリケーション、フェールオーバー、データの安全性、スケーラビリティ、バックアップなど、データベースに関連するすべての困難な問題を処理する適切に設計された時系列データベースができればと思います。
現時点では、特効薬はありません。
何をすべきか
予想されるデータ量を評価します。
100メトリック* 100ソース* 1秒=> 10000データポイント/秒=> 864メガデータポイント/日。
時系列データベースの良いところは、コンパクトな形式を使用し、圧縮率が高く、データポイントを集約し、古いデータを消去することです。 （さらに、時系列データに関連する機能が付属しています。）
データポイントが4バイトとして扱われると仮定すると、それは1日あたりわずか数ギガバイトです。幸いなことに、10個のコアと10個のTBドライブを備えたシステムがすぐに利用できます。これはおそらく単一のノードで実行できます。
別の方法は、従来のNoSQLデータベース（Cassandra、ElasticSearch、またはRiak）を使用してから、アプリケーションの欠落部分を設計することです。これらのデータベースは、その種類のストレージ用に最適化されていない可能性があります（または現代のデータベースは非常に複雑で最適化されており、ベンチマークを行わない限り確実に知ることができません）。
アプリケーションに必要な容量を評価する必要があります。これらのさまざまなデータベースで概念実証を作成し、物事を測定します。
InfluxDBの制限内に収まるかどうかを確認してください。もしそうなら、おそらく最善の策です。そうでない場合は、他の何かの上に独自のソリューションを作成する必要があります。
InfluxDBは、1000台のサーバーからの実稼働負荷（メトリック）を保持できません。データの取り込みにいくつかの実際の問題があり、ストール/ハングアップして使用できなくなります。しばらく使用しようとしましたが、データ量が何らかのクリティカルレベルに達すると、使用できなくなりました。メモリやCPUのアップグレードは助けになりませんでした。したがって、私たちの経験は間違いなくそれを避けています。成熟した製品ではなく、深刻なアーキテクチャ設計の問題があります。また、Influxによる突然の商用への移行についても話していません。
次に、Prometheusを調査しましたが、クエリを書き換える必要がありましたが、Influxにフィードしようとしたものと比較して、問題なく4倍のメトリックを取り込みます。そして、その負荷はすべて単一のPrometheusサーバーで処理され、高速で信頼性が高く、信頼性があります。これは、かなり重い負荷の下で巨大な国際的なインターネットショップを運営している私たちの経験です。
IIRCの現在のPrometheus実装は、単一のサーバーに適合するすべてのデータを中心に設計されています。膨大な量のデータがある場合、すべてがPrometheusに収まらない場合があります。