SNMPを使用して（おそらく）5分間隔で、CPU使用率、ディスク使用率、温度などのさまざまなメトリックに関するデータをデバイスにポーリングするシステムを作成しています。最終的な目標は、システムのユーザーに時系列グラフの形で視覚化を提供することです。

私は過去にRRDToolの使用を検討しましたが、キャプチャされたデータを無期限に保存することは私のプロジェクトにとって重要であり、キャプチャされたデータへのより高いレベルでより柔軟なアクセスが必要であるため拒否しました。だから私の質問は本当に：

グラフ化のためにデータをクエリするときのパフォーマンスに関しては、リレーショナルデータベース（MySQLやPostgreSQLなど）または非リレーショナルデータベースやNoSQLデータベース（MongoDBやRedisなど）のほうが優れています。

関連した

リレーショナルデータベースが与えられた場合、data_instancesテーブルを使用します。このテーブルには、すべてのデバイスで測定されるすべてのメトリックについてキャプチャされたデータのすべてのインスタンスが格納され、次のフィールドが含まれます。

田畑： id fk_to_device fk_to_metric metric_value timestamp

特定のデバイスの特定のメトリックのグラフを描画する場合、他のデバイスを除外するこの特異なテーブルと、このデバイスに対して分析されている他のメトリックをクエリする必要があります。

SELECT metric_value, timestamp FROM data_instances
    WHERE fk_to_device=1 AND fk_to_metric=2

このテーブルの行数は次のようになります。

d * m_d * f * t

ここdで、はデバイスの数、m_dはすべてのデバイスについて記録されているメトリックの累積数、fはデータがポーリングされる頻度、およびシステムがデータを収集していtた合計時間です。

年間5分ごとに3台のデバイスの10のメトリックを記録するユーザーの場合、500万レコード弱になります。

インデックス

インデックスを付けずにこの継続的に拡張するテーブルfk_to_deviceをfk_to_metricスキャンしないと、時間がかかりすぎます。したがって、前述のフィールドにインデックスを付けることと、timestamp（ローカライズされた期間でグラフを作成するために）要件になります。

非リレーショナル（NoSQL）

MongoDBにはコレクションという概念があります。テーブルとは異なり、これらは設定なしでプログラムで作成できます。これらを使用して、デバイスごとにデータのストレージを分割したり、デバイスごとに記録されたメトリックを分割したりすることもできました。

私はNoSQLの経験がなく、インデックス作成などのクエリパフォーマンス向上機能が提供されているかどうかはわかりませんが、前の段落では、データがNoSQLに格納される構造で従来のリレーショナルクエリ作業のほとんどを実行することを提案しています。

未定

正しいインデックス付けを使用するリレーショナルソリューションは、1年以内にクロールに減少しますか？または、コレクションに基づくNoSQLアプローチの構造（これは、格納されたデータの私のメンタルモデルに一致します）は顕著な利点を提供しますか？

間違いなく関係。無制限の柔軟性と拡張性。

コンセプトとアプリケーションの両方に2つの修正があり、その後に標高が続きます。

補正

1. 「不要なデータを除外する」ことではありません。それがさだけ選択に必要なデータを。はい、もちろん、WHERE句で識別された列をサポートするインデックスがある場合、それは非常に高速で、クエリはテーブルのサイズに依存しません（160億行のテーブルから1,000行を取得するのは瞬時です） 。

2. テーブルには重大な障害が1つあります。説明を踏まえると、実際のP​​Kは（Device、Metric、DateTime）です。（TimeStampと呼ばないでください。それは別のことを意味しますが、それは小さな問題です。）行の一意性は、次のように識別されます。

      (Device, Metric, DateTime)
   

   • Id列には、何もしません、それは完全に、完全に冗長です。

     • あ Id列には、キー（リレーショナルデータベースで禁止されている重複行は、他の手段によって防止しなければならない）ことはありません。

     • Idコラムは明らかに速度を妨げる追加のインデックスを、必要とINSERT/DELETEし、使用するディスクスペースに追加されます。

     • あなたはそれを取り除くことができます。お願いします。

