【问题标题】:When to save time-series data何时保存时间序列数据
【发布时间】:2012-03-11 12:44:30
【问题描述】:

我们正在收集大约 30,000 种金融工具的市场数据。我们希望每 10 分钟左右保留一次历史数据。它都保存在 PostgreSQL 表中。我在两种方法之间进行辩论:

“快照”

每 10 分钟存储一次所有符号的价格,带有漂亮的圆形时间戳。

优点:

  • 使查询变得容易,因为时间戳是已知的先验,只需四舍五入到最后 10 分钟的倍数。

缺点:

  • 更大的数据集
  • 大刀片会影响性能
  • 不会在不存储其他信息的情况下传达仪器数据更改的频率

“滚动更新”

仅在更新时存储每个符号,如果自上次更新后经过的时间超过 10 分钟。

优点:

  • 更少和更小(更便宜)的插件
  • 较小的数据集
  • 数据将更准确地反映实际的变化频率(对于每 10 分钟更换一次以下的仪器)

缺点:

  • 查询将更加复杂/昂贵,因为所需行的时间戳未知。

注意事项

  • 插入比查询多得多
  • 我们希望能够扩展到更多的仪器,可能会更新频率略高。

我一直在执行“滚动更新”,但没有发现查询有任何性能问题。表上只有一个多列索引,但插入似乎仍然比查询昂贵得多,因此这似乎是更适合的方法。这是一个合理的方法吗?还有其他我遗漏的注意事项吗?

【问题讨论】:

  • 您选择了哪个选项,为什么?数据库是干什么用的?

标签: database time-series


【解决方案1】:

我正在重新实现我们的提要,并且我正在从滚动更新切换到快照。编码更容易;我不必跟踪何时存储什么。使用二进制副本将数据加载到经过仔细索引的 PostgreSQL 表中,因此插入性能不是问题;我们看到的速率至少有几千条记录/秒,这已经足够了。

我没有使用专门的圆形时间戳,但如果我们想这样做的话,这将使检索整个快照变得更加容易。此时,我们一次只在一个时间点检索一个交易品种的数据。

我们处理的大多数符号每 10 分钟更改一次以上,因此无论如何我们的数据集都不能反映这些符号的变化频率。

更新:我们已开始更广泛地使用历史数据。我们现在可以轻松地在单个时间点检索更大的数据块,这是一个真正的福音。

【讨论】:

    【解决方案2】:

    快照方法存在一些问题,因为并非所有工具都会每分钟都在运行,特别是因为您正在考虑 30,000 种工具,其中必须包括一些流动性较低且可能不经常交易的工具。

    滚动更新方法存在到处都有时间戳的问题,这可能会在查询数据时使事情变得复杂。

    结合它们的第三种方法效果最好,您在解析器的内存中保留所有仪器的“滚动更新”的临时记录,并在 10 分钟标记时将最新值写入永久表并重新启动临时记录。这种方法还可以轻松跟踪开盘价、最高价、最低价、收盘价和成交量值。

    【讨论】:

    • 其实是的。由于我们使用当前数据完成大部分工作,因此数据库中有一个单独的表。某些仪器不经常更新的事实本身并不是问题。这只是意味着为了简化检索,我们拥有比理论上需要的更多的数据。
    • 快照方法的数据不应比滚动方法多得多...在这两种情况下,您每 10 分钟为每个仪器保存一个数据点(我猜是 OHLCV)。除非我错过了图片的一部分?如果有的话,我会倾向于存储所有原始消息或生成具有最小粒度(如 1 分钟)的数据快照,因为这将使时间窗口大小的变化变得微不足道......交易者突然决定你需要移动到 5 或 15 分钟并不意味着回到第 1 格,只需运行一个脚本。
    • 快照当然有更多的数据。正如您所指出的,通过快照,我们在每个间隔保存所有仪器,但有些变化非常罕见。通过滚动更新,保存的频率会大大降低。
    • 我在您的linkedin上看到你们交易期权,特别是当您远离资金时,它们可能会非常缓慢。既然它们不经常滴答作响,为什么不保存每条原始记录,然后在 Lambda 架构上使用批处理来聚合它们呢?借助 SPARK 或 STORM 等工具,您可以获得所需的信息,并且可以灵活地在未来将分析转向不同的方向。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2014-08-03
    • 2020-11-02
    • 2015-10-13
    • 1970-01-01
    • 2018-07-19
    • 2023-03-25
    相关资源
    最近更新 更多