MongoDB縮放問題（索引是否影響'獨特'性能）？

我正在使用Mongo來一天一天地存儲一組大約40個股權的所有「嘀嗒」。這些刻度包含交易信息（包含價格和交易量的文件）和賬簿信息（包含賣出買入建議的更復雜的文件）。大小順序是大約5K次交易+ 20K本書*每天40股權益。文檔按照每個符號（權益名稱）的插入日期，時間日期進行索引。經過一週的收集，我的一個查詢不再擴展：查找不同的日期需要很長時間。所以我決定有一個特殊的文件只是說有一個「收集」的某一天，這是一個正確的方法？此外，作爲一個單獨的小文件收集東西是正確的，還是更好地收集權益文件上的剔號？MongoDB縮放問題（索引是否影響'獨特'性能）？

謝謝大家！

BTW這個問題是這樣的一個結果是：Using mongodb for store intraday equity data

增加： 即使我明確地說，（在控制檯）

db.books.ensureIndex({dateTag:1}) 
db.books.distinct("dateTag")

慢慢回覆。所以也許更好的問題是：索引是否會影響distinct的性能？

加法升級到1.8.2後行爲是一樣的。

來源

2011-05-26 Felice Pollano

是什麼MongoDB版本？ – 2011-05-26 09:10:01

@Sentinel 1.6.5 – 2011-05-26 09:11:26

不影響指數的不同表現？

確實，但沒有「解釋計劃」，因此只能通過文檔/代碼進行確認。

文檔被索引，以每符號（股權名字）插入的日期，傳播時間間隔一天

我不是你有多少指標有100％的清楚，你擁有什麼類型的內存佔用這裏。只有索引並不一定意味着它會非常快。如果該索引不在內存中，那麼最終會轉到磁盤並放慢查詢速度。

如果你在此查詢儘管指數看到性能下降我會檢查兩件事情：

磁盤活動（在查詢期間）相對於內存
數據大小

但是，保留「存儲天數」列表可能會更容易。即使使用索引，這個不同的查詢可能會變得更糟。所以它永遠不會像簡單列出日子那麼快。

來源

2011-05-27 17:19:41

最終我使用了存儲文檔的日子。無論如何，數據庫活動無論如何都是很高的，因爲我在查詢新數據時正在進行查詢。無論如何，正如您猜測存儲日期解決了問題一樣。 – 2011-05-28 07:54:24

我不認爲你的「某一天的收集」方法會奏效，因爲你會遇到MongoDb每個數據庫24,000個名稱空間的限制。將刻度存儲在文檔的數組屬性中可能會使執行某些類型的查詢更加困難（實際取決於您需要在刻度上運行哪種類型的報告）。

您確定您的索引適用於您在有問題的查詢中使用的屬性嗎？作爲最後的手段，你可以嘗試分片，但我懷疑這是必要的。

來源

2011-05-26 07:55:54

集合實際上只有兩個：交易和書籍。他們都包含很多文件。我應該擔心命名空間嗎？不再縮放的查詢是爲字段日期選擇書籍集合中的不同字符，即使它被編入索引。 – 2011-05-26 08:01:33

如果您要爲貿易數據的每一天使用單獨的集合，您只需要擔心命名空間限制。您是否檢查該索引是否實際用於該查詢？如果您不知道我建議閱讀http://www.mongodb.org/display/DOCS/Optimization#Optimization-Explain。 – 2011-05-26 08:07:23

+ 1，Tnx，我用1.8.2更新了 – 2011-05-26 08:46:43

http://www.mongodb.org/display/DOCS/Aggregation#Aggregation-Distinct

明確指出，不同的（）可以使用索引開始的MongoDB 1.7.3

來源

2011-05-26 10:25:11

這個問題，一個星期的數據查詢需要3秒。它比1.6.x更快，但它似乎並不適合我... – 2011-05-26 10:54:36

MongoDB縮放問題（索引是否影響'獨特'性能）？

回答

相關問題