MongoDB架構建議

Question

我想挑選MongoDB作爲我的首選數據庫。我需要幫助我的桌子的設計。

應用程序背景 - 分析應用程序，其中聯繫人推送他們自己的事件和相關的自定義數據。聯繫人可以有很多事件。如：接觸這樣做，這樣做等

EVENT_TYPE，custom_data（JSON），epoch_time

如： 事件1：EVENT_TYPE：page_visited，自定義數據：{網址：定價，引薦：谷歌}， CURRENT_TIME 事件2：EVENT_TYPE：video_watched，定製數據：{URL：VIDEO_LINK}，CURRENT_TIME 事件3：EVENT_TYPE：支付，custom_data：{計劃：精簡版，價格：35}

這些事件是自定義，並且被定義由用戶。可伸縮性是一個問題。

這些都是常見的用例：

• 給我，誰是來定價頁在過去7天的用戶列表
• 給我誰看了視頻和付出更多的用戶列表50
• 給我誰訪問過定價用戶觀看視頻的名單，但沒有支付至少20

什麼是設計我的表的最佳方法是什麼？ 在這種情況下使用嵌入式事件是個好主意嗎？

Answer 1

在蒙戈，他們被稱爲集合和不表，因爲數據是不是行/列:)

（1）我會做一個事件收集和用戶收藏

（2）我每個事件都有一個userId文件。 （3）如果你需要實時數據，你需要一個你想要查詢的索引（即不要對整個集合進行掃描）。 （4）如果有些事情只需要報告，我建議製作報告節點（即不同的mongo實例），並使用複製將數據複製到該mongo實例。您可以將其他索引放在該節點上進行報告。這樣，額外的索引和任何昂貴的查詢都不會影響生產性能。

上分片注

如果您的活動集合將會變大 - 你可能需要考慮拆分。也許用戶ID分片。不過，我建議這可能是一個更長期的解決方案，而不是在需要之前深入研究。

有一點需要注意的是，mongo目前（2.6）有一個數據庫級的寫鎖實現。這意味着您一次只能執行1次寫入。它允許許多讀取。這意味着如果你想要一個高寫入系統並且擁有大量用戶，你需要在某個時刻考慮分片。但是，根據我迄今爲止的經驗，具有輔助（和報告節點）的管理1主節點更容易設置。使用該設置，我們目前每秒可以處理大約10,000次操作。

但是，我們遇到了來自系統的用戶高峯的問題。你會想確保你的索引有足夠的內存。 SSD將被推薦。因爲用戶激增可能導致緩存未命中（即索引不在內存中），導致它從硬盤上讀取。

最後一點 - 有很多NoSQL DB，他們都有自己的優點和缺點。我個人發現，高寫入，低讀取和實時分析大量數據並不是mongo的強項。所以這取決於你在做什麼。這聽起來像你還在學習基本面。可能值得閱讀所有可用的類型來爲正確的工作選擇合適的工具。