將大集合拆分爲更小的集合？

Question

我有一個可能會非常大的集合。現在我知道MongoDB實際上並沒有問題，但我真的不知道如何設計一個可以輕鬆處理大型數據集的模式。所以我要介紹一下這個問題。

我們正在爲我們的客戶收集大量數據。基本上，當我們收集這些數據時，它表示爲一個三元組，可以說（a，b，c），其中b和c分別是集合B和C的成員。在這個特殊情況下，我們知道B和C集合隨着時間的推移不會增長很多。對於我們目前的客戶，我們正在談論約20萬名會員。然而，A組是隨着時間的推移而不斷增長的組合。目前，我們每個客戶約有2,000,000名會員，但是這將會增長（可能很快）。此外，b-> a和c-> a之間存在1→n的關係。

該數據集的工作量基本上分爲3個用例。收藏將定期更新，其中A將得到最多的寫入，而B和C將得到一些，但不是很多。第二個用例是對B的隨機訪問，然後聚合C中與b中b有關的一些文檔。最後一個用例基本上是將來自A和B的大子集流化以生成一些新數據。

我們面臨的問題是指標越來越大。目前，我們有大約8個小客戶的測試設置，目前總數據集大小約爲15GB，索引運行大約3GB到4GB。這裏的問題是我們的數據集中沒有真正的熱區。它基本上會在所有文檔中均勻分佈負載。

基本上我們已經想出了兩個選擇來做到這一點。我上面描述的那個，所有客戶的所有數據都堆積成一個集合。這意味着我們必須在某個字段中創建索引，將該集合中的文檔鏈接到特定的客戶。

其他選項是將所有b和c放在一起（這些集合相對較小），但將C集合分爲一個，每個客戶一個。我可以想象這最後一個解決方案有點難以管理，但由於我們很少同時訪問多個客戶的數據，所以它可以防止內存問題。 MongoDB將能夠將客戶索引加載到內存中，並從那裏運行。

你對此有何看法？

P.S .:我希望這不是太含糊，如果有什麼不清楚的話，我會進入更多的細節。

Answer 1

這聽起來像一個更大的集合（如果我遵循正確的話），可以合理地放入它自己的數據庫中。我說的是數據庫而不是集合，因爲現在發佈了2.2版本，您希望最小化繁忙數據庫和其他數據庫之間的鎖定爭用，並且最好將單獨的數據庫（2.2引入的數據庫級別鎖定）做到這一點。當然，這是從一個副本集模型來看待這個問題。

此外，索引大小與您的數據大小聽起來有點不成比例 - 您確定它們都是必需的嗎？修剪不需要的索引，組合和使用複合索引可能會顯着減少您在索引增長方面遇到的痛苦（它可能會使更新和插入效率更高）。這確實需要細節，可能屬於另一個問題，或者可能是mongodb用戶組中的一個線程，因此多眼可以查看並提出建議。

如果我們看看它可能引入分片，那麼真正重要的一點是選擇一個分片鍵，以便確保將位置保存在碎片中，以便您經常需要訪問的碎片。這會讓自己更傾向於單個分片集合（保留多個相關分片集合的本地化將非常棘手，除非您以某種方式手動分割和平衡分塊）。分割使您能夠在您的索引達到單個實例限制等時水平擴展，但它將使分片關鍵決策非常重要。

再次，採摘片鍵細節超出了更廣泛的討論，類似於我上面提到的潛在指標審查的範圍。