MongoDB：股票报价数据库的模式设计答案

【问题标题】：MongoDB: Schema design for stock tick databaseMongoDB：股票报价数据库的模式设计
【发布时间】：2014-06-05 13:25:18
【问题描述】：

我需要在 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，我相信很快就会达到限制，尤其是对于刻度数据。

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

那么，您将如何分别设计每日价格和分时数据的架构？

【问题讨论】：

您好，请问您最后使用的方案。
我决定改用 kdb+。我不认为 MongoDB 是刻度数据的好选择。
你能帮我看看你使用的数据库模式吗？我不会存储整天的数据。我将只存储收盘价。因此，例如 AAPL 一天只有一条记录。非常感谢您的回复
抱歉，我没有继续实施。如果您只是存储每日价格，我假设 { symbol: "AAPL", prices: [100, 101, 102] } 可以。

标签： mongodb schema-design stockquotes

【解决方案1】：

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

为每个股票代码准备一份文档可以让您很好地了解集合中的所有代码。而且每个文档都有一个相当可维护的大小。
在我看来，如果您在单个文档上甚至接近 16MB，那么架构设计还远远不够好。它不容易阅读或维护。每次您想要从文档中获取任何内容时，您还必须获取大量数据。
您提到“每天每个符号一个文档”。对我来说，这听起来像是一种合理的数据结构方式。虽然我不熟悉股票报价数据中的细节，但我认为这将为您提供架构设计的良好基础。您可以将其按每天进行拆分，并且可以轻松获取给定日期/小时的所有刻度。
请记住，模式设计没有绝对的解决方案，只要您仔细考虑即可。（肯定有正确/错误的方式）;)

【讨论】：

谢谢。假设我正在监视 100 个符号，并且每个符号每天接收约 5000 个刻度 - 假设我每天使用每个符号一个文档的方法，存储在单个文档中会不会太多？但是，如果我稍后添加选项数据，体积会更大。
当我不知道您的对象的大小时，我很难说是或否。我认为如果你保持低于 16MB 的限制，你会没事的。但请记住，如果您想与数据进行交互，非常大的文档将需要更长的时间来解析。