2009-04-07 11 views
0

異なる時間間隔でさまざまなソースから入ってくる時系列データを保存して提供するために、何かを構築したいと考えています。これには、生データと計算データの両方が含まれます。たとえば、30秒ごとの温度の読み取り値と5分ごとに別々に計算する気温予測値を記録するとします。高周波データを提供するための設計アイデア

データをすばやく検索できるようにする必要があります。リレーショナルデータベースが大きくなりすぎても、うまく機能しないことがわかりました。だから私はある種のメモリ内のものを作ることを考えていましたが、ある時点でクラッシュすると思いますので、データをディスクに保存する必要があります。だから私は、一般的に要求されるデータのための何らかのキャッシュを使って、ディスク全体をディスクベースにするだけでは不思議に思っていました。

しかし、私はこれについてどうやって行くのか分かりません。私は、データソースが更新データセットをサーバーに定期的に送り、何らかの文字列キー/記号を使用してデータが何であるかを特定することを想像しています。サーバーはデータを取得し、次に何を取得するのですか?何らかのバイナリファイルに書きますか?シンボルごとに1つのファイルに書き込むことはできますか? (100kシンボル以上と仮定)

私が望むものは、GoogleのBigTableに似ていますが、はるかに小規模です。基本的には、分散型ハッシュテーブルであり、非常に高速な検索と時系列で範囲クエリを取り出すことができるように、関連するデータの時系列に文字列キーをマッピングします。多次元データのための余分なポイントが含まれています。

ああ、これは(理想的には)C#/ windowsプロジェクトで、である必要はありません。高性能です。

+0

データベースのパーティション化? – CookieOfFortune

答えて

0

データベースを使用してインデックスを作成し、リレーショナル・パートを取り出すと、説明したものが得られます。しかし、私はそれがどれほど有用なのかよく分かりません。なぜデータベースがあなたにとってうまくいかないのか、私たちにより良いアイデアを教えてください。あなたは何をしようとしましたか?

+0

SQL Server 2005を使用していましたが、遅かったです。私はキーが階層的であった(timestamp、key1、key2、key3、data1、data2、data3)という形式のデータを持っていました。だから、私は "タイムライン範囲[a、b]のkey1 = x、key2 = y、key3 = zのところでdata1を与えると言うでしょう。 –

+0

私はindex3をkey3に持っていましたが、これによりインデックスディスクスペースが非常に大きくなり、挿入や削除が遅くなりました(覚えていない)。私はSQL Serverを再訪することができたと思いますが、データストアとしてではなく、データサーバーとしてデータベースを使用するのは間違っていたようです... –

+0

毎回データベースにどのようにアクセスしましたか?データベースへの新しい接続の作成が遅くなる可能性があります。そのため、ほとんどのシステムで接続プールが使用されているか、接続を維持できます。 – CookieOfFortune

2

「ファイルシステム」のアプローチ(私が知っている)は、リレーショナルデータベースより高速になるとは言えません。おそらくもっと悪くなるでしょう。

リレーショナルデータベースの問題は、本質的に遅いのではなく、データの保存方法を気にせずにデータを配置できることです。良いインデックスは、数百万のレコードであっても、1秒未満の結果をもたらすはずです。それは、アクセスの問題よりも設計上の問題です。それをうまく設計すれば、アクセスが可能になります。

編集:また、「リレーショナルデータベース」によってMicrosoft Accessを意味する場合は、正しいと思います。それは多くの記録では遅いです。私はその道を行くつもりはない。マネーが問題であればMySql、マネーならばOracle/Sql Serverを調べてください。

+0

リレーショナルデータベースはファイルシステムの上にあります。リレーショナルデータベースは小規模なSCADAシステムでも機能しますが、規模がまったく変わっていません。ディスクスペースをあまりにも多く使いすぎると、索引がどれほどうまくいくかにかかわらず、あまりにも早く過ぎ去る傾向があります。 – grieve

+0

@grieve申し訳ありませんが、リレーショナルデータベースが何らかの形で記憶媒体から切り離されたということを意味するわけではありません。私は、リレーショナルデータベースに組み込まれたメカニズムが、自分自身でファイルシステムを介して同様のシステムを組み立てようとするよりも(私の知る限り)優れていることを意味していました。スケーリングの問題を認識していませんでした。 –

