データを保存するために使用できる技術

私は0.1秒ごとに約1kバイトのデータを保存するアプリケーションを持っています。これは36MByte/hour、つまり約600MByte/dayです。データを保存するために使用できる技術

データは圧縮率が高いため、10：1〜100：1の間で圧縮する必要があります。すべてのデータはタイムスタンプによって参照されます。

私の質問はこれです：このデータを保存するにはどのようなテクニックを使用できますか？

制約：

データベースのサイズが大きくなるにつれて増加することはできませんデータベースにデータを挿入するための時間。この制約はMicrosoft SQL Serverを排除します（試してみましたが、5日後には「挿入」が1分掛かるたびに停止します）。
1時間に4時間のデータ記録を効果的に中断することができます。これにより、圧縮などの時間が短縮されます。
LINQ for .NETと互換性があります。つまり、 LINQアダプタ（MySQLスタイルのインターフェイスは大丈夫でしょう）。

2010-12-19 Contango

SQLサーバーの構成が正しくありませんでした。インサートが無期限に一定の時間がかかるように設定することは可能です。 –

1分以上挿入しますか？時間の99％は、これはデータベースではなくクエリの問題です。 NOLOCKでInsertを指定して、挿入されている行のインデックスがある場合は、挿入された行が途中で無作為にではなく、インデックスの「最後」またはその近くに移動することを確認してください。 – Juliet

私はLinqを使用する必要性を再評価したいと思います...私はLinqが素晴らしいと思うのですが、私はこれを自分で使っていますが、このようなことはクライアント側の処理を奨励するプログラミング方法が気になります（サーバー側処理）。 – Arafangion

1つのアプローチは、着信データを単にディスク上のファイルに追加することです。 1日後に新しいファイルに切り替えて、前日のファイルを圧縮して保存するプロセスを起動します。

理由を説明することなく、データをデータベースに保存する必要があると思われるようです。あなたは？

2010-12-19 22:22:41

私はそれを簡単に照会できるように、データベースにデータを入れたいと思っています。 LINQクエリは非常に表現力があり、作業が楽になります。 – Contango

今日のデータをすぐに入手する必要がない場合は、バックグラウンドプロセスでデータベースに実際に挿入することもできます。そうすれば、あなたのオンラインロギングはデータベースに全く依存しません。これは、より堅牢なシステムの1つの側面になります。 –

並行ライターがない場合、これは実際には非常にうまくスケールされる本当に素晴らしいソリューションです。 – Ronnis

SQL Serverでロードの小規模な処理をタイムリーに行うことができない場合は、データの挿入方法を検討していないと、RDBMSが有効かどうか疑問に思っています。

他のインデックス/関数/プロセスブロック/読み取りを持たない単一のテーブル（プライマリキー付き）に非常に単純な挿入を行っていますか？あるいは、このプロセスは実際にあなたが話しているこの単純な/小さなインサートよりも少し複雑ですか？

もしあなたがLinqを使って死んでいるのであれば、あなたのlinq文をプロファイリングして、ORMに何か愚かなことを言わないようにしていますか？

2010-12-19 22:46:23 Gator

簡単な挿入作業をしています。私はあなたが提案したようにします - LINQをプロファイルして、愚かなことをしないようにします（テーブル全体の負荷をソートできるようにする「Orderby」の使用など）。 – Contango

おそらく、すべての内容をバイナリファイルに保存し、メタデータをDBに保存することができます。

2010-12-20 00:41:38

答えて