首页 文章

KDB - 历史表 - 这样做的“正确”方法是什么？

提问于
浏览 次
2

我有一个销售点系统，将我的数据导出到.csv然后导入KDB . 目前，我所做的是将所有数据从POS导出到csv，然后创建一个表 . 我有大约10个月的销售数据，我的csv文件大约是11mb . 随着时间的推移，我想csv文件真的很大，我想知道这是否效率低下 .

在我以前的工作中，我们要做的是为每一天的数据创建一个表，然后会有一个_hist表，它将所有日常文件组合在一起 . 因此，如果我想查看当天的数据，我会查看invoicedata表，如果我想查看所有时间，我会查看invoidata_hist表并设置查询以查看日期（dateA; dateB） . 我想知道我是否应该以这种方式设置，而不是我现在这样做 .

我最好有一个包含所有数据的非常大的csv文件，还是应该为每一天创建一个csv文件？如果第二种方式更好，任何人都可以让我知道设置这一切的最佳方法吗？

谢谢！

kdb

1 回答

  • 5

    如果您的记录总数不会超过几百万，那么分区可能是一种过度杀伤力 .

    如果我的 daily 表数大约为100万或更多，我会考虑对数据进行分区 .

    您还需要考虑如何访问数据，例如检查 date 分区表中的频繁客户的 last-n 记录可能会影响您的查询性能，因为您必须迭代地回顾 . 在这种情况下，展开的或每年分区的表可能是合适的 .

    虽然有多种方法可以将数据存储在磁盘上，但请查看this link .

    • 二进制序列化（将表存储为二进制块）

    ``:/db/t set ([] ti:09:30:00 09:31:00; p:101.5 33.5)`

    ``:/db/t/ set ([] ti:09:30:00 09:31:00; p:101.5 33.5) // trailing "/" in the file handle`

    .Q.dpft[directory;partition;p#field;tablename]`

    .Q.dpft[directory;partition;p#field;tablename]`

    • save function - 以二进制/ xml / csv / txt / xml格式保存数据 .

    由于您在问题中要求提供日期分区表，实际上有不同的方法可以partition your data：

    每天

    • 每月

    • 每年

    • 长（可在任何 long 列上自定义）

    You might want to store the data in a monthly partition based on the table count.

    要将数据保存到分区，可以使用.Q.dpft函数

    .Q.dpft[directory;partition;`p#field;tablename]

    来自code.kx的示例：

    q)trade:([]sym:10?`a`b`c;time:.z.T+10*til 10;price:50f+10?50f;size:100*1+10?10)
q).Q.dpft[`:db;2007.07.23;`sym;`trade]
`trade
    回复于

相关问题