1

時系列の金融市場のティック データを大量に保存しています。

通常、このデータは順次書き込まれます (つまり、データは受信時にタイムスタンプが付けられてから db に書き込まれます)。

タイムスタンプ (のみ) に基づいてデータを読み取る必要があります。つまり、一般的なクエリは、「2012 年 1 月 1 日から 2012 年 2 月 1 日までのすべてのデータを選択する」のようなものになります。

質問: READ パフォーマンスが最重要である場合、このデータをバイナリ ファイルまたは mySQL データベースに保存したほうがよいでしょうか?

データの特性はファイルにより適しているように思われます。予備テストでは、ファイルの方が高速であることが示されているようです (つまり、データをより速く読み戻すことができます)。

4

1 に答える 1

1

あなたの説明は、時間の次元についてのみ語っています。しかし、他の次元とは何ですか? おそらくさまざまな金融商品 (MSFT、IBM、AAPL など)。

金融市場データの性質は、通常、時間ディメンション (数十万の株価の毎日の更新を取得する) によって順序付けられて受信されますが、金融商品ディメンション (単一の金融商品のすべての価格をクエリするため、場合によっては多少制限される可能性があります) によって照会されます。時間）。

したがって、最大の読み取りパフォーマンスが必要な場合は、データが受信された方法ではなく、照会される方法、つまりディスク上に保存されていることを確認する必要があります。金融商品によって物理的に注文する必要があります。

私は過去にOracleでこれをうまく実装しました。基本的に、金融商品識別子と日付を主キーとして使用して、索引構成表を作成します (識別子が最初である必要があります)。オラクルは、金融商品の識別子と日付でソートされたデータを多かれ少なかれ保存します。したがって、特定の時間範囲で単一の金融商品の株価をクエリすると、必要なすべてのデータが連続したディスク ページにあり、既に目的の順序になっているため、クエリは非常に高速になります。

私は MySQL の経験があまりありません。しかし、私が理解している限りでは、InnoDB ストレージ エンジンとクラスター化インデックスを使用して同じことを実現できます。

CREATE TABLE prices (
    ticker CHAR(10),
    date DATE,
    close NUMBER(10, 4),
    PRIMARY KEY (ticker, date)
) ENGINE=InnoDB;

また、バイナリ ファイルは使用しないでください。あなたはそれを後悔するでしょう。

于 2013-01-02T09:11:51.753 に答える