8

問題に直面しています: プロセス プラントのデータベースです。50 ミリ秒のサンプリング レートで最大 50,000 個のセンサーがあります。すべての測定値は少なくとも 3 年間保存する必要があり、リアルタイム クエリをサポートする必要があります (つまり、ユーザーは 1 秒未満の遅延で履歴データを表示できます)。私は最近Time-series Databaseに関する記事を読みました。OpenTSDB、KairosDB、InfluxDB など、多くのオプションが用意されています。

どちらが目的に適しているか混乱していますか?これについて知っている人は私を助けてください!

更新 15.06.25

今日、OpenTSDB に基づいたテストを実行します。Virtual Box を使用して、3 つの CentOS x64 VM (1 つのマスター、2 つのスレーブ) のクラスターを作成しました。ホスト構成は 8 GB RAM、core i5 です。マスター VM 構成は 3 GB RAM で、スレーブ構成は 1.5 GB RAM です。以下のように、データを OpenTSDB に送信する python プログラムを作成します。

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(("192.168.10.55", 4242))

start_time = time.time()
start_epoch = 1434192418;

for x in range(0, 1000000):
    curr_epoch = start_epoch + x

    tag1 = "put TAG_1 %d 12.9 stt=good\n" % (curr_epoch)
    tag2 = "put TAG_2 %d 12.9 stt=good\n" % (curr_epoch)
    tag3 = "put TAG_3 %d 12.9 stt=good\n" % (curr_epoch)
    tag4 = "put TAG_4 %d 12.9 stt=good\n" % (curr_epoch)
    tag5 = "put TAG_5 %d 12.9 stt=good\n" % (curr_epoch)
    tag6 = "put TAG_6 %d 12.9 stt=good\n" % (curr_epoch)
    tag7 = "put TAG_7 %d 12.9 stt=good\n" % (curr_epoch)
    tag8 = "put TAG_8 %d 12.9 stt=good\n" % (curr_epoch)
    tag9 = "put TAG_9 %d 12.9 stt=good\n" % (curr_epoch)
    tag10 = "put TAG_10 %d 12.9 stt=good\n" % (curr_epoch)
    str = tag1 + tag2 + tag3 + tag4 + tag5 + tag6 + tag7 + tag8 + tag9 + tag10

    s.send(str)

print("--- %s seconds ---" % (time.time() - start_time))

ホストで python を実行すると、作業は約 220 秒後に完了します。だから、私は平均を得ました。毎秒最大 45000 レコードの速度。

更新 15.06.29

今回は 1 つの VM (5 GB RAM、3 コア、CentOS x64、疑似分散 Hadoop) のみを使用しました。Windows 7 ホストで 2 つの Python プロセスを実行して、データの 2 つの半分を OpenTSDB に送信します。平均 データの書き込み速度は、1 秒あたり最大 100,000 レコードでした。

4

4 に答える 4

2

1 秒あたり 100 万回の書き込みを処理するには、本格的なエンジニアリングを導入する必要があります。

すべてのデータベースがその量のデータをコンパクトな形式で保存できるわけではありません。

たとえば、ATSD は、観測された分散に応じて、サンプルごとに 5 ~ 10 バイト (float データ型) を使用します。

この種の負荷を処理できる、HBase 上に構築された分散型 (クラスター化) データベースのタイプがあります。

たとえば、openTSDBATSDを見てみることができます。

更新 1。

特定のユースケースに対して次のテストを実行しました。

30.000 のアナログ センサーが float 型のデータを書き込み、540.000.000 レコードになります

20.000 個のデジタル センサーが短いタイプのデータ (0 と 1) を書き込み、552.000.000 レコードになります。

データは 3.68 ギガバイトを占めました。圧縮は無損失でした。

結果として、レコードあたり平均 3.37 バイトになります。

これはストレージ効率テストでした。

完全な開示、私は ATSD を開発する会社で働いています。

于 2015-06-22T16:36:23.540 に答える
1

非常に興味深い使用例。

KairosDB と Cassandra を強く評価して使用しただけなので、他の人について話すことはできませんが、私自身の経験について話すことができます。

KairosDB + Cassandra はスループットに耐えますが、1 秒あたり 100 万回の書き込みを行うには、複数のフロントエンド (少なくとも 10 ノードをお勧めしますが、テストする必要があります) とバックエンド サーバー (必要に応じて同じ場所に配置できます) を備えたクラスターが必要になります。必要)。

とにかく、センサーごとに 1 秒あたり 200 サンプルのスループットで...履歴データの取得は、長いクエリの場合に問題になる可能性があります (履歴データの 1 秒は興味深いですが、クエリ期間のサンプルの量を決定する必要があります)。

私が知る限り、ストレージ効率は ATSD ほど良くはありません (おそらく 2 倍のサイズで、すでに優れています)。

私が個人的に KairosDB と Cassandra を気に入っているところと、それを採用した理由: シンプルで本当に分散されていること、KairosDB はデータをいじらないこと、デザインがエレガントで複雑なシステムを必要としないこと、Cassandra がデータを管理し、kairosDB が TSDB を提供することサービス、およびパフォーマンスと効率はまったく悪くありません...さらに、Cassandraは、対応するものよりもクラスターとして管理するのがはるかに簡単です.

于 2015-07-29T15:09:29.940 に答える