CrateDBにパフォーマンスデータを格納するためのベストプラクティスは何ですか？

Question

私のアプリケーションはCrateDBにパフォーマンスの時系列データを保存しています。セットアップの権利を得るためには、1日に約72Mレコードになるため、正しくスケーリングする必要があるため、いくつか質問があります。私の目標は、Grafanaと結果のデータを視覚化することであり、現在、私は心の中で次のような構造を持っている：

CREATE TABLE metrics (
    ts TIMESTAMP, 
    hostname STRING, 
    servicename STRING, 
    perfdata OBJECT(DYNAMIC) 
) 

// for example 
{ 
    "hostname": "localhost", 
    "servicename": "ping", 
    "timestamp": 1483699527, 
    "perfdata": { 
     "rta": { 
      "current": 0.5, 
      "unit": "ms", 
      "warn": 100, 
      "critical": 200 
     }, 
     "pl": { 
      "current": 0, 
      "unit": "%", 
      "warn": 10, 
      "crit": 20 
     } 
    } 
} 

重要なビットは、ホストベース/サービス名、メトリックの名前と値、およびタイムスタンプです。代替スキーマにもなります：

CREATE TABLE metrics (
    ts TIMESTAMP, 
    hostname STRING, 
    servicename STRING, 
    metric OBJECT(DYNAMIC) AS (
     unit STRING, 
     name STRING, 
     value DOUBLE, 
    )  
) 

データを保存するにはどちらの方法が適していますか？パーティショニングも必要ですか？私の集計は、通常、最後の24時間を表示し、まれに最後の月を示します...

ありがとう！

Answer 1

第2テーブルスキーマは、シンプルで、事前に組み立てられたものではなく生データをキャプチャして、実際に必要なものを集計できるので、一般的にはの第2テーブルスキーマをお勧めします。

しかし、実際の要件に大きく依存するため、この質問は非常に難しいです。だから、基本的に組み合わされたスキーマは、トリッキーな（オブジェクトのみを交換しない更新することができます）更新を行いますので、データを一緒に送信することが必要です（そしておそらく同じペースで収集します？）。

さらに、partitioningを設定すると便利です。 これにより、クエリを高速化し、change the number of shards for future partitionsにすることができます（さらにスケーラビリティを向上させることができます）。 一般的なプラクティスは、月または週ごと、場合によっては1日ごとに分割することです。 しかし 破片は、システム・リソースを必要と爆発からの破片の数を防ぐために、そこに世話をしなければなりません。 CrateDBはGrafanaと非常によく動作します

、datasource plugin :)

Answer 2

のおかげで今これを見て、私はperdata（のnagios）とcratedbで遊んでてきました。 私たちは（mongodb timeseriesのデモに基づいて）1時間ごとに格納していましたが、perfdata [ts] = {perfオブジェクト} を受け取りました（実際にperfdata ['minute'] ['second'] = {}）

24時間スキーマは、ホスト/サービスに主キーを定義することによって、そうPERFDATA [「時間」] [「分」]

だろう/あなたが を行う「重複キーの更新に..」

ので、ホスト/サービス/時間単位での問合せは

:-)ただ一つのクエリです