2012-12-18 165 views
13

我正在設計一個系統與MongoDb(64位版本)來處理大量的用戶(大約100,000),並且每個用戶將有大量的數據(大約100萬條記錄)。MongoDb數據庫與集合

什麼是設計的最佳策略?

  1. 轉儲單集

  2. 所有記錄的集合爲每個用戶

  3. 爲每一個用戶的數據庫。

非常感謝,

+1

肯定不是最後2 –

+0

從數據庫架構角度來看,我會建議使用一個單一的集合,但我不知道他們是否還擴展這麼好,當你有上百*千億*在他們的記錄。 – Philipp

回答

12

因此,您正在尋找1000億個記錄(100萬條記錄* 100,000個用戶)的地區。

處理大量數據的首選方法是創建一個分割的集羣,將數據分散到多個服務器上,這些服務器通過mongo客戶端呈現爲單個邏輯單元。

因此,您的問題的答案是將所有記錄放入單個分片集合中。

集羣所需的分片數量和配置數量與數據大小和其他因素(如讀取和寫入的數量和分佈)有關。這些問題的答案可能非常針對你的獨特情況,所以我不會試圖猜測它們。

我可能會首先決定有多少分片可供您在多臺機器的集羣上設置和測試系統。根據其性能,您可以決定在羣集中是否需要更多或更少的碎片

+3

雖然在這種情況下分片架構肯定是相關的,但是您的文章沒有解決OP的問題,即關於是使用一個集合,多個集合還是多個數據庫。 – Philipp

+3

是啊,備選方案2和3是如此直覺對我說,我忘了,清楚,你應該把它變成一個單一的收集和分片 – chrisbunney

+1

@chrisbunney什麼是對使用的數據庫或集合」模式的2個便士每個用戶「只是爲了安全和簡化訪問控制管理的唯一目的? – kommradHomer

3

關於每個用戶的集合:

使用默認配置,MongoDB是限於12K集合。您可以通過--nssize增加這個尺寸,但它不是無限的。 而且你必須計入這個12k的索引。 (檢查mongo文檔中的「命名空間」概念)。

關於爲每個用戶數據庫:

換一個型號上來看,這是非常奇怪的。 對於技術而言,mongo沒有限制,但是您可能對文件描述符有限制(限制您的操作系統/設置)。

所以@Rohit說,最後兩個不好。也許你應該更多地解釋你的情況。 也許你可以將用戶剪切成不同的集合(例如:每個名字的首字母等等,或者公司的每個服務......)。 並且當然使用分片

編輯:也許MongoDb不是您的用例的最佳數據庫。

5

因此,您正在爲100K用戶尋找100,000,000個詳細記錄?

很多人似乎有什麼不明白的是,MongoDB是善於水平縮放。水平縮放通常被歸類爲跨越大型集羣中許多(許多)服務器的巨大單個數據集合。

因此,如果您對一般數據使用單個集合(即一個集合稱爲user,另一個集合稱爲detail),那麼您已經適合MongoDB的核心目的和構建。

MongoDB中,如前所述,通過別人是不是在許多藏品垂直縮放那麼好。它有一個nssize的限制開始,即使12K初始集合是估計由於索引大小,您可以在您的數據庫只有5K集合。

所以每個用戶的集合是不可行的。它將使用MongoDB來對付其核心原則。

有每個用戶數據庫涉及到同樣的問題,也許更多,具有每個用戶的單一集合。

我從來沒有遇到過某個人無法將MongoDB擴展到數十億甚至接近數十億(甚至更高)的優化設置,但是,我不明白爲什麼它不能;畢竟Facebook能夠使MySQL擴展到每個用戶數十億用戶(跨越32K +分片),並且這兩個數據庫之間的分割概念相似。

所以這樣做的理論和可能性就在那裏。這完全取決於選擇正確的模式和分片概念和關鍵(以及服務器和網絡等等等)。

如果你目睹了問題,你可以去拆分歸檔集合或從主集合中刪除項目,但我認爲這太過分了,而你想確保MongoDB知道你的大數據集的每個部分是在任何給定的時間點在主數據庫上,並確保這些數據總是很熱,這樣一來,不會執行全局和分散式操作的查詢應該非常快。

相關問題