2

私が持っているのは、数千の金融商品のオーダーブックの約 130 GB の時変状態データです。

私が持っているcsvファイルには、オーダーブックの状態の各変更ごとに行が含まれています（実行された取引、挿入された注文などによる）。状態は次のように記述されます: 一般的なオーダーブック情報のいくつかのフィールド (例: 金融商品の isin コード)、状態変化に関する情報のいくつかのフィールド (orderType、時間など)、最後に現在の状態の売買レベル。売り注文と買い注文の両方に最大 20 のレベル (買いレベル 1 は最良の買い価格を表し、売りレベル 1 は最良の売り価格を表すなど) があり、それぞれが 3 つのフィールド (価格、総量、および注文金額）。最後に、買い側と売り側の両方について、20 を超えるレベルの集計データの追加の 3 つのフィールドがあります。これは合計最大 21*2*3 = 州ごとのレベル データの 126 フィールドになります。

問題は、20 近くのレベルが存在することはめったにないため、各レベルにフィールドを予約する意味がないように思われることです。たとえば、3 つの購入レベルがあり、残りのフィールドが空の行があるとします。一方、同じオーダーブックは、しばらくすると 7 つの買いレベルを持つことができます。

一般的なオーダーブック情報を独自のテーブルに正規化することは間違いありませんが、レベルを効率的に処理する方法がわかりません。

どんな助けでも大歓迎です。

4

1 に答える 1

0

ある時点で、まさにこのデータ構造に対処しなければなりませんでした。重要な問題の 1 つは、データがどのように使用されるかです。任意の時点での最良のビッドとアスクの価格のみを探している場合は、レベルに大きな違いはありません。市場深度を分析している場合、レベルが重要になる可能性があります。

使用しているデータの量については、インデックス作成やパーティション分割などの他の考慮事項がより重要になる場合があります。特定のクエリに必要なデータがメモリに収まる場合は、テーブル全体がどれだけ大きくても問題ありません。

私のアドバイスは、異なるレベルを同じ記録に残すことです。次に、(ストレージ エンジンに応じて) ページ圧縮を使用して、空の値用に予約されている領域のほとんどを削除できます。SQL Server ではこれが自動的に行われるため、レベルを 1 つのレコードに入れるのは簡単でした。

ページ圧縮が機能しない場合の妥協案は、一定数のレベルを格納することです。通常は 5 つのレベルが入力されるため、空のフィールドでスペースが無駄になるという問題はありません。そして、そのレベル数は、ほとんどすべての用途に十分な場合があります。

于 2012-12-19T15:37:28.323 に答える