我正在開發一個Meteor網絡應用，使用Mongo，它將在雲上運行。每個用戶必須屬於公司。 每個公司只能訪問它自己的數據。 每個用戶都可以訪問自己的數據以及與同一家公司的其他用戶共享的一些數據。 想象一下1.000公司和每個公司100個用戶，如果我爲整個應用程序使用1個Mongodb數據庫，性能和安全性可能會很差。Mongodb多公司網絡應用策略
如此，因爲蒙戈是「無模式和數據庫少」我想我可以定義1.000 DBS，可以說db_0001，db_0002，...具有相同名稱的集合，可以說任務， 消息，...，因此該應用程序可以高效且更安全（每個公司的相同代碼和數據隔離）。
此外，在託管端（比如說說數字海洋），我認爲它更容易分配dbs，如果已經被霧化。
這是一個很好的方法嗎？或者我不應該擔心它，並讓託管做這項工作？
任何想法都很好。
你目前只在看硬幣的一面。這是很好的開始。
想想你將如何顯示該數據以及它轉化爲什麼查詢。對所有潛在的查詢進行徹底的盡職調查。例如，用戶/ getbyid被多久調用一次，以及多久你需要向用戶顯示他們的信息以及他們與其他用戶的關係。除了用戶信息之外還需要其他什麼元數據，您是否需要執行連接才能獲取這些數據？還是將其作爲嵌入式文檔存儲？你最想搜索和排序的領域是什麼？哪些類型的數據寫得很重，讀取的是什麼？
現在讓我們回到您的數據庫着色方法。能夠在這方面提前思考，而不是稍後重寫組件，這太好了。數據量/存儲不擔心我在這裏。在應用程序中將使用多少個併發用戶，以及什麼是主要用例應該是首先考慮考慮規模的地方。
此外，您需要了解業務和項目增長的性質。這是否像Instragram類型的高增長？或者它更可預測。一個大型的Mongo集羣可以處理數以千計的併發讀/寫請求（假設您的設計和查詢已經過優化），以免打擾我。如果你想保持它的靈活性，MongoDB有一個分片機制，你可以在一個密鑰上分割，並且把所有的花哨的東西都照顧到你。
如果您啓用了從輔助數據庫讀取的數據，並且您擁有大量業務關鍵型應用程序，則需要小心，因爲您可能會讀取過期結果，因此，MongoDB具有最終一致性（查找MongoDB CAP定理）。
就託管而言，DO很好，但總是在另一個區域備份以保持地理冗餘度，以防萬一某個區域出現故障（您好AWS！），您有事可循。
祝您的項目順利！
非常感謝卡拉根！以下是我將用於設計的一個簡短列表：1）在每個集合中包含一個company_id，並在該字段中包含一個索引，2）用於很多屬性的冗餘（即user_id user_name + user_url_pic allways存儲），3 ）加入具有不同含義或數量的集合（即項目和會議），4）每個字段的數據字典（避免2個字段具有相同的名稱和不同的含義），5）如果可能的話， '，preffer'獅子'，'狗'，...）。如果沒有進一步的評論，我會發布這個答案。 –
Mongo仍然會在100k用戶表現，1000 db的實例聽起來像是過度殺傷，而且對我來說不是很靈活。 – challett
這不是你如何擴展Mongodb;你會爲自己創造一個巨大的毛球。首先閱讀https://www.mongodb.com/mongodb-scale及其鏈接。有很多關於縮放Mongo的在線案例研究。 –