我正在为我的交易数据使用标准的splayed格式，其中我将每个日期的目录和每列作为单独的文件放在那里 . 我正在读取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创建一个表加速的事情吗？我正在尝试，但想知道是否有我应该知道的内存/空间权衡 .
3 回答
你有没有做过任何剖析，看看实际的瓶颈是什么？如果您发现问题与磁盘读取速度有关（使用iostat之类的东西），您可以获得更快的磁盘（SSD），更多内存（用于更大的磁盘缓存），或使用par.txt在多个磁盘上分割数据库查询并行发生在多个磁盘和核心上 .
在使用.Q.dpft时，您已经在对数据库进行分区 . 如果您的用例始终在查询中传递一个日期，则按日期分段将不会提供任何性能改进 . 您可以按符号范围进行分段（请参阅here），但这绝不是我尝试过的 .
提高性能的一种基本方法是选择列的子集 . 在查询时，您真的需要阅读所有字段吗？根据表的宽度，这会产生很大的影响，因为它现在可以完全忽略某些文件 .
提高性能的另一种方法是将`u＃应用于sym文件 . 这将加快您的第二个查询，因为sym文件上的查找速度会更快 . 虽然这实际上取决于您的宇宙大小 . 与减少我想象的列数相比，这样做的好处是微不足道的 .
正如用户1895961所述，仅选择某些列会更快 . KDB展开的\分区表几乎只是文件系统上的文件，文件越小，读取的越少，它就越快 . 文件夹数量和文件数量之间的 balancer 是关键 . 每个分区1.5mln是可以的，但是偏大 . 也许您可能想要通过其他方式进行分区 .
您可能还希望规范化数据，将其拆分为多个表，并使用链接列将其重新连接回来 . 如果设置正确，链接列可以非常强大，如果添加了过滤，可以帮助避免从磁盘读取太多数据 .
还尝试将您的数据转换为char而不是sym，我发现这样做会带来很大的性能提升 .