一個大型的SNS網站，是否適合資料庫全部用mongodb來做，為什麼？

---

別鬧。

---

要說穩定性及實踐經驗，MySQL是不能丟的，再進一步，用Oracle。

MongoDB可用在非關鍵業務上，做些嘗試、試驗。

---

不建議都使用mongodb。

kv資料庫和關係型資料庫各有各的優劣，在項目裡面可以根據不同的需求和場景來搭配使用。

你可以先用mongodb存放訪問頻繁、並且可以容忍數據不準確的部分，用MySQL存放重要的、不能容忍數據丟失的部分。積累一段時間的經驗後，再考慮是否完全使用mongodb，而MySQL只用來做備份用途。

---

1.MongoDB是不是適合做某事，需要你自己去弄懂它的定位與特性。

2.要弄懂這些，需要去它的官網通讀文檔以及簡介。

3.SNS里存在一些業務適合MongoDB，但你們會不會涉及這些業務，那得問你們自己。

4.MongoDB以犧牲功能來贏取性能，因此SNS里需要其他功能正常的資料庫配合。

5.帖子里居然有很多人直接評論說MongoDB不適合SNS，呵呵，太可愛了，這些人同時了解MongoDB與SNS業務嗎？

---

你看一下mongodb自己官方的介紹，它提到如果你的數據要經常join，那不建議用mongodb，在分散式數據上很難做到。當然，你如果修改業務流程，把join給消滅掉，那肯定還是能用的。

---

永遠不要使用自己不熟悉的技術。

沒有任何道理你熟悉的MySQL做出來的東西會比半吊子的MongoDB差。

---

在用關係型資料庫的時候我就不用join了。

---

when you have a hammer ,ererything like nails 。建議最好使用業界比較成熟的方案。 例如lamp

---

我們現在的SNS遊戲就採用的mongodb,主要看重的是它的key-value結構的效率。

設計數據結構的時候可以避免使用關聯的，往key-value結構上設計，對於資源性質的內容我們都放在自定義內存中作為cache,避免從數據表到資源表去join.

---

mysql mongo 兩者可以混合使用

兩者之間不是排斥獨立關係，應該可以相輔相成，

最近就思考這個相輔相成的問題，

既關聯又獨立，混合使用效果應該不錯。

---

曾經這麼做過，不過網站沒有上線，不是因為技術的原因，而是因為產品

---

看業務需求

---

mongodb不進行join。小數據直接sub-document

---

我的理解是各自用在合適的地方吧，很多時候是相互配合使用的

---

前期的話建議用熟悉的mysql

mongo的運帷成本較大、且在用戶請求不大的情況下，mysql完全夠用了，mongo的硬體要求和成本也較mysql大。

---

網站大了，業務複雜了，都會讓Mongo死的很慘

初期基礎架構上還是穩妥些好

---

mongodb會節約很多成本吧。

不過大型的SNS確實不適合。畢竟不熟悉的話，遇到問題怎麼辦

---

mongodb不需要join

---

所謂no sql，實際就是你人肉把以前sql做的事情自己做一遍，所以用不用的區別就在於工作量

---

推薦閱讀：