作者：周思遠
連結：https://www.zhihu.com/question/20059632/answer/14981332
來源：知乎

When to use MongoDB or other document oriented database systems?
http://stackoverflow.com/questions/1476295/when-to-use-mongodb-or-other-document-oriented-database-systems
其中引用了 NoSQL: If Only It Was That Easy http://bjclark.me/2009/08/nosql-if-only-it-was-that-easy/

這一篇文章和一組問答很好地回答了什麼時候用NoSQL的問題。下面引用加評論。

I think Mongo might be the closest thing to a RDBMS replacement that I’ve seen so far. It won’t work for all data sets and access patterns, but it’s built for your typical CRUD stuff. Storing what is essentially a huge hash, and being able to select on any of those keys, is what most people use a relational database for. If your DB is 3NF and you don’t do any joins (you’re just selecting a bunch of tables and putting all the objects together, AKA what most people do in a web app), MongoDB would probably kick ass for you.

上文說如果資料集比較簡單，沒有Join，MongoDB會非常棒。沒錯。但這不意味著如果資料複雜就不行。相反，這時需要重新設計資料schema (模式、架構、結構)，把相關的內容放到一個document裡，這是與關係型資料庫追求的三正規化最不一樣的地方。比如一篇文章的評論不算太多，最多幾百個，就可以把評論放到陣列(array)裡，作為文章這一document的一部分。是的，陣列(array)是支援的，查詢陣列元素也非常自然。這樣的好處是在讀取文章這一document時，一個頁面上所有需要的資料都有了，讀硬碟（記憶體）的次數少了，自然就快，相比之下，關係型資料庫Join就麻煩很多了。這個例子裡資料的access pattern決定了資料schema。
相關文件（MongoDB的官方文件真是個好地方，尤其是他們最近在擴充文件團隊）： 最後這個對比說明了，MongoDB希望在大多數應用中做為關係型資料庫的替代品，提供這些優點：

http://www.mongodb.org/display/DOCS/Introduction

• Document-oriented，用文件來組織資料，不需要嚴格的結構。
  
• High performance，高效能
  
• High availability，高可用，比如複製 (Replica set)
  
• Easy scalability，易擴充套件，比如Sharding
  
• Rich query language，富查詢

這些特點都是以關係型資料庫當假想敵來說的，你沒有的我有，你有的我也可以有。實際上，10gen, MongoDB背後的公司，把Oracle作為真正的競爭對手，他們要從關係型資料庫的碗裡搶飯吃。

MongoDB這樣的NoSQL會火的根本原因，是許多使用者不必需關係型資料庫的特性，有時候還帶來了限制。我從以上特性中選幾個談談。

1. Document-oriented.《MongoDB in Action》中舉了擴充套件或自定義屬性的例子。比如電子商務網站的產品除了預設的價格，id等，因具體產品不同有許多自定義屬性，產品這個表應該怎麼設計？就算一類產品大致相似，也有獨特的屬性，比如LCD和LED顯示器的產品特性就不一樣。這個問題有一些解決方案，比如 Entity-attribute-value Model http://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model 但是這些方案都很複雜，這時，schemaless的優點就顯現出來了。
2. Easy scalability. 當資料規模大到一個機器裝不下了，或者一臺機器資料讀寫負載太高，需要使用cluster的時候，關係型資料庫的partitioning, sharding要複雜的手工處理。MongoDB可以自動按照使用者給定的sharding key把資料分片，並且動態地平衡各個機器的資料量。
   
3. Rich query language. 這是關係型資料庫擅長的地方，也是使用者所希望的，而有的key-value資料庫只把value當作一個binary blob，比如Voldemort，只能通過key查詢。簡言之，不通用。MongoDB內部也是按key-value存的，但是支援各種查詢，並且可以建各種索引，提供了易用與高效能。
   

技術上，MongoDB用到的都是在學術上很成熟的，但是針對使用者需要，它把不同的技術組合起來，建立了易用的產品，構成了關係型資料庫強有力的挑戰。

當然，MongoDB不是什麼功能都有，往往這也是其他NoSQL產品做不好的。最明顯的就是事務現在沒有被直接支援，其他知友也提到了。在MongoDB不適合幹什麼上，我還得多做做功課，再來補充。

開頭說到的文章中還提到了幾個NoSQL產品的對比：

What am I going to build my next app on? Probably Postgres. Will I use NoSQL? Maybe. I might also use Hadoop and Hive. I might keep everything in flat files. Maybe I’ll start hacking on Maglev. I’ll use whatever is best for the job. If I need reporting, I won’t be using any NoSQL. If I need caching, I’ll probably use Tokyo Tyrant. If I need ACIDity, I won’t use NoSQL. If I need a ton of counters, I’ll use Redis. If I need transactions, I’ll use Postgres. If I have a ton of a single type of documents, I’ll probably use Mongo. If I need to write 1 billion objects a day, I’d probably use Voldemort. If I need full text search, I’d probably use Solr. If I need full text search of volatile data, I’d probably use Sphinx.

唯一的遺憾是這一文章寫得太早（2009），此後MongoDB加入了不少很棒的新功能。比如文章提出的擴充套件性問題，2010年引入的Sharding提供了自動的擴充套件功能，http://www.mongodb.org/display/DOCS/Sharding+Introduction，這一功能之後又不斷被完善，可以算是一個對關係型資料庫的殺手級feature了。
這些應廣大使用者要求加入的feature使得MongoDB倍受歡迎。一個例子就是MongoDB成為線上招聘網站http://Indeed.com上繼HTML5之後第二大增長最快的關鍵詞。http://www.indeed.com/jobtrends/Mongodb.html 這個說明許多startup的應用中可以用MongoDB代替關係型資料庫。這是市場對這個問題的回答。

其實開頭文章中我最喜歡的一句話是

NoSQL is a great tool, but it’s certainly not going to be your competitive edge, it’s not going to make your app hot, and most of all, your users won’t give a shit about any of this.

做為一個工程師，最重要的是務實地去build something. 這也是為什麼我想修改問題描述，把“完全取代”放到副標題，我們比較不同產品的特點，不預測未來，不空談誰好誰壞。