易於縮放mongodb vs mysql

Question

我正在創建一個Grails應用程序，它是移動應用程序的後端。它目前部署在亞馬遜EC2上。它將數據保存到mysql數據庫。一個當前指向數據庫的實例。我打算在負載均衡器後面部署多個應用程序實例，並最終將讀取請求發送到數據庫的從屬實例。我們計劃在未來幾個月內發佈，並擁有數千用戶的測試版組。它比寫更多地閱讀密集。

我們研究過使用mongodb代替sql，並將其視爲一個很好的解決方案。

由於它具有自動分片等功能，縮放mongodb會不會有很多縮放mysql（或mongodb）的經驗。 （從兩個都做過的人中尋找想法）我認爲現在切換到mongodb會更容易，而不是處於「製作」階段並且不得不遷移。

想法？

Answer 1

MongoDB中有 「尺度」 的兩個版本：

1. 讀通過replica sets縮放。
2. 書寫縮放通過sharding。

他們不是銀子彈，但他們都很容易設置。副本集具有自動故障切換功能，這在使用EC2時非常重要（它們只有隨機失敗節點的良好歷史記錄）。當您需要寫入擴展時，MongoDB將documented processes for upgrading副本設置爲一系列分片副本集。

不幸的限制是（最後我檢查），像scalr這樣的東西並不真的支持自動縮放。所以你必須推出自己的解決方案來添加和刪除集合中的節點。

有一些重要事項：

1. 磁盤IO性能是在雲粗略。良好的性能是關於可以解決問題的RAM數量。
2. 如果您使用副本集進行讀取，請確保您的驅動程序/數據包裝器能夠處理讀取的分佈。就像MySQL目前它不是「免費」的，你需要決定「寫還是讀」。
3. 64位機器。 MongoDB真的想在64位硬件上運行。這是一種成本負擔，因爲你可能需要增加4GB的機器而不是2GB的機器（我不認爲這是一個很大的限制，但我也知道成爲一個創業公司的感覺）。
4. MongoDB仍然是新技術。這些清單非常活躍，人們正在將它用於非常大型的數據集。但是這仍然是一個新產品，你必須準備好從命令行工作並解析文檔並提出問題。

會是容易擴展的MongoDB

在某種程度上比例將是一個「硬」的問題。 MongoDB做得很好的是提供一種真正通過複製橫向擴展大量盒子的方法。根據我的經驗，MySQL確實在兩個盒子左右寫入。您可以輕鬆配置聯合主人，但在此之後，您必須開始分析各種分區，並且基本上失去了進行聯接的能力。

我想會比較容易切換到現在的MongoDB，而不是在「生產」

它可能會的。

想法？

從小開始。獲取一件作品，看看你是否喜歡它的工作原理。如果您有權訪問EC2帳戶，那麼可以輕鬆啓動幾臺機器並進行遊戲。 MongoDB不是萬能的，但它對很多現代Web問題都非常有效。只需要測量你需要加入多少:)