大きな時系列データを効率的に保存する方法は？

いくつかの非常に大量の時系列データを保存し、クエリできるようにする必要があります。

データのプロパティは次のとおりです。

シリーズ数：約12.000（1万）
データポイントの数、グローバル：1か月あたり約500.000.000（5億）
混合値タイプ：データポイントの大部分は浮動小数点値で、残りは文字列です
サンプリング期間：シリーズ間およびシリーズ内で可変
タイムスタンプ：ミリ秒精度
データ保持期間：数年、減衰またはダウンサンプリングなし
データアーカイブはほぼリアルタイムで構築する必要がありますが、妥当な遅延（約1時間）が許容されます
必要に応じて過去のデータを再構築できますが、高コストです
時々ですが、ごくまれに、過去のデータを更新する必要があります

想定されるクエリのプロパティ：

データに対するクエリのほとんどはタイムスタンプベースのクエリです。1日から数ヶ月/年までの範囲。90％以上が最新データのクエリになります

その他の要件：

ソリューションは、無料のビールのように無料である必要があり、できればオープンソース

私が最初に考えたのは、SQLデータベースの代わりにバックエンドを格納するHDF5ファイルで PyTables / Pandasを使用することでした。

質問：

PyTables / Pandasが「最良の」ルートであると仮定すると、それぞれが特定の期間にわたる複数のHDFファイルにデータを分割するか、すべてが単一のファイルに入れられて巨大になるのが良いでしょうか？
固定形式または表形式を選択する必要がありますか？私にとっては、1か月に1つのHDFファイルを保持すれば、固定形式は問題なく見えます。このように、シリーズ全体がおそらくRAMに収まり、テーブル形式インデックスを必要とせずにメモリ内をスライスできるからです。私は正しいですか？

それが最善のアプローチではない場合、このデータストアをどのように構成する必要がありますか、またはどのテクノロジーを検討する必要がありますか？大量の時系列データの保存に取り組むのは私が初めてではありませんが、この課題を解決する一般的なアプローチは何ですか？

私が検討した他のアプローチ：

配列データベース：配列の開始時間と終了時間、およびサンプリング周期を保存するだけでよく、配列自体の値とインデックス付けが簡単なので、一定のサンプリング周期を持つ時系列に最適です。しかし、シリーズ自体の可変サンプリング期間では、タイムスタンプと値の関係をより厳密に保つ必要があります。これは、私の見解では、配列DBMSにはあまり適していません。
タイムスタンプ、paramID、値を列として持つ標準SQLデータベースですが、その性質上、クエリに対して大量のディスクI / Oを要求します

database python performance

— 空飛ぶ
ソース

配列データベース-en.wikipedia.org/wiki/Array_DBMS#List_of_Array_DBMSを検討する必要があります。私は、それらの1つが正しい、あるいは最高の、あるいは十分な答えでさえあるとは言っていません。そのリストのエントリのほかに、kdbシステム（kx.com）がありますが、それは無料ではありません。

— ハイパフォーマンスマーク

ご意見ありがとうございます。私は配列データベースを検討しましたが、これらの問題は、それらが配列の開始時間と終了時間およびサンプリング期間のみを保存し、その後の値のみを保存する必要があるため、一定のサンプリング周期を持つ時系列に最適であることです配列自体とインデックス作成は簡単です。しかし、シリーズ自体の可変サンプリング期間では、タイムスタンプと値の関係をより厳密に保つ必要があります。これは、私の見解では、配列DBMSにはあまり適していません。そうは言っても、間違ったことを証明できたらうれしいです。

— flyingmig

私がこれまでに考えたことを追加するための質問の編集

— -flyingmig

質問：すべてのデータを保存する必要がありますか？データは時間の経過とともに減衰する可能性がありますか、および/またはフロートベースのシリーズに許容可能な精度レベルがありますか？

— Jトラナ

@ moinuddin-quadri私は、テーブル形式を使用して、毎月のHDF5ファイルに裏打ちされたpandas DataFrameオブジェクトを使用することになりました。システムは1年以上稼働しており、SSDディスクを使用しなくても、非常に安定して高速であることが示されています。時間があるときは、答えとしてそれをすべて書き上げようとします。それ以外の場合は、お気軽にPMにご連絡ください。

— flyingmig

回答:

グラファイトプロジェクトの一部であるカーボンとささやきを見てみてください。Carbonは非常に大量の時系列データを処理できます。しかし、今ではドキュメントを読んだので（使用してから数年が経ちました）、数値データ専用です。あなたは文字列データも持っていると言ったので、あなたはこれが役に立たないかもしれない。ただし、大量のデータを迅速に処理する方法についての知恵を集めることができるかもしれません。

グラファイトがOrbitzで最初に生産に投入されたとき、それがどれだけうまくスケーリングするかを知るために、1分あたり160,000メトリックを処理していました。

— ブライアン・オークリー
ソース

提案していただきありがとうございますが、ミリ秒の精度が必要なときはその精度が2番目であり、あなたが正当に指摘したように、私はそこに保存できない文字列データも持っているので、私の理解からささやきは適合しません。

— flyingmig

@flyingmigそれほどささやいてはいけません。タイムスタンプはUnixエポック値です。また、質問で説明した「文字列データ」は列挙型のように聞こえ、通常は小さな整数値として保存されます。

— ロスパターソン

シアーズは、カーボン/グラファイト/セレスを使用して、毎分4M +のユニークなデータポイントを保存しています。完全ではなく、グラファイトクラスタリングとSSDが必要ですが、動作します。そこに他のすべてのソリューションは、私たちが発見したことを、このレベルにスケーラブルではありませんが、あなたはアイデアを持っている場合、でチャイムにお気軽に。

— ケヴィン・J.ライス

InfluxDBは、Goで記述されたオープンソースデータベースです。特に時系列データを処理するために作成されており、Cassandraよりもはるかに優れたパフォーマンスを示すベンチマークを公開しました。

InfluxDBは3つのテストすべてでCassandraよりも優れており、書き込みスループットは4.5倍、ディスクスペースは10.8倍、テストクエリの応答時間は最大168倍になりました。

— ダン・ダスカレスク
ソース

列指向のデータベースをチェックアウトすることもできます。配列データベースの意味はわかりませんが、推奨されるアプローチを使用すると、時間枠ごとに動的な値の数を設定できます。同じタイムスタンプに複数の値を設定することもできます。興味深い部分は、同じタイムスタンプで測定された値がある場合、追加の列として保存できることです（温度と湿度を測定するセンサー、株式取引価格と取引のサイズなど）。列指向の性質のため、100列のテーブルを作成できますが、クエリが5列のみにアクセスする場合、データベースは5列のデータのみを読み取ります。

独自の時系列データベースの作成に関するシリーズを作成しましたので、ご覧ください。

パート1：https : //medium.com/@hellomichibye/column-oriented-database-introduction-part-1-572e5780aebb
パート2：https : //medium.com/@hellomichibye/column-oriented-database-draft-part-2-21199a2de18a

— こんにちは
ソース