時系列：SQLまたはNoSQL？

SQLとNoSQLの一般的な違い（または従来の違い）は気にしません。

現在、内部時系列のストレージの変更を検討しています。これらにはすべて、さまざまなソースからの財務データが含まれています。現在、独自のデータベースにデータを保存しています。独自のクエリ言語を持つのは、まさにNoSQLです。

コミュニティからのインプットに興味があります。SQLデータベースにデータをどのように保存しますか？NoSQLを介してSQLを使用すること、特に時系列のメリットは何ですか？これをSQLに保存することを検討するのは正気ですか？

データセットは数百万の時系列で構成され、これらの約10％にはそれぞれ数百万のレコードが含まれています。時系列は階層的に整理されます：/ Market / Instrument / Value / Frequency、ここで：

• 市場は証券取引所などであり、基本的には商品の集まりであり、通常は同様の商品です。
• 楽器は楽器です。これはインジケーター（ブレント原油）、エクイティ（GOOG）などです。
• 値は、楽器の複数の種類のデータの1つです。これは、近い、高い、低いなどです
• 頻度は、特定の時系列値の頻度です。毎週、毎日、毎月、ティック、任意など

データはどのようにSQL dbに保存されますか？1つの大きなテーブル（何かで分割されている場合があります）、市場または銘柄ごとに1つのテーブル、時系列ごとに1つのテーブル。

前もって感謝します。

一般に、このような構造化されたデータセットの場合、ほとんどの日常業務（つまり、任意の時間からの小さなデータの取得）で高速なカスタムデータ形式を作成できると思います。標準のDBツールに移行する利点は、アドホッククエリ、複数アクセス、レプリケーション、可用性などの追加機能にある可能性があります。また、標準ベースのデータストアを維持するためのサポートを雇う方が簡単です。

そのデータを保存するデータベースをセットアップするように求められたら、次のことを行います。

提案されたスキーマ

（1）コアデータは、それぞれが2つの列を含む多数の（1000の）個別のテーブルに配置されます。

1. time：SQL DATETIMEデータ型または何らかのエポックからの数値型（これが主キー）
2. 値：データに応じて適切に入力します。デフォルトでは単精度の浮動小数点数ですが、金融取引には固定小数点データ型の方が適している場合があります。これはおそらく索引付けされていません。

これらのテーブルは非常に大きくなるため、（たとえば）年ごとに手動でパーティション分割することができます。ただし、システムのパフォーマンスを確認し、必要に応じて調整する必要があります。

これらのテーブルには一意の名前が必要であり、いくつかのオプションがあります。人間が読める形式（nyse_goog_dailyhighs_2010など）またはランダム（私の好み）です。いずれにせよ、メタデータテーブルのセットが必要であり、ランダムなテーブル名は、開発者が推論することを意図していない名前に何かを推論することを防ぎます。

（2）メタデータは、アプリケーションの必要に応じて、個別のテーブルに保存されます。

メタデータを追跡するには、追加のテーブルまたはテーブルのセットが必要です。これらの表には、交換、商品、値、頻度、日付範囲、出所（データの出所）、および必要なその他のデータが含まれます。これらはデータテーブル名にマッピングされます。

十分なデータがある場合、このルックアップは実際にテーブル名とデータベース名を提供し、一種の自己実装データシャーディングを可能にします（それが用語の正しい使用である場合）。しかし、私はそれを保留にします。

次に、アプリケーション層でメタデータテーブルにクエリを実行してデータの場所を特定し、ビッグデータテーブルで比較的簡単なクエリを実行してデータを取得します。

利点：

• 私の（比較的限られた）経験では、データベースは通常、少数の大きなテーブルよりも簡単に多数の小さなテーブルを処理できます。このアプローチにより、メンテナンスが容易になります（古いデータのパージ、破損したテーブルの再構築、バックアップからの作成/再ロード、新しいエンティティの追加など）。これにより、（たとえば）異なるレートのデータがある場合、または異なるデータ型が必要な場合、異なる種類のデータが完全に分離されます。