+0

@grieveスケーリングが問題になる場合は、リレーショナルデータベース以外に何をお勧めしますか? –

0

私はあなたがなぜこれをデータベース化しているのか分かりません。私は、数千万の行を持つ表についてリアルタイムの統計を行ってきました。さらに、読書を定期的にバッチアップして、数十万行をコンパイルされたデータの何百行にすることもできます。

メモリ内の永続性とキーと値のペアのアクセスについては、memcachedbを参照してください。これはmemcachedに基づいており、優れたパフォーマンスを提供します。

また、もっと考えてみると、メモリ内のハッシュテーブルとして簡単に実行し、永続化のためにファイルシステムに定期的にシリアル化することができます。

+0

あなたは何に対してハッシュしますか? – grieve

+0

ああ、そうです。そのハッシュスペースは膨大なものになります。 –

+0

質問者は、キーと値のペアになると述べました。それ(と彼の詳細の不足)を考えると、私はちょうど適している何かを提案した。一度細部が現れたら、良いアイデアかもしれません。 – bbrown

0

私は他の人にはデータベースがあなたのベスト・ベットになることに同意します。

パフォーマンス上の問題を引き起こすような膨大な量のデータを実際に生成している場合は、「リアルタイム」ソースと「アーカイブ」の2つのテーブルを作成することができます。

システムはリアルタイムテーブルに新しいデータを挿入し、バッチジョブはそこから定期的にデータをアーカイブテーブルに移動します。パフォーマンスが問題になる場合は、より小さなリアルタイム表のみを照会します。実際にすべてのデータを照会する必要がある場合は、実表とアーカイブ表を結合するビューを照会します。

1

システムのデータ収集部分を利用して、SCADA(システム制御およびデータ収集)タイプのアプリケーションのように聞こえます。あなたは既製のソリューションを見ましたか? Wonderware/IndustrialSQLまたは一部の競合製品ですか?

私の現在の雇用主(The MetService、New Zealand)は、自動気象ステーション(気温、降水量、風など)から30秒、1分または1時間ごとに読み取り値を記録し、Oracle DBに予測していると言います。最小限の索引付け。インデックスは4つのDMLアクションのうち3つを遅らせ、スピードアップします。選択もちろん、3つのアクション、特に挿入が必要です。高速IOシステム。 REDOログのIOが非常に高速です。私たちは、削除がより速く、より少ないredoを生成するように、パーティション化されたテーブルに移動しています(削除を発行するのではなく内容を含むテーブルスペースを削除してください)。インサートを実行しているマシンとDBとDBを実行しているマシンのパフォーマンスには重大ですが、重大です。

2

悲しいことに、私は、これを行う方法を教えてくれるNDA契約によって禁止されています。私はあなたがやろうとしていることを正確に実行する非リレーショナルデータベースを作成したチームで働いていました。それは城砦と呼ばれています。しかし、公開されているもののリンクを教えてもらうことができます。また、それがどのように機能するかについていくつかのアイデアを提供する必要があります。

http://zone.ni.com/devzone/cda/tut/p/id/6579

あなただけの製品を買うことができるが、それはかなり高価です。

また、このうちKarlポイントは、一般的にWonderwareLookout、およびLabVIEW DSCようSCADA製品に使用されます。

SCADA data storageを検索すると、興味深い読者も増えます。


データ量が少ない場合、リレーショナルデータベースはこの問題を解決できます。時間が経つにつれて起こりがちなのは、データが限界を超えて成長し、リレーショナルデータベースが容量を超えて満たされるということです。優れたSCADAデータストレージシステムは、毎秒50000のポーリングを容易に処理できます。ある時点でさえ、彼らは扱いが大きくなりすぎてしまいます。

1

RRDToolは、オープンソースの業界標準であり、時系列データ用の高性能データロギングおよびグラフ作成システムです。」

2つの部分に分かれています.1つは、時系列データを記録、保存、取得し、もう1つはグラフ作成のための部分です。それが使用されている例はたくさんあります。

あなたがそれを使用しなくても、デザインは間違いなく適切です。

関連する問題