历史数据存储和检索

loading...


2

我正在为我的交易数据使用标准的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回答

  • 0

    你有没有做过任何剖析,看看实际的瓶颈是什么?如果您发现问题与磁盘读取速度有关(使用iostat之类的东西),您可以获得更快的磁盘(SSD),更多内存(用于更大的磁盘缓存),或使用par.txt在多个磁盘上分割数据库查询并行发生在多个磁盘和核心上 .


  • 0

    在使用.Q.dpft时,您已经在对数据库进行分区 . 如果您的用例始终在查询中传递一个日期,则按日期分段将不会提供任何性能改进 . 您可以按符号范围进行分段(请参阅here),但这绝不是我尝试过的 .

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

    提高性能的另一种方法是将`u#应用于sym文件 . 这将加快您的第二个查询,因为sym文件上的查找速度会更快 . 虽然这实际上取决于您的宇宙大小 . 与减少我想象的列数相比,这样做的好处是微不足道的 .


  • 1

    正如用户1895961所述,仅选择某些列会更快 . KDB展开的\分区表几乎只是文件系统上的文件,文件越小,读取的越少,它就越快 . 文件夹数量和文件数量之间的 balancer 是关键 . 每个分区1.5mln是可以的,但是偏大 . 也许您可能想要通过其他方式进行分区 .

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

    还尝试将您的数据转换为char而不是sym,我发现这样做会带来很大的性能提升 .

loading...

评论

暂时没有评论!