KDBクエリのパフォーマンス改善

私は株式のバックテストに使用している価格を含む単純なテーブルを持っています。KDBクエリのパフォーマンス改善

price_hist:([pxkey:`$()]price:`float$()) 
update `g#pxkey from `price_hist

pxkeyは、連結形式の文字列 'MSFT_5M_201710060945'、そう株式= MSFT、価格バーの間隔= 5分と日時= 201710060945です。私は単純なので、私はKDBの初心者であり、何かをすばやく実行したいので、個々の列の代わりに連結された文字列を使用しました。

私はそこに約500万行があり、パフォーマンスはまったく同じデータを使ってMySqlよりわずかに速いだけです。どのように（テーブル構造、属性、クエリ、何かを介して）これを改善するためのアイデア？ FYI私はqSharpライブラリとC＃を使用していると私は辞書を返します。この形式を使用してい照会する： - 生成されたシンボルの数百万人を作成

price_hist`MSFT_5M_201710060945

出典

2017-11-23 Tokyo D

は、KDBの+に良いアイデアになることはありません。、あなたはそれを移植すると、パフォーマンスを向上させるために

bar5m[(`MSFT;2017.10.06D09:45);`price]

を次のように

bar5m:([sym:`$();time:`timestamp$()]price:`float$())

は、あなたがそれを照会することができるはずのテーブルがあることを確認してください。私の代わりに辞書のキー付きテーブルを使用することをお勧めしますsym,timeでソートし、p属性をsymに設定します。

出典

2017-11-23 05:13:55

私の場合、price_histはキー付きのテーブルですよね。だからあなたの提案の違いは、別の文字列とdatetimeの列をキーとして使用することです[また、バーのために異なるテーブルに分割する]。 stringとdatetimeの列を別々にすると、パフォーマンスに大きな影響がありますか？ –

技術的には、キー付きの表はkdb +の辞書です。あるテーブルから別のテーブルへのマッピングです。これらの表に単一の列がある場合、キー付き表は単純な辞書とほとんど区別できません。私の答えの主な提案は、合成シンボルを使用するのではなく、複数のキー列を使用することです。 –

わかりました - 私はそれを試みます（そして、おそらくフォローアップで戻ってくるでしょう）。ああもう一つ..既存のデータから新しいテーブルを作成するための簡単な構文を教えてくれますか？これは、文字列を日付に変換することを意味します。それを正しくするには2時間かかりますが、20秒かかるでしょう！どうもありがとう！ –

KDBクエリのパフォーマンス改善

答えて

関連する問題