文档数据库是否适合存储大量Stock Tick数据？

Question

我正在考虑使用像mongodb或ravendb这样的数据库来存储大量的股票数据,并想知道与标准关系(如Sql Server)相比这是否可行.

数据实际上不是关系数据,而是几个巨大的表格.我也在想我可以按分钟/小时/天/周/月等来加/最小/最大行数据,以便进行更快的计算.

示例数据:500个符号*60分钟*60秒*300天......(每个记录我们存储:日期,开放,高,低,关闭,交易量,开放 - 所有小数/浮点数)

那你觉得怎么样？

Answer 1

自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）。

TL; DR

与用于存储和查询大量股票报价数据的面向文档的数据库相比，时间序列数据库是更好的选择。

Answer 2

这里的答案取决于范围。

MongoDB 是“输入”数据的好方法，并且查询各个数据块的速度非常快。它也很好，因为它是为了水平扩展而构建的。

然而，您必须记住的是，所有重要的“查询”实际上都是由“批处理作业输出”产生的。

例如，Gilt Groupe 创建了一个名为Hummingbird的系统，用于在其网站上进行实时分析。介绍在这里。它们基本上是根据在很短的时间间隔（15 分钟）内收集的性能数据动态呈现页面。

在他们的例子中，他们有一个简单的循环：将数据发布到 mongo -> 运行 map-reduce -> 将数据推送到网络进行实时优化 -> 冲洗/重复。

老实说，这非常接近您可能想做的事情。但是，这里有一些限制：

另一方面，您将遇到这些 SQL 问题的不同变体。

当然，这里有一些好处：

水平可扩展性。如果您有很多盒子，那么您可以对它们进行分片，并在 Map/Reduce 作业上获得一定程度的线性性能提升（这就是它们的工作原理）。使用 SQL 数据库构建这样一个“集群”的成本和成本要高得多。
速度非常快，与第 1 点一样，您可以水平添加 RAM 以保持速度。

但正如其他人所提到的，您将无法访问 ETL 和其他常见分析工具。您肯定会编写许多自己的分析工具。