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：股票價格數據庫的模式設計

回答

相關問題