2

我为我的交易数据使用标准的张开格式，其中我有每个日期的目录和每一列作为单独的文件。我正在读取 csv 文件并使用以下代码进行存储。我在 win 7、64 位上使用 32 位试用版。

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 行。选择时间为一天的 0.5 到 1 秒有没有办法改善以下任一查询的时间。

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

我已阅读有关分段、分区等的文档，但不确定是否有任何帮助。

再想一想，为每个 sym 创建一个表会加快速度吗？我正在尝试，但想知道是否有我应该注意的内存/空间权衡。

4

3 回答 3

1

您是否进行了任何分析以查看实际的瓶颈是什么？如果您发现问题与磁盘读取速度有关（使用 iostat 之类的东西），您可以获得更快的磁盘 (SSD)、更多内存（用于更大的磁盘缓存），或者使用par.txt将数据库分片到多个磁盘，以便查询在多个磁盘和内核上并行发生。

于 2013-10-09T00:57:06.417 回答
0

正如 user1895961 提到的，仅选择某些列会更快。KDB 展开\分区表几乎只是文件系统上的文件，文件越小，您必须读取的越少，它就会越快。文件夹数量和文件数量之间的平衡是关键。每个分区 150 万是可以的，但偏大。也许您可能想用其他东西进行分区。

您可能还希望对数据进行规范化，将其拆分为多个表并使用链接列将其重新连接起来。如果设置正确，链接列会非常强大，如果添加了过滤，可以帮助避免从磁盘读取太多数据。

还尝试将您的数据转换为 char 而不是 sym，我发现这样做可以大大提高性能。

于 2014-07-17T10:53:40.077 回答
0

当您使用 .Q.dpft 时，您已经在对数据库进行分区。如果您的用例总是在查询中传递一个日期，那么按日期分段不会提供任何性能改进。您可以按符号范围进行分段（请参见此处），尽管我从未尝试过这种方法。

提高性能的一种基本方法是选择列的子集。查询时真的需要读取所有字段吗？根据表格的宽度，这可能会产生很大的影响，因为它现在可以完全忽略某些文件。

另一种提高性能的方法是将 `u# 应用于 sym 文件。这将加快您的第二次查询，因为对 sym 文件的查找会更快。虽然这真的取决于你宇宙的大小。与减少我想象的请求的列数相比，这样做的好处是微不足道的。

于 2013-10-08T15:06:33.310 回答