MongoDB：股票价格数据库的模式设计

我需要在MongoDB中存储每日股票收盘价以及数据点数据。你将如何设计这样的模式？对于每日价格，我希望每个股票代码都有一个文件，例如MongoDB：股票价格数据库的模式设计

{ 
    symbol: "AAPL", 
    quotes: { 
     { 
      date: '2014-01-01', 
      values: { open: 1, high: 1, low: 1, close: 1, volume: 100 } 
     }, 
     { 
      date: '2014-01-02', 
      values: { open: 1, high: 1, low: 1, close: 1, volume: 100 } 
     }, ... 
    } 
}

对于刻度数据我可以做一些像上面这样每小时有一个子文档和一组刻度。

但是，考虑到最大文件大小只有16MB，我相信这个限制会很快达到，特别是对于tick数据。

我知道这种方法http://blog.mongodb.org/post/65517193370/schema-design-for-time-series-data-in-mongodb。这会是一个好方法吗？即每个符号每天一个文件？

那么，您将如何分别设计每日价格和订单数据的模式？

来源

2014-04-21 Morten

嗨，你能告诉我你最终使用的方案吗？ – Karthik

我决定改用kdb +。我不认为MongoDB是刻度数据的好选择。 – Morten

你能帮我解释一下你使用的数据库模式吗？我不会存储整天的数据。我只是存储闭市价格。因此，例如AAPL将只有一天的记录。感谢回复 – Karthik

我认为你是在正确的轨道上。

每个股票代码都有一个文档，可以很好地概括集合中的所有符号。并且每个文档的大小都相当可维护。
在我看来，如果单个文档的接近16MB，模式设计远远不够好。它不易读或可维护。每次需要从文档中获取任何内容时，您还必须获取大量数据。
您提到“每个符号每天一篇文章”。对我来说，这听起来像是一个明智的方式来构建数据。尽管我不熟悉股票中的点滴数据的细节，但我认为这会为模式设计提供良好的基础。您每天都会分割它，并且可以轻松获取给定日/小时的所有蜱虫。
请记住，只要您彻底思考，模式设计就没有绝对的解决方案。（虽然确实有对错的方法）;）

来源

2014-04-21 13:23:20 aludvigsen

谢谢。假设我正在监控100个符号，每个符号每天接收约5000个滴答声 - 假设我每个符号每天使用一个文档，那么这对于存储在单个文档中是否太多了？但是，如果我稍后添加选项数据，则体积会更大。 – Morten

当我不知道物体的大小时，我很难说是或否。我认为如果你保持低于16MB的限制，你会没事的。但请记住，如果您想与数据进行交互，非常大的文档需要更长的时间才能解析。 – aludvigsen

MongoDB：股票价格数据库的模式设计

回答

相关问题