テーブル名と列名についていくつかの仮定を立てますが、推定できると確信しています
取引所からクオートを受け取り、KDB ティッカー プラントに保存します。
定義上、tickerplant
非常に短い時間だけデータを保存し、それをファイルに記録して、データを RDB (および他のリスナー) に送信します。
これらのデータベースのパフォーマンスへの影響を最小限に抑えます
それはすべて、(a) データ量 (b) 最適な where 句に依存します。また、クエリに対処するのに十分な RAM がマシンにあるかどうかにも依存します。クリティカルに近づくほど、OS がメモリを割り当てるのが難しくなるため、クエリの実行に時間がかかります (ただし、メモリの割り当て時間は、ディスクからデータを取得する場合に比べて見劣りします。したがって、ディスク速度も重要です)。要素)。
まず、1 日を 10 分間隔で分割し、間隔ごとにボリュームを含む統計を作成する関数を作成するにはどうすればよいでしょうか?
あなたの友達は xbar です: http://code.kx.com/q/ref/arith-integer/#xbar
getBy10MinsRDB:{[instrument;mkt]
select max volume, min volume, sum volume, avg volume by 10 xbar `minute$time from table where sym=instrument, market=mkt
};
date
HDB の場合、(日付で分割されたデータベースの場合) 最も最適なクエリはsym
ですtime
。あなたの場合、あなたは時間を尋ねていないので、省略します。
getBy10MinsHDB:{[dt;instrument;mkt]
select max volume, min volume, sum volume, avg volume by 10 xbar `minute$time from table where date=dt,sym=instrument, market=mkt
};
部分ごとにループでレコードを抽出する必要がありますか、それとも 1 つのクエリで一度に抽出する必要がありますか?
いいえ、それは KDB で物事を行う絶対に最悪の方法です :-) ほとんどの場合、優れたベクトル化されたソリューションがあります。
データベースには、毎日約 1 億 5000 万件のレコードがあります。
KDB はカラム型データベースであるため、使用するカラムのタイプはレコード数と同じくらい重要です。それは記憶に影響を与えるからです。
他のチームでも使用されているため
上記のような単純なクエリで問題が発生している場合は、テーブルを市場ごとに分割して、おそらくクエリの衝突と負荷を減らすことを検討する必要があります。メモリが問題にならない場合は、-s
マルチスレッド クエリ (複数日にわたる) 用の HDB を検討してください。クエリの衝突を最小限に抑えるために、マルチスレッド入力キューの HDB で負のポート番号を検討してください (ただし、必ずしも高速になるわけではありません)。