历史数据存储和检索答案

【问题标题】：historic data storage and retrieval历史数据存储和检索
【发布时间】：2013-10-08 11:07:01
【问题描述】：

我为我的交易数据使用标准的张开格式，其中我有每个日期的目录和每个列作为单独文件的目录。我正在读取 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 创建一个表会加快速度吗？我正在尝试，但想知道是否有我应该注意的内存/空间权衡。

【问题讨论】：

标签： kdb

【解决方案1】：

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

【讨论】：

关于如何进行分析和查找瓶颈的任何想法？

【解决方案2】：

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

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

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

【讨论】：

只选择有用的列并没有多大帮助，因为该表只有 2 个非必要列。你能解释一下如何申请u#, if i try u#sym 它失败了。
sym 文件中只有 275 个 sym。你认为 `u# 在这里会有所帮助吗？
275 非常小，因此 u# 几乎没有改进。鉴于您的查询配置文件，我认为提高性能的唯一选择可能是在 sym 上进行分段。这将有助于您的第一个查询，因为您现在可以并行阅读，并帮助您的第二个查询，因为您只点击一个片段。

【解决方案3】：

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

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

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

【讨论】：