リレーショナルまたは非時系列データの保存？
SNMPを使用して（おそらく）5分間隔で、CPU使用率、ディスク使用率、温度などのさまざまなメトリックに関するデータのデバイスをポーリングするシステムを作成しています。最終的な目標は、システムのユーザーに時系列グラフの形で視覚化を提供することです。
過去にRRDToolの使用を検討しましたが、キャプチャしたデータを無期限に保存することがプロジェクトにとって重要であり、キャプチャしたデータへのより高いレベルでより柔軟なアクセスが必要であるため拒否しました。だから私の質問は本当にです：
より良いのは、グラフ化のためにデータをクエリする際のパフォーマンスに関して、リレーショナルデータベース（MySQLやPostgreSQLなど）または非リレーショナルデータベースまたはNoSQLデータベース（MongoDBやRedisなど）です。
リレーショナル
リレーショナルデータベースの場合、data_instancesテーブルを使用します。このテーブルには、すべてのデバイスで測定されるすべてのメトリックに対してキャプチャされたデータのすべてのインスタンスが格納され、次のフィールドがあります。
フィールド：idfk_to_devicefk_to_metricmetric_valuetimestamp
特定のデバイスで特定のメトリックのグラフを描画する場合、この特異なテーブルフィルター処理で他のデバイス、およびこのデバイスについて分析されている他のメトリックを照会する必要があります。
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は総量です時間システムはデータを収集しています。
1年間5分ごとに3つのデバイスについて10のメトリックを記録するユーザーの場合、5 millionのレコードがすぐ下になります。
インデックス
fk_to_deviceおよびfk_to_metricのインデックスがない場合、この連続的に拡張するテーブルのスキャンには時間がかかりすぎます。したがって、前述のフィールドにインデックスを付け、timestamp（ローカライズされた期間でグラフを作成するため）も必要です。
非リレーショナル（NoSQL）
MongoDBにはcollectionという概念があります。テーブルとは異なり、これらはセットアップなしでプログラムで作成できます。これらを使用して、各デバイスのデータストレージ、または各デバイスに記録された各メトリックをパーティション分割できます。
私はNoSQLの経験がなく、インデックス作成などのクエリパフォーマンス強化機能を提供するかどうかはわかりませんが、前の段落では、NoSQLでデータが格納される構造で従来のリレーショナルクエリ作業のほとんどを行うことを提案しています。
未定
正しいインデックス付けを備えたリレーショナルソリューションは、1年以内にクロールを減らすでしょうか？または、NoSQLアプローチのコレクションベースの構造（保存されたデータの私のメンタルモデルに一致する）は、顕著な利点を提供しますか？
間違いなくリレーショナル。無制限の柔軟性と拡張性。
コンセプトとアプリケーションの両方での2つの修正と、その後の昇格。
補正
「不要なデータを除外する」ことではありません。selecting only必要なデータです。はい、もちろん、WHERE句で識別される列をサポートするインデックスがある場合、それは非常に高速であり、クエリはテーブルのサイズに依存しません（160億行のテーブルから1,000行を取得するのは瞬時です） 。
テーブルには1つの重大な障害があります。説明を考えると、実際のPKは（デバイス、メトリック、日時）です。 （TimeStampとは呼ばないでください。それは別のものを意味しますが、それは小さな問題です。）rowの一意性は次のように識別されます。
(Device, Metric, DateTime)Id列は何も行いません。完全に冗長です。Id列は決してキーではありません（リレーショナルデータベースで禁止されている重複行は、他の手段で防止する必要があります）。Id列には追加のインデックスが必要です。これは明らかにINSERT/DELETEの速度を妨げ、使用されるディスク容量を追加します。あなたはそれを取り除くことができます。お願いします。
標高
これで障害を削除したので、認識できなかったかもしれませんが、テーブルは第6正規形になっています。 PKにインデックスが1つしかない非常に高速。理解するには、 this answer から第6正規形とは？次へ。
（私は3つではなく1つのインデックスしか持っていません。非SQLでは3つのインデックスが必要な場合があります）。
私はまったく同じテーブルを持っています（もちろん
Id"key"なし）。追加の列Serverがあります。複数の顧客をリモートでサポートしています。(Server, Device, Metric, DateTime)
このテーブルを使用して、まったく同じSQLコード（はい、セルを切り替えます）を使用してデータをピボットできます（つまり、
Devicesを上に、Metricsを下に、またはピボット）。この表を使用して、お客様がサーバーのパフォーマンスを改善できるように、無制限のさまざまなグラフとチャートを作成します。統計データモデルの監視 。
（インラインには大きすぎます。一部のブラウザはインラインをロードできません。リンクをクリックしてください。これは廃止されたデモ版です。明白な理由により、商用製品DMを表示できません。）//を使用して、顧客から生のモニタリング統計ファイルを受信した後、 Charts Like This 、6つのキーストロークを生成することができます単一のSELECTコマンド。ミックスアンドマッチに注意してください。同じチャート上のOSとサーバー。さまざまなピボット。もちろん、統計マトリックスの数、つまりチャートの数に制限はありません。 （顧客の親切な許可で使用されます。）
リレーショナルデータベースのモデリングの標準に精通していない読者は、 IDEF1X Notation が役立つ場合があります。
One More Thing
最後になりましたが、SQLはIEC/ISO/ANSI標準です。フリーウェアは実際には非SQLです。標準を提供していない場合、SQLという用語を使用することは不正です。彼らは「エクストラ」を提供するかもしれませんが、基本はありません。
上記の答えは非常に興味深いことがわかりました。ここでさらにいくつかの考慮事項を追加しようとしています。
1）データのエージング
時系列管理では通常、エージングポリシーを作成する必要があります。典型的なシナリオ（サーバーCPUの監視など）は、以下を保存する必要があります：
1-sec短時間の生サンプル（24時間など）
5-min中期間（1週間など）の詳細な集計サンプル
1時間その詳細（例：最大1年）
リレーショナルモデルを使用すると、数万のデータシリーズを持つ大規模な顧客向けに大規模な集中型データベースを確実に管理できるようになりますが、新しい種類のデータストアでは、次のような興味深い機能が追加されます。
自動データ消去（RedisのEXPIREコマンドを参照）
多次元集計（例：map-reduce jobs a-la-Splunk）
2）リアルタイム収集
さらに重要なことに、一部の非リレーショナルデータストアは本質的に分散しており、ホットスポットの作成（挿入中のインデックス作成の管理）によりRDBMSで問題となる可能性のある、はるかに効率的なリアルタイム（またはほぼリアルタイム）のデータ収集を可能にします単一のテーブル）。 RDBMSスペースのこの問題は通常、バッチインポート手順に戻すことで解決されます（過去にこの方法で管理していました）が、no-sqlテクノロジーは大規模なリアルタイムの収集と集約に成功しました（たとえば、前の返信で言及したSplunkを参照） 。
テーブルには単一のテーブルにデータがあります。したがって、リレーショナルと非リレーショナルは問題ではありません。基本的に、大量のシーケンシャルデータを読み取る必要があります。これで、何年分のデータを保存するのに十分なRAMがある場合、Redis/MongoDBなどを使用するようなものはありません。
ほとんどの場合、NoSQLデータベースは、ディスク上の同じ場所に圧縮形式でデータを保存し、複数のディスクアクセスを回避します。
NoSQLは、デバイスIDとメトリックIDにインデックスを作成するのと同じことを行いますが、独自の方法で行います。データベースを使用すると、これを行っても、インデックスとデータが異なる場所にある可能性があり、ディスクIOが大量に発生します。
Splunkなどのツールは、NoSQLバックエンドを使用して時系列データを保存し、map reduceを使用して集計を作成します（後で必要になる場合があります）。したがって、NoSQLを使用することは、同様のユースケースで既に使用されているため、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.gur
GPLパッケージを見る場合、 RRDTool を見るのが良いでしょう。時系列データを保存、抽出、グラフ化するための優れたツールです。ユースケースは時系列データとまったく同じように見えます。
これは、ApiAxleで解決しなければならなかった問題です。 ブログ投稿を書き上げました Redisを使用した方法について。非常に長い間存在していませんでしたが、効果的であることが証明されています。
私は RRDTool を別のプロジェクトにも使用しました。
この種の質問に対する答えは、主にデータベースがストレージを利用する方法に関するものであると思います。一部のデータベースサーバーはRAMとディスクを使用し、一部はRAMのみを使用します（オプションで永続性のためにディスク）など。ほとんどの一般的なSQLデータベースソリューションはメモリ+ディスクストレージを使用し、行ベースのレイアウト（挿入されたすべてのrawは、物理的に同じ場所に書き込まれます）。時系列ストアの場合、ほとんどの場合、ワークロードは次のようになります。大量の挿入の比較的低い間隔、読み取りは列ベースです（ほとんどの場合、メトリックを表す特定の列からデータの範囲を読み取ります）
Columnar Databases（google it、MonetDB、InfoBright、parAccelなど）が時系列で素晴らしい仕事をしていることがわかりました。
個人的に私はやや無効だと思うあなたの質問については（障害用語NoSQL-IMOを使用するすべての議論のように）：あなたは片方でSQLを話すことができるデータベースサーバーを使用でき、誰もが多くの人にとってSQLを知っているのであなたの人生を非常に簡単にすることができます長年にわたり、この言語はデータクエリのために何度も完成されてきました。ただし、RAM、CPUキャッシュ、およびディスクをカラムナー指向の方法で活用し、時系列に最適なソリューションを作成します
5数百万の行は、今日の集中的なデータにとっては意味がありません。数か月以内にデータがTBまたはPBにあると予想します。この時点で、RDBMSはタスクに合わせて拡張できず、NoSqlデータベースの線形スケーラビリティが必要です。データを格納するために使用されるカラムナーパーティションのパフォーマンスが達成され、パフォーマンスを向上させるために、より多くの列とより少ない種類の概念が追加されます。 HBASEやMapR_DBなどの上で行われたOpen TSDBの作業を活用します。
私は定期的に同様の要件に直面していますが、最近このタイプのデータを収集して保存するためにZabbixを使用し始めました。 Zabbixには独自のグラフ作成機能がありますが、Zabbixのデータベースからデータを抽出し、好きなように処理するのは簡単です。まだZabbixをチェックアウトしていない場合は、時間をかけてチェックする価値があるかもしれません。