質問

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

過去に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 の総量です。 時間 がデータを収集している。

3つのデバイスで5分ごとに10個のメトリクスを記録するユーザが1年間いた場合、以下のようになります。 500万 を記録します。

インデックス

にインデックスがない場合 fk_to_device と fk_to_metric この継続的に拡大するテーブルをスキャンするのは時間がかかりすぎる。そこで前述のフィールドにインデックスを付け、さらに timestamp (期間を局所化したグラフを作成するための)要件である。

非リレーショナル(NoSQL)

MongoDBには コレクション テーブルとは異なり、設定なしにプログラムで作成することができます。これを使えば、各デバイスのデータを分割して保存したり、各デバイスに記録された各メトリックスを保存したりすることができます。

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

未定

正しいインデックスを作成したリレーショナルソリューションは、1年以内にクロールのように減ってしまうのでしょうか？それとも、NoSQLアプローチのコレクションベースの構造（保存データの私のメンタルモデルと一致する）が、顕著な利点をもたらすのでしょうか？

どのように解決するのか？

間違いなくリレーショナル。 無限の柔軟性と拡張性。

コンセプトとアプリケーションの両面から2つの修正を行い、その後に昇華させる。

訂正内容

1. 不要なデータをフィルタリングしているのではありません。 のみを選択 必要なデータ もちろん、WHERE句で特定されたカラムをサポートするIndexがあれば、非常に高速で、クエリーはテーブルのサイズに依存しません（160億行のテーブルから1000行を取得するのは瞬時です）。

2. あなたのテーブルには、ひとつ重大な障害があります。 あなたの説明からすると、実際のPKは（デバイス、メトリック、日付時間）です。 (TimeStampと呼ばないでください。それは他のものを意味しますが、それは些細な問題です)。 の一意性です。 行 が識別されます。

      (Device, Metric, DateTime)
   
   

   • は Id カラムは何もしません。完全に冗長です。

     • An Id カラムは決してキーではありません（リレーショナル・データベースで禁止されている重複行は、他の手段で防ぐ必要があります）。

     • は Id カラムは追加のIndexを必要とし、これは明らかに INSERT/DELETE また、使用するディスク容量も増加します。

     • 捨てていいんだよ。 お願いします。

標高

1. さて、障害を取り除いたので、あなたは気づかなかったかもしれませんが、あなたのテーブルは第六正規形です。 非常に高速で、PKにIndexが1つあるだけの状態です。理解のために、以下を読んでください。 この回答 から 第六正規形とは何ですか？ の見出し以降をご覧ください。

   • (私は3つではなく1つのインデックスしか持っていません。非SQLでは3つのインデックスが必要な場合があります)。

   • 全く同じテーブルを( Id もちろん、"key"です）。私は、追加のカラム Server . 複数の顧客をリモートでサポートしています。

     (Server, Device, Metric, DateTime)

   テーブルは、データをPivot（ピボット）するために使用することができます（ie. Devices を挟んで、上部に Metrics というのは、全く同じSQLコード（そう、セルを入れ替えるのです）を使って、横から見たり、回転させたりしているのです。） 私はこのテーブルを使って、顧客のサーバーのパフォーマンスに関するグラフやチャートを無制限に作成することができます。

   • モニタ統計データモデル .
     
     (大きすぎてインラインでは読み込めません。一部のブラウザでは、リンクをクリックしてください。 また、これは旧式のデモ版です。明らかな理由により、商用製品のDMをお見せすることはできません)。

   • を作り出すことができるんです。 こんなチャート を使用して、お客様から生の監視統計ファイルを受け取った後、6つのキーストロークを使用します。 単一のSELECTコマンド . OSとサーバーを同じチャートに表示したり、様々なピボットを使用したりと、混在していることに注目です。 もちろん、統計マトリックスの数、つまりチャートの数に制限はありません。(お客様のご好意により使用させていただいております。）

   • リレーショナル・データベース・モデリング標準」を知らない読者には IDEF1X記法 を参考にしました。

One More Thing

最後になりますが、SQLはIEC/ISO/ANSIの規格です。 フリーウェアは実は非SQLで、標準を提供しないのにSQLという言葉を使うのは詐欺です。 標準を提供しないのにSQLという言葉を使うのは詐欺です。