異なるデータポイントが潜在的に異なる属性を持つ多量の金融時系列データを格納する必要があります。異種属性を持つ財務時系列データに最適なデータベース技術は何ですか?
たとえば、株式とオプションを含む時系列の金融商品をデータベースに保存する必要がある状況を考えてみましょう。株式とオプションの両方は、任意の時点で価格を持っていますが、オプションにはグリックス(デルタ、ガンマ、ベガ)などの追加属性があります。
ここではリレーショナルデータベースが最も適しているようです。属性ごとに列を作成し、未使用の属性をNULLに設定します。上の例では、株式を表すレコードの場合は列の一部のみを使用し、オプションの場合は他の列を使用します。
このアプローチの問題は、非常に非効率的で(多数のNULLを格納することになります)、非常に柔軟性がない(属性を追加または削除するたびに列を追加または削除する必要がある)ということです。
すべての属性を縦型テーブル(Key-Name-Value)に格納する方法もありますが、すべての属性を安全でないものにする(たとえば、すべて文字列として格納するなど) 。
私が考えた別の選択肢は、属性をXML文書として時系列表の単一の列に格納することです。私はこのアプローチをテストしましたが、パフォーマンスの観点からは実用的ではありません。より多くの時系列レコードの属性を抽出する場合は、各行のXML解析が遅すぎます。
NoSQLとRDBMSの組み合わせで、キー・タイムスタンプ・ペアはリレーショナルの表形式データベースの行のように動作しますが、すべての属性は行レベル・バッグに格納され、それぞれに高速アクセスできます。
このようなシステムを知っている人はいますか?私が記述しているデータの種類を格納するための他の提案はありますか?
ヌルはデータベース内にスペースをとらないため、効率的ではありません。たとえば、属性/属性グループごとのテーブルなどを考えましたか?それは垂直ではなくクエリ時間を短縮し、何かを追加したい場合には、おそらく使用中のテーブルを変更する必要はありません。 – Ben
EAVテーブルは、型の安全性、並べ替え/検索のためにひどいものです(インデックス内で通常は連続しているものはパフォーマンスを損なうことはありません)。外部キー関係を(意味を持って)強制することも不可能です - あなたは 'key'-'name'カラムをキーオフすることができますが、**値が有効であることを要求することができません。あなたが良い、_eventually_何かが起こるだろう。特に私には分かりませんが、私はハイブリッドシステムであることを見たと思っていました。さもなければ、私は提案されるようにマスター/子テーブルの方に向かうだろう。 –