標高

1. 障害を取り除いたので、それを認識していない可能性がありますが、テーブルは第6正規形です。PKのインデックスが1つだけなので、非常に高速です。理解するために、第6正規形とは何かからこの回答を読んでください。先に向かって。

   • （私は3つではなく1つのインデックスのみを持っています。非SQLでは3つのインデックスが必要になる場合があります）。

   • 私はまったく同じテーブルを持っています（Idもちろん、「キー」なし）。追加の列がありますServer。複数の顧客をリモートでサポートします。

     (Server, Device, Metric, DateTime)

   テーブルは、まったく同じSQLコードを使用してデータをピボットする（つまりDevices、Metrics上下左右にピボットする）ために使用できます（はい、セルを切り替えます）。この表を使用して、サーバーのパフォーマンスに関する顧客向けに、無制限のさまざまなグラフやチャートを作成します。

   • 統計データモデルの監視。
     （インラインには大きすぎます。一部のブラウザーはインラインで読み込めません。リンクをクリックしてください。これも廃止されたデモバージョンです。明らかな理由により、商用製品DMを表示できません。）

   • これにより、1つのSELECTコマンドを使用して、顧客から生の監視統計ファイルを受け取った後、6つのキーストロークでこのようなグラフを作成できます。ミックスアンドマッチに注意してください。同じチャート上のOSとサーバー。さまざまなピボット。もちろん、統計マトリックスの数、したがってグラフの数に制限はありません。（お客様のご厚意によりご利用いただきます。）

   • リレーショナルデータベースのモデリングの標準に慣れていない読者は、IDEF1X表記法が役立つことがあります。

もう一つ

最後に、SQLはIEC / ISO / ANSI標準です。フリーウェアは実際には非SQLです。標準を提供しない場合、SQLという用語を使用することは不正です。それらは「エクストラ」を提供する場合がありますが、基本はありません。

上記の回答は非常に興味深いものでした。ここにいくつかの考慮事項を追加しようとしています。

1）データの老化

時系列管理では、通常、エージングポリシーを作成する必要があります。典型的なシナリオ（例：サーバーCPUの監視）では、次のものを保存する必要があります。

• 短時間（例：24時間）の1秒の生サンプル

• 中期間（例：1週間）の5分の詳細な集計サンプル

• 1時間の詳細（例：最大1年）

リレーショナルモデルを使用すると（数万のデータシリーズを持つ大規模な顧客向けに大規模な集中型データベースを実装している）確実にそれを適切に管理できますが、新しい種類のデータストアは興味深い機能を追加して次のように調査します。

• 自動データ消去（RedisのEXPIREコマンドを参照）

• 多次元集約（例：map-reduceジョブa-la-Splunk）

2）リアルタイム収集

さらに重要なのは、一部の非リレーショナルデータストアが本質的に分散されており、ホットスポットの作成（挿入中にインデックス付けを管理する）のためにRDBMSで問題になる可能性がある、はるかに効率的なリアルタイム（またはほぼリアルタイム）のデータ収集を可能にする単一のテーブル）。RDBMSスペースのこの問題は通常、バッチインポートプロシージャ（以前はこの方法で管理していました）に戻して解決されますが、SQL以外のテクノロジーは大規模なリアルタイムの収集と集約に成功しています（以前の返信で述べたSplunkなどを参照）。 。

テーブルのデータは1つのテーブルにあります。したがって、リレーショナルか非リレーショナルかは問題ではありません。基本的に、多くのシーケンシャルデータを読み取る必要があります。1年分のデータを保存するのに十分なRAMがある場合は、Redis / MongoDBなどを使用するのと同じです。

多くの場合、NoSQLデータベースは、ディスク上の同じ場所にデータを格納し、複数のディスクアクセスを回避するために圧縮形式で保存します。

NoSQLは、デバイスIDとメトリックIDにインデックスを作成するのと同じことを行いますが、独自の方法で行います。データベースを使用すると、これを実行しても、インデックスとデータが別の場所にあり、大量のディスクIOが存在する可能性があります。