• このスキニーテーブルの概念により、最も一般的なクエリである単一のエンティティからの連続したデータ範囲に対する高速ディスクアクセスも可能になります。ほとんどのデータアプリケーションはディスクI / Oに制限があるため、これは検討する価値があります。コメンターがすでに示唆しているように、これは列指向データベースの理想的なアプリケーションですが、私のキャリアを賭けるのに十分な主流である列指向製品をまだ見つけていません。このスキーマはかなり近くなります。

短所：

• かなり率直に言って、100から1000のテーブルのタイムスタンプ列にまったく同じデータがある場合、ディスクスペースの約半分はタイムスタンプの保存専用です。（実際、これは簡単なテーブル結合を実行する場合の要件です）。

• テーブル名を保存し、動的なルックアップを実行するには、アプリケーションの複雑さと文字列操作が多く必要になるため、やる気になります。しかし、それは他の選択肢よりも優れているようです（以下で説明します）。

考慮事項：

• 時間フィールドの丸めに注意してください。結合を有効にするのに十分な値（適切な場合）でありながら、明確になるように十分に正確な値が必要です。

• タイムゾーンと夏時間に注意してください。これらはテストするのが難しいです。データストアにUTC要件を適用し（これにより、人気がなくなる可能性があります）、アプリケーションでの変換を処理します。

バリエーション：

私が検討したいくつかのバリエーションは次のとおりです。

データの折りたたみ：時 系列が等間隔の場合、1つのタイムスタンプ列と（たとえば）10個のデータ列を使用します。タイムスタンプは最初のデータ列の時間を参照するようになり、他のデータ列はそのタイムスタンプと次のデータ列の間に等間隔であると想定されます。これにより、以前はタイムスタンプの保存に使用されていた多くのストレージが節約されますが、かなりのクエリやアプリケーションの複雑さが犠牲になります。連続した範囲の単一エンティティクエリでは、ディスクアクセスが少なくなりました。

マルチプレックス： 複数の時系列が同じ時系列を使用することがわかっている場合は、上記のように1つのタイムスタンプと（たとえば）10個のデータ列を使用します。しかし今では、各列は異なる時系列を表しています。これには、テーブルおよび列名のルックアップではない、メタデータテーブルの更新が必要です。ストレージスペースが削減されます。クエリは単純なままです。ただし、連続した範囲の単一エンティティクエリでは、はるかに多くのディスクアクセスが必要になります。

メガテーブル： 「マルチプレックス」の概念を極限まで高め、すべてのデータを単一のテーブルに、列ごとに時系列で1回配置します。これは、連続した範囲の単一エンティティクエリのために大量のディスクアクセスを必要とし、メンテナンスの悪夢です。たとえば、新しいエンティティを追加するには、多数のTBテーブルでMODIFY TABLEコマンドが必要になりました。

この形式の詳細については、MySQLの列が多すぎますのさまざまな回答を参照してください。

完全に正規化されたテーブル： 多くの2列テーブルを使用する代わりに、列が時間、データID、および値である1つの3列テーブルを使用できます。これで、メタデータテーブルはテーブル名や列名ではなく、ID値をルックアップするだけで済み、アプリケーションレイヤーではなくSQLクエリにより多くのロジックをプッシュできます。

現在、ストレージの約2/3が正規化列で消費されているため、多くのディスク領域が使用されます。

高速で連続した単一エンティティクエリには、プライマリキーの順序（dataid、timestamp）を使用できます。または、挿入を高速化するために（timestamp。dataid）の主キーの順序を使用できます。

ただし、これらのバリエーションを検討した後でも、私の次の開発の計画は、それぞれ2列のテーブルがたくさんあることです。それ、または私より賢明な誰かによってすぐに投稿される方法:)。

MongoDBを使用すると、オンザフライでコレクションを非常に迅速に作成できます。データを別々のデータベースに配置し、それらのデータベース内のコレクションを見てください。高速検索が必要な場合は、各シャードをシステムメモリ内に保持するために必要なメモリ量を検討してください。あなたが必要とするラインに沿って進化する何か新しいものがあるなら、社内のソリューションに固執するのは愚かなことです。良いイニシアチブのように思えます。