我正在考虑使用 mongodb 或 ravendb 之类的数据库来存储大量股票报价数据,并想知道与 Sql Server 之类的标准关系相比这是否可行。
数据将不是真正的关系数据,而是几个巨大的表。我还认为我可以按分钟/小时/天/周/月等对数据行求和/最小/最大行数,以便更快地计算。
示例数据:500 个符号 * 60 分钟 * 60 秒 * 300 天...(我们存储的每条记录:日期、开盘价、最高价、最低价、收盘价、交易量、开盘整数 - 所有小数/浮点数)
那你们怎么看?
自从 2010 年提出这个问题以来,已经发布了几个数据库引擎或开发了专门处理时间序列的功能,例如股票报价数据:
对于 MongoDB 或其他面向文档的数据库,如果您以性能为目标,建议扭曲您的模式以在以秒为键的对象中组织记号(或以分钟为单位的对象,每分钟是另一个 60 秒的对象)。使用专门的时间序列数据库,您可以简单地查询数据
SELECT open, close FROM market_data
WHERE symbol = 'AAPL' AND time > '2016-09-14' AND time < '2016-09-21'
我还认为我可以按分钟/小时/天/周/月等对数据行求和/最小/最大行数,以便更快地计算。
使用 InfluxDB,这非常简单。以下是获取每日最小值和最大值的方法:
SELECT MIN("close"), MAX("close") FROM "market_data" WHERE WHERE symbol = 'AAPL'
GROUP BY time(1d)
您可以按时间间隔分组,时间间隔可以是微秒 ( u
)、秒 ( s
)、分钟 ( m
)、小时 ( h
)、天 ( d
) 或周 ( w
)。
在存储和查询大量股票报价数据方面,时间序列数据库比面向文档的数据库更好。
这里的答案将取决于范围。
MongoDB 是“输入”数据的好方法,而且它在查询单个部分时非常快。它也很好,因为它可以水平扩展。
但是,您必须记住的是,您所有重要的“查询”实际上都是由“批处理作业输出”产生的。
例如,Gilt Groupe 创建了一个名为Hummingbird的系统,用于在其网站上进行实时分析。演示在这里。它们基本上是根据收集的性能数据在很短的时间间隔(15 分钟)内动态呈现页面。
在他们的案例中,他们有一个简单的循环:将数据发布到 mongo -> 运行 map-reduce -> 将数据推送到网络以进行实时优化 -> 冲洗/重复。
老实说,这非常接近您可能想要做的事情。但是,这里有一些限制:
另一方面,您将在 SQL 中遇到这些问题的不同变体。
当然这里有一些好处:
不过,正如其他人所提到的,您将无法访问 ETL 和其他常用分析工具。你肯定会写很多你自己的分析工具。
这是我对这个想法的保留——我将公开承认我对文档数据库的工作知识很薄弱。我假设您希望存储所有这些数据,以便您可以对其执行一些聚合或基于趋势的分析。
如果您使用基于文档的数据库作为源,则每行数据的加载和操作(CRUD 操作)非常简单。非常高效,非常直接,基本上很可爱。
糟糕的是,提取这些数据并将其塞进更适合统计分析的结构(例如柱状数据库或多维数据集)的选项很少(如果有的话)。如果将其加载到基本的关系数据库中,则有许多工具,包括商业工具和开源工具,例如pentaho,它们可以很好地适应 ETL 和分析。
最后,您要记住的是,世界上每家金融公司都有股票分析/自动交易应用程序;它们只是导致美国股市大跌,它们不是玩具。:)
在执行分析合理地超出单个系统容量的情况下,诸如键值或文档数据库之类的简单数据存储也很有用。(或者它需要一台非常大的机器来处理负载。)在这些情况下,使用简单的存储是有意义的,因为无论如何分析都需要批处理。我个人会寻找一种水平扩展的处理方法来提出所需的单位/时间分析。
我会研究使用构建在 Hadoop 上的东西进行并行处理。要么在 Java/C++ 中使用本机框架,要么使用更高级别的抽象:Pig、Wukong、通过流接口的二进制可执行文件等。如果对这条路线感兴趣,亚马逊会提供相当便宜的处理时间和存储。(我没有个人经验,但很多人都这样做并依赖于他们的业务。)