MongoDB聚合性能能力

Question

我正在努力解決有關使用MongoDb處理各種聚合中使用的大量文檔的一些性能問題。

我讀過一個集合具有32TB capcity，具體取決於塊和分片鍵值的大小。

如果我有65,000個客戶，每個客戶每天向我們提供350筆銷售交易，那麼每天最多可創建22,750,000份文檔。當我說一個銷售交易時，我的意思是一個對象，就像一個包含標題和訂單項的發票。我擁有的每份文件平均爲2.60kb。

我還有一些其他數據被這些相同的客戶收到，如帳戶餘額和目錄中的產品。我估計任何時候都有大約1000個產品記錄在活動。

基於上述情況，我每年接近8,392,475,0,00（84億）份文件，總共存儲20,145,450,000 kb（18.76Tb）的數據。

根據MongoDb收集32Tb（34,359,738,368 kb）的容量，我相信它的容量將達到58.63％。

我想了解它將如何執行不同聚合查詢上運行它。我想創建一組分階段管道聚合，這些聚合寫入不同的集合，這些集合用作商業洞察分析的源數據。

在84億份交易文檔中，我的目標是通過一組單獨的服務在不同的集合中創建這些彙總數據，這些服務使用$out輸出，以避免單個結果集的16Mb文檔大小出現任何問題。

我是不是過於雄心勃勃這裏厚望的MongoDB能夠：

1. 商店，一個集合中的大量數據
2. 總輸出刷新數據的結果，以推動業務洞察力在一個單獨的集合通過提供客戶業務的離散方面的服務消費

任何反饋歡迎，我想了解在使用MongoDb的限制，而不是其他技術的數量數據存儲和我們即

在此先感謝

Answer 1

有在MongoDB的大集合怎麼可能（在設置複製或分片集羣）沒有限制。我認爲你在達到最大集合大小後不能將其分解，這是令人困惑的。

MongoDB Docs: Sharding Operational Restrictions

對於數據量你打算擁有它將使意義去從一開始就分片集羣。