Splunkのようなツールは、NoSQLバックエンドを使用して時系列データを格納し、map reduceを使用して集計を作成します（後で必要になる場合があります）。したがって、私の意見では、NoSQLを使用することはオプションです。しかし、100万行はデータベースをクロールします（まともなハードウェアと適切な構成では）。

ファイルを作成し、1_2.dataという名前を付けます。奇妙なアイデア？あなたが得るもの：

• すべてのデータポイントに対してfk_to_device値とfk_to_metric値を繰り返す必要がないため、スペースを最大50％節約できます。
• インデックスを必要としないため、さらに多くのスペースを節約できます。
• （timestamp、metric_value）のペアをデータに追加してファイルに保存し、タイムスタンプで無料で注文できるようにします。（ソースがデバイスの順不同データを送信しないと仮定）

=>バイナリ検索を使用してファイル内の適切な場所を見つけて読み取ることができるため、タイムスタンプによるクエリは驚くほど高速に実行されます。

もしあなたがそれをもっと好きなら、そのようにあなたのファイルを分割することについて考え始めます;

• 1_2_january2014.data
• 1_2_february2014.data
• 1_2_march2014.data

または、http： //kx.comのkdb +を使用します。これらはすべてこのためです。）列指向が役立つ場合があります。

クラウドベースの列指向のソリューションがポップアップしているので、http：//timeseries.guruをご覧ください。

GPLパッケージを表示している場合、RRDToolが役立ちます。時系列データを保存、抽出、グラフ化するための優れたツールです。ユースケースは時系列データのように見えます。

これは、ApiAxleで解決しなければならない問題です。Redisを使用してそれをどのように行ったかについて、ブログ投稿を書きました。それは長い間出回っていませんが、効果的であることが証明されています。

優れた別のプロジェクトにもRRDToolを使用しました。

この種の質問に対する答えは、主にデータベースがストレージを利用する方法を中心に展開する必要があると思います。一部のデータベースサーバーはRAMとディスクを使用し、一部はRAMのみを使用します（オプションで永続化のためにディスクを使用します）。最も一般的なSQLデータベースソリューションは、メモリ+ディスクストレージを使用し、行ベースのレイアウトでデータを書き込みます（挿入されたrawはすべて同じに書き込まれます）物理的な位置）。時系列ストアの場合、ほとんどの場合、ワークロードは次のようなものです。読み取りは列ベースですが、比較的短い間隔で大量の挿入が行われます（ほとんどの場合、特定の列からデータの範囲を読み取り、指標を表します）。

Columnar Databases（google it、MonetDB、InfoBright、parAccelなどが見つかります）が時系列で素晴らしい仕事をしていることがわかりました。

あなたの質問については、個人的には少し無効だと思います（フォールト用語NoSQL-IMOを使用するすべての議論と同様）：SQLを片手に話すことができるデータベースサーバーを使用できます。年とこの言語は、データクエリのために何度も何度も完璧にされています。ただし、RAM、CPUキャッシュ、およびディスクを列指向の方法で利用し、ソリューションを時系列に最も適合させます。

500万行は、今日の集中的なデータには当てはまりません。ほんの数か月でデータがTBまたはPBに入ると予想します。この時点では、RDBMSはタスクに対応していないため、NoSqlデータベースの線形スケーラビリティが必要です。データの格納に使用される列パーティションのパフォーマンスが達成され、列を増やし、行数を減らしてパフォーマンスを向上させます。HBASEやMapR_DBなどの上で行われるOpen TSDBの作業を活用します。

私は定期的に同様の要件に直面しており、最近このタイプのデータを収集して保存するためにZabbixを使用し始めました。Zabbixには独自のグラフ作成機能がありますが、Zabbixのデータベースからデータを抽出して好きなように処理するのは簡単です。Zabbixをまだチェックアウトしていない場合は、チェックする価値があります。

時系列データベースを調べてください。この目的のために作成されました。

時系列データベース（TSDB）は、時系列データ、つまり時間（日時または日時範囲）で索引付けされた数値の配列を処理するために最適化されたソフトウェアシステムです。

時系列データベースInfluxDBの一般的な例