關於NoSQL，你必須知道的九件事

本文提到的列表來源於一篇文章，文章標題是關係型數據庫使用者必須知道的一些NoSQL知識。其中總結的九點NoSQL與RDBMS的區別聯繫非常不錯。NoSQLFan爲大家翻譯在此。

原文鏈接：NOSQL DB BASICS FOR THE RDBMS-SAVVY

1. 理解ACID與BASE的區別（ACID是關係型數據庫強一致性的四個要求，而BASE是NoSQL數據庫通常對可用性及一致性的弱要求原則，它們的意思分別是，ACID：atomicity, consistency, isolation, durability;BASE：Basically Available, Soft-state, Eventually Consistent。同時有意思的是ACID在英語裏意爲酸，BASE意思爲鹼）
2. 理解持久化與非持久化的區別。這麼說是因爲有的NoSQL系統是純內存存儲的。
3. 你必須意識到傳統有關係型數據庫與NoSQL系統在數據結構上的本質區別。傳統關係型數據庫通常是基於行的表格型存儲，而NoSQL系統包括了列式存儲（Cassandra）、key/value存儲（Memcached）、文檔型存儲（CouchDB）以及圖結構存儲（Neo4j）
4. 與傳統關係數據庫有統一的SQL語言操作接口不同，NoSQL系統通常有自己特有的API接口。
5. 在架構上，你必須搞清楚，NoSQL系統是被設計用於成百上千臺機器的集羣中的，而非共享型數據庫系統的架構。
6. 在NoSQL系統中，可能你得習慣一下不知道你的數據具體存在何處的情況。
7. 在NoSQL系統中，你最好習慣它的弱一致性。”eventually consistent”(最終一致性)正是BASE原則中的重要一項。比如在Twitter，你在Followers列表中經常會感受到數據的延遲。
8. 在NoSQL系統中，你要理解，很多時候數據並不總是可用的。
9. 你得理解，有的方案是擁有分區容忍性的，有的方案不一定有。

作者：周思遠
鏈接：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/Philosophy
• MongoDB的schema設計：http://www.mongodb.org/display/DOCS/Schema+Design
• MongoDB與SQL查詢的對比：http://www.mongodb.org/display/DOCS/SQL+to+Mongo+Mapping+Chart

最後這個對比說明了，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. 這也是爲什麼我想修改問題描述，把“完全取代”放到副標題，我們比較不同產品的特點，不預測未來，不空談誰好誰壞。