文档数据库是否适合存储大量的股票行情数据？

Question

我在考虑使用mongodb或ravendb这样的数据库来存储大量的股票行情数据，并想知道与Sql Server等标准关系相比，这是否可行。

数据将不是真正的关系型数据，而是几个巨大的表。我还在想，我可以按分钟/小时/天/周/月等对数据的/最小/最大行进行求和，以获得更快的计算速度。

示例数据: 500个符号* 60分钟*60秒* 300天...(我们存储的每个记录: date，open，high，low，close，volume，openint - all decimal/float)

你们觉得怎么样？

Answer 1

这里的答案将取决于范围。

MongoDB是获取数据的一种很好的方式，而且它在查询单个片段时速度非常快。它也很好，因为它被构建为水平扩展。

但是，您必须记住的是，所有重要的“查询”实际上都是“批处理作业输出”的结果。

例如，Gilt Groupe创建了一个名为Hummingbird的系统，用于在其网站上进行实时分析。Presentation here。它们基本上是根据收集的性能数据以严格的时间间隔(15分钟)动态呈现页面。

在他们的例子中，他们有一个简单的循环: post数据到mongo -> run map-reduce ->推送数据到webs进行实时优化->清洗/重复。

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

1. Map-reduce对很多人来说都是新鲜事。如果你熟悉SQL，你将不得不接受map-reduce的学习曲线。
2. 如果你输入了大量的数据，那么在这些机器上你的map-reduce将会变得更慢。如果响应时间很重要，您可能会想看看从属/副本对。

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

当然，这里也有一些好处：

1. 水平可扩展性。如果你有很多盒子，那么你可以对它们进行分片，并在Map/Reduce作业上获得一定程度的线性性能提升(这就是它们的工作方式)。使用SQL数据库构建这样的“集群”的成本要高得多，而且expensive.
2. Really的速度也很快，正如第1点所示，您可以水平添加内存以保持速度。

然而，正如其他人所提到的，你将失去对ETL和其他常见分析工具的访问。你肯定要编写很多你自己的分析工具。

Answer 2

自从2010年提出这个问题以来，一些数据库引擎已经发布或开发了专门处理时间序列的功能，例如股票节拍数据：

• InfluxDB - see my other answer
• Cassandra

对于MongoDB或其他面向文档的数据库，如果您的目标是性能，建议contort your schema在以秒为关键字的对象(或分钟对象，每分钟是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 3

这是我对这个想法的保留意见--我要坦率地承认，我对文档数据库的应用知识很薄弱。我假设您希望存储所有这些数据，以便可以对其执行一些聚合或基于趋势的分析。

如果使用基于文档的数据库作为数据源，则加载和操作每行数据(CRUD操作)非常简单。非常高效，非常直截了当，基本上很可爱。

糟糕的是，提取这些数据并将其塞进更适合统计分析的结构中的选项很少，如果有的话。如果您将它加载到一个基本的关系数据库中，就会有一系列的工具，包括商业的和开源的，比如pentaho，它们可以很好地适应ETL和分析。

但最终，您要记住的是，世界上每家金融公司都有一个股票分析/自动交易应用程序；它们只是引起了美国股市的大跌，它们不是玩具。:)