3

データベースに一連の時系列を保存する必要がありますが、サイズ処理時間の両方が心配です。

サイズを縮小するために、別のプロジェクトで、時系列全体を保存するために zip/JSON を使用しましたが、これはストレージ スペースの点で非常に効率的です。しかし問題は、一部のデータを検索するには、最初に時系列全体を取得し、解凍してシリアル化を解除する必要があることです。もちろん、 SQL SELECT/WHERE などのデータベース統合クエリ機能を使用することはできません。

そのため、 1 つのポイントしか必要としない場合でも、データを取得するために帯域幅を消費し、 CPUを解凍してRAMを保存する必要があります...

時系列は常に全体として操作され、本質的にグラフまたは Excel で表示されるため、これは以前のプロジェクトでは問題ではありませんでしたが、今回はデータベース内のデータを検索する最小限の機能が必要です。

SQL を使用するなど、データ操作に関してこの柔軟性を可能にするために、「標準形式」があります: one row by dateですが、2 つの懸念事項があります。

  • 10 年以上の時系列には 3000 の値がある可能性があるため、3000 行を意味します。MySQL や PostgreSQL のような「通常の」データベースがこのような膨大な数の行を処理できるかどうかはわかりませんが、間違っていることを願っています
  • DBMS がすべてのセルに必要なスペースを最適化するのに優れているかどうかはわかりませんが、「大きすぎない」間は問題ありません

私は任意の無料データベースを選択できるので、NoSQLも役に立ちます。

何か提案がありますか、それともより良いフィードバックがありますか?

ご意見ありがとうございます。

4

1 に答える 1

3

TempoDB をチェックアウト: http://tempo-db.com

私は共同設立者であり、まさにこの問題を解決するためにサービスを構築しました。

アクセスパターンは、時間順にデータを書き込み、通常は編集せず (非常に不変)、時間ごとにデータを読み戻します。

直面する根本的な問題は、何十億もの行があるタイムスタンプのインデックス作成です。クエリのパフォーマンスを、基礎となるデータセットの合計サイズから切り離したいと考えています。データセットのサイズは常に少なくとも直線的に増加しています。私たちはそのすべてを行います...そしてもっと:)

于 2013-06-12T20:35:20.173 に答える