MongoDB: 股票交易数据库的模式设计

Question

我需要将每日股票收盘价以及tick数据存储在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 }
        }, ...
    }
}

对于Tick数据，我可以采取上述方法，每小时一个子文档，包含一组Ticks。

然而，考虑到文档的最大大小仅为16MB，我认为这个限制会很快被达到，尤其是对于Tick数据而言。

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

那么，你会如何设计每日价格和Tick数据的模式？

- Morten

---

你好，请问你最终使用的方案是什么？ - Karthik

我决定使用kdb+。我认为MongoDB不是一个适合储存tick数据的好选择。 - Morten

你能帮我看一下你使用的数据库模式吗？我不会存储整天的数据，只会存储收盘股价。例如，AAPL每天只有一条记录。非常感谢您的回复。 - Karthik

抱歉，我没有进行实现。如果你只是存储每日价格，我认为 { symbol: "AAPL", prices: [100, 101, 102] } 就可以了。 - Morten

Answer 1

我认为你走在了正确的道路上。

• 每个股票符号对应一个文档，这样可以让你很好地概览所有收集到的符号。而且每个文档的大小也相对容易维护。
• 依我之见，如果单个文档接近16MB，那么架构设计就远远不够好。它不容易阅读或维护。你还需要一次性获取大量数据才能从文档中获得任何信息。
• 你提到“每个符号每天一个文档”。在我看来，这听起来是一种合理的数据结构方式。虽然我不熟悉股票交易的tick数据的细节，但我想这会为架构设计奠定良好的基础。你可以按每天/小时拆分数据，轻松地获得给定日期/小时的所有ticks。
• 记住，没有绝对正确的架构设计方案，只要你仔细思考过。(当然有对错之分) ;)

- aludvigsen

---

谢谢。假设我正在监视100个符号，每个符号每天接收大约5000个标记 - 如果我使用每个符号每天一个文档的方法，那么存储在单个文档中是否太多？但是，如果我稍后添加期权数据，则体积将更大。 - Morten

当我不知道你的对象大小时，很难给出肯定或否定的答复。我认为如果你保持在16MB以下的限制范围内，应该是没问题的。但请记住，如果你想与数据进行交互，非常大的文档解析时间会更长。 - aludvigsen