對於 Web 2.0 實時應用、大數據量，MongoDB 和 memcached + SQL 哪個性能更好、在國內比較容易僱工程師？

01-19

如果對緩存和架構理解很深刻，能夠充分發揮緩存優勢的話，用memcached+SQL自然性能更好，穩定性更高，而且這是成熟方案，沒有風險。

用mongoDB的最大好處並不是性能，而是schema free，適合從小團隊初創項目開始成長的應用，隨時隨地可以調整存儲的數據結構，而非一上來就是超大訪問量的應用。

從性能上考量的話，其實用mongoDB可以處理的，現在採用MySQL+HandlerSocket一樣可以處理，甚至我更傾向於後者，因為更成熟，監控工具，備份方案都是現成的，mongoDB還是有一些惱人的bug的。

我想主要取決於你做什麼類型的項目：如果你對自己要做的產品形態已經非常明確，未來預期產品形態不會劇烈頻繁的調整，而是用戶訪問量會持續增長的話，應該採用MySQL＋緩存；如果你對自己要做的產品形態尚在探索階段，未來產品形態會劇烈頻繁的改動，那麼mongoDB的schema free特性就特別適合你，讓你來回改資料庫結構，沒有任何pain。

工程師都不難僱傭，但是對這兩種架構有深入了解並且能夠靈活運用的，你很難找到。

memcached 挺好的，工程師容易招；

個人認為，除非你的數據壓力達到了一個BT的級別，否則 NO SQL方案需要慎用。這點淘寶的余鋒非常有發言權，他們把mysql的性能發揮到了極致。

很多時候，我們對mysql的性能會有誤解，因為我們很少有人能把他的性能發揮到極致。

HandlerSocket據說能夠達到75W QPS，這個確實非常誘人。mongdb目前分散式還不夠成熟，它的document的存儲，查詢還是挺方便的。

挺久前的問題了～隨便說幾句吧。

用Mongo做過幾個項目，MongoDB並沒有想像中網上傳的那麼優秀，而且他的使用成本不低。題主說的大數據而且實時，我姑且可以認為數據量不少於1T，

這種情況下，

× 索引大小估計會達到幾十個G（看你索引建立的方式）。這幾十個G需要全部處於內存中。

× 如果你的數據訪問比較隨機，沒有什麼熱數據的概念，那這塊數據也全部都是在內存中的。

你可以預估下需要的內存大小。而且MongoDB沒有自己的內存管理機制，全部由系統自己管理。這會導致內存的難以控制。

在預建立索引的情況，MongoDB的插入性能也比較糟糕（同樣一張表，三個索引，我覺得甚至比不上Mysql）。

另外一點就是上面有人回答過得 scheme-free，這個東西帶來的好處真沒有想像的那麼大。比如改數據結構，我也沒看出來有任何pain。比方說Mysql資料庫，我加個欄位跟MongoDB的scheme-free多一個屬性有多出很多的工作嗎(5分鐘的工作量)? 另外MongoDB的嵌套Document查詢以及group by這種查詢，一直支持的不好(最近幾個版本有改善)。

另外舉一個例子，去年我參與的一個項目使用MongoDB，最開始使用PyMongo作為Client，鑒於Python語言的動態性，按理說跟PyMongo配合是如魚得水，但是經歷過一番掙扎之後，還是換到了MongoEngine（一個ORM-Client）。

總之：MongoDB你可以拿來玩玩，實際要用來處理大數據，個人不推薦。

Mysql的話題，GitHub上搜一下，有支持Cache的（Memcache，Redis)實現。鑒於Mysql我只處於熟悉階段就不多做回答誤導人了。

End

考慮到mongodb的一些缺點，建議用tokumx代替mongodb.

tokumx是mongodb兼容的資料庫實現，針對mongodb的弱點提供了事務和數據壓縮的功能，使高可靠性和性能都得到提升。已有mongodb訪問代碼也不用改變。唯一的問題是，如果使用事務，一些語言比如nodejs的mongodb driver可能工作不正常。

MongoDB 之於 Mysql，類似於Rails 之於 J2EE。 schema free 的最大好處就是快速開發，快速驗證想法。在用戶上規模之前考慮性能是多餘的不必要的。另外MongoDB另一個最大的好處是 Geo Indexing，我個人覺得這是4sq 和 path 選用MongoDB的一個很大的原因，我建議做LBS相關的應用都應該考慮MongoDB。

從穩定性來說， MongoDB 1.6 以後已經趨於穩定，可以放心的在生產環境上使用。性能上MongoDB也很不錯，可以找相關的benchmark 測試看看。監控和備份上稍微差點，在做分散式的時候要稍微注意，雖然有auto sharding。

MongoDB 的入門門檻不高，經驗豐富的DBA很快就可以操作。

MongoDB相對mysql來說，技術不夠成熟而且分散式會對數據可靠性引入不少不穩定因素，如果不是數據量達到一定程度，真不建議使用。

Mysql + Memcached 年頭很長了，用的人最多，沒什麼好說的，有些問題就是memcached不是持久化的，需要特殊處理，另外可能存在不一致問題。

個人比較推薦MySQL + HandlerSocket （或者Percona Server），簡化第二種方案，又可以提供較好性能，目前飛信已經使用，新浪微博和淘寶很多公司都有人在研究。

對於用戶交互的實時數據MongoDB更有優勢，靈活的非結構化設計能解決數據嵌套帶來的瓶頸，也能適應數據結構的快速升級，大量社交遊戲運營商都使用了MongoDB。memcache,percona 等Mysql改良方案還是比較適合在線交易，結帳類的應用。hanler-socket很新穎但是編程語言介面方面似乎還不成熟，也許再過半年會有更好的表現。

MySQL 5.6.2引入了memcached,如果想嘗鮮,可以一試

這個問題完全不用糾結。MongoDB的性能和mc完全不是一個數量級的。如果是超大規模的實時應用，把內存當硬碟使是必然的，redis或者mcdb這種內存+持久化的方式才適合。另，熟悉mc的人比熟悉mongodb的人多太多...

memcached+SQL 模式成熟，國內有很多實現案例，人也好招些。mongodb還在發展過程中，代碼升級多，可靠性差點，需要有對mongodb代碼熟悉的程序員增加可靠度。

性能上估計是前者更好

我現在也在使用mongodb，用的2.4.9版本，感覺在查詢方面支持還是比較好，能夠滿足我的業務需要。

推薦你用Redis吧

MongoDB+redis 或者 MySQL+Memcached 比較好的組合，邏輯簡單的就用NOSQL

如果能找到穩定的技術人員，並且精通mongdb建議用mongdb+redis。否則還是用mysql，至少人走了，可以很容易找個人接上。

看完上面的大蝦說的我也說下我的想法

NOSQL(mongdb等)+緩存（redis 等）是網站的王道

我從2011年就開始關注mongdb到現在

做過一個類似於微博的項目用的就是mvc+redis+mongdb

但是我有一個後台這個後台用的是sql資料庫緩存memcached

我感覺關係簡單邏輯簡單的就用NOSQL

相反的最好用SQL

我個人現在也在糾結於使用mongdb+redis還是用sql+cache

這個只是我自己的一點想法希望對你有幫助