2

私は取引データに標準のスプレイ形式を使用しています。そこでは、各日付と各列のディレクトリがそこに個別のファイルとしてあります。csv ファイルから読み取り、以下のコードを使用して保存しています。win7、64bitで試用版32bitを使用しています。

readDat: {[x]
tmp: read data from csv file(x)
tmp: `sym`time`trdId xasc tmp;
/trd: update `g#sym from trd;
trade:: trd;
.Q.dpft[`:/kdb/ndb; dt; `sym; `trade];
.Q.gc[];
};

\t readDat each 50#dtlist

`g#sym を使用する場合と使用しない場合の両方を試しました。データには通常、日付ごとに 1.5MM 行があります。これの選択時間は、1 日で 0.5 から 1 秒です。以下のクエリのいずれかの時間を改善する方法はありますか。

\t select from trade where date=x
\t select from trade where date=x, sym=y

セグメンテーション、パーティショニングなどに関するドキュメントを読みましたが、ここで何か役立つかどうかはわかりません。

よく考えてみると、シンボリックごとにテーブルを作成すると速度が上がるのでしょうか? 私はそれを試していますが、知っておくべきメモリ/スペースのトレードオフがあるかどうかを知りたいと思っていました.

4

3 に答える 3

1

実際のボトルネックが何であるかを確認するためにプロファイリングを行いましたか? 問題がディスクの読み取り速度に関係していることがわかった場合 (iostat などを使用)、より高速なディスク (SSD)、より多くのメモリ (より大きなディスク キャッシュ用) を取得するか、またはpar.txtを使用してデータベースを複数のサーバーに分割することができます。クエリが複数のディスクとコアで並行して発生するようなディスク。

于 2013-10-09T00:57:06.417 に答える
0

.Q.dpft を使用しているため、既に DB をパーティション分割しています。ユースケースがクエリで常に 1 つの日付を渡す場合、日付でセグメント化してもパフォーマンスは向上しません。シンボル範囲でセグメント化することもできますが (こちらを参照)、これは私が試したことはありません。

パフォーマンスを向上させる基本的な方法の 1 つは、列のサブセットを選択することです。クエリを実行するときに、本当にすべてのフィールドを読み取る必要がありますか? テーブルの幅によっては、一部のファイルを完全に無視できるようになったため、これは大きな影響を与える可能性があります。

パフォーマンスを向上させる別の方法は、`u# を sym ファイルに適用することです。これにより、sym ファイルの検索が高速になるため、2 番目のクエリが高速化されます。これは実際にはあなたの宇宙の大きさに依存しますが. これの利点は、私が想像する要求された列の数を減らすことに比べてわずかです。

于 2013-10-08T15:06:33.310 に答える