一、NoSQL的誕生原因

隨著互聯(lián)網(wǎng)快速發(fā)展，各種類型的應用層出不窮，所以導致在這個云計算的時代，對技術提出了更多的需求，主要體現(xiàn)在下面這四個方面：

1. 低延遲的讀寫速度：應用快速地反應能極大地提升用戶的滿意度;

原因：當數(shù)據(jù)量達到一定規(guī)模時，由于關系型數(shù)據(jù)庫的系統(tǒng)邏輯非常復雜，使得其非常容易發(fā)生死鎖等的并發(fā)問題，所以導致其讀寫速度下滑非常嚴重;

2. 支撐海量的數(shù)據(jù)和流量：對于搜索這樣大型應用而言，需要利用PB級別的數(shù)據(jù)和能應對百萬級的流量;

原因：有限的支撐容量：現(xiàn)有關系型解決方案還無法支撐Google這樣海量的數(shù)據(jù)存儲

3. 大規(guī)模集群的管理：系統(tǒng)管理員希望分布式應用能更簡單的部署和管理;

原因：由于存在類似Join這樣多表查詢機制，使得數(shù)據(jù)庫在擴展方面很艱難;

4. 龐大運營成本的考量：IT經(jīng)理們希望在硬件成本、軟件成本和人力成本能夠有大幅度地降低;

原因：企業(yè)級數(shù)據(jù)庫的License價格很驚人，并且隨著系統(tǒng)的規(guī)模，而不斷上升;

業(yè)界為了解決上面提到的幾個需求，推出了多款新類型的數(shù)據(jù)庫，并且由于它們在設計上和傳統(tǒng)的NoSQL數(shù)據(jù)庫相比有很大的不同，所以被統(tǒng)稱為 “NoSQL”系列數(shù)據(jù)庫?？偟膩碚f，在設計上，它們非常關注對數(shù)據(jù)高并發(fā)地讀寫和對海量數(shù)據(jù)的存儲等，與關系型數(shù)據(jù)庫相比，它們在架構和數(shù)據(jù)模型方量面 做了“減法”，而在擴展和并發(fā)等方面做了“加法”?，F(xiàn)在主流的NoSQL數(shù)據(jù)庫有BigTable、HBase、Cassandra、SimpleDB、CouchDB、MongoDB和Redis等。

二、為何要使用NoSQL數(shù)據(jù)庫?

1. NoSQL具有靈活的數(shù)據(jù)模型，可以處理非結構化/半結構化的大數(shù)據(jù)

現(xiàn)在，我們可以通過Facebook、D&B等第三方輕松獲得與訪問數(shù)據(jù)，如個人用戶信息、地理位置數(shù)據(jù)、社交圖譜、用戶產(chǎn)生的內(nèi)容、機器日志數(shù) 據(jù)以及傳感器生成的數(shù)據(jù)等。對這些數(shù)據(jù)的使用正在快速改變著通信、購物、廣告、娛樂以及關系管理的特質(zhì)。沒有使用這些數(shù)據(jù)的應用很快就會被用戶所遺忘。開 發(fā)者希望使用非常靈活的數(shù)據(jù)庫，能夠輕松容納新的數(shù)據(jù)類型，并且不會被第三方數(shù)據(jù)提供商內(nèi)容結構的變化所累。很多新數(shù)據(jù)都是非結構化或是半結構化的，因此 開發(fā)者還需要能夠高效存儲這種數(shù)據(jù)的數(shù)據(jù)庫。但遺憾的是，關系型數(shù)據(jù)庫所使用的定義嚴格、基于模式的方式是無法快速容納新的數(shù)據(jù)類型的，對于非結構化或是 半結構化的數(shù)據(jù)更是無能為力。NoSQL提供的數(shù)據(jù)模型則能很好地滿足這種需求。很多應用都會從這種非結構化數(shù)據(jù)模型中獲益，比如說CRM、ERP、 BPM等等，他們可以通過這種靈活性存儲數(shù)據(jù)而無需修改表或是創(chuàng)建更多的列。這些數(shù)據(jù)庫也非常適合于創(chuàng)建原型或是快速應用，因為這種靈活性使得新特性的開發(fā)變得非常容易。

 2. NoSQL很容易實現(xiàn)可伸縮性(向上擴展與水平擴展)

如果有很多用戶在頻繁且并發(fā)地使用你的應用，那么你就需要考慮可伸縮的數(shù)據(jù)庫技術而非傳統(tǒng)的RDBMS了。對于關系型技術來說，很多應用開發(fā)者會發(fā)現(xiàn)動態(tài) 的可伸縮性是難以實現(xiàn)的，這時就應該考慮切換到NoSQL數(shù)據(jù)庫上。對于云應用來說，關系型數(shù)據(jù)庫一開始是普遍的選擇。然而，在使用過程中卻遇到了越來越 多的問題，原因就在于他們是中心化的，向上擴展而非水平擴展的。這使得他們不適合于那些需要簡單且動態(tài)可伸縮性的應用。NoSQL數(shù)據(jù)庫從一開始就是分布 式、水平擴展的，因此非常適合于互聯(lián)網(wǎng)應用分布式的特性。

在三層互聯(lián)網(wǎng)架構的Web/應用層上，多年來向上擴展已經(jīng)成為默認的擴展方式了。隨著應用使用人數(shù)的激增，我們需要添加更多的服務器，性能則是通過負載均 衡來實現(xiàn)的，這時的代價與用戶數(shù)量成線性比例關系。在NoSQL數(shù)據(jù)庫之前，數(shù)據(jù)庫層的默認擴展方式就是向上擴展。為了支持更多的并發(fā)用戶以及存儲更多的 數(shù)據(jù)，你需要越來越好的服務器，更好的CPU、更多的內(nèi)存、更大的磁盤來維護所有表。然而，好的服務器意味著更加復雜、私有、并且也更加昂貴。這與Web/應用層所使用的便宜的硬件形成了鮮明的對比。

3. 動態(tài)模式

關系型數(shù)據(jù)庫需要在添加數(shù)據(jù)前先定義好模式。比如說，你需要存儲客戶的電話號碼、姓名、地址、城市與州等信息，SQL數(shù)據(jù)庫需要提前知曉你要存的是什么。 這對于敏捷開發(fā)模式來說是場災難，因為每次完成新特性時，數(shù)據(jù)庫的模式通常都需要改變。因此，如果在開發(fā)過程中想將客戶喜歡的條目加到數(shù)據(jù)庫中，那就得向 表中添加這一列才行，然后要做的就是將整個數(shù)據(jù)庫遷移到新的模式上。

4. 自動分片

由于是結構化的，關系型數(shù)據(jù)庫通常會垂直擴展，單臺服務器要持有整個數(shù)據(jù)庫來確?？煽啃耘c數(shù)據(jù)的持續(xù)可用性。這樣做的代價就是非常昂貴、擴展受到限制，并 且數(shù)據(jù)庫基礎設施會成為失敗點。這個問題的解決方案就是水平擴展，添加服務器而不是為單臺服務器增加更多的能力。NoSQL數(shù)據(jù)庫通常都支持自動分片，這 意味著他們本質(zhì)上就會自動在多臺服務器上分發(fā)數(shù)據(jù)，應用甚至都不知道這些事情。數(shù)據(jù)與查詢負載會自動在多臺服務器上做到平衡，當某臺服務器當機時，它能快 速且透明地被替換掉。

5. 復制

大多數(shù)NoSQL數(shù)據(jù)庫也支持自動復制，這意味著你可以獲得高可用性與災備恢復功能。從開發(fā)者的角度來看，存儲環(huán)境本質(zhì)上是虛擬化的。

三、NoSQL優(yōu)缺點

在優(yōu)勢方面，主要體現(xiàn)在下面這三點：

• 簡單的擴展：典型例子是Cassandra，由于其架構是類似于經(jīng)典的P2P，所以能通過輕松地添加新的節(jié)點來擴展這個集群;
• 快速的讀寫：主要例子有Redis，由于其邏輯簡單，而且純內(nèi)存操作，使得其性能非常出色，單節(jié)點每秒可以處理超過10萬次讀寫操作;
• 低廉的成本：這是大多數(shù)分布式數(shù)據(jù)庫共有的特點，因為主要都是開源軟件，沒有昂貴的License成本;

但瑕不掩瑜，NoSQL數(shù)據(jù)庫還存在著很多的不足，常見主要有下面這幾個：

• 不提供對SQL的支持：如果不支持SQL這樣的工業(yè)標準，將會對用戶產(chǎn)生一定的學習和應用遷移成本;
• 支持的特性不夠豐富：現(xiàn)有產(chǎn)品所提供的功能都比較有限，大多數(shù)NoSQL數(shù)據(jù)庫都不支持事務，也不像MS SQL Server和Oracle那樣能提供各種附加功能，比如BI和報表等;
• 現(xiàn)有產(chǎn)品的不夠成熟：大多數(shù)產(chǎn)品都還處于初創(chuàng)期，和關系型數(shù)據(jù)庫幾十年的完善不可同日而語;

上面NoSQL產(chǎn)品的優(yōu)缺點都是些比較共通的，在實際情況下，每個產(chǎn)品都會根據(jù)自己所遵從的數(shù)據(jù)模型和CAP理念而有所不同。

四、適合場景

NoSQL數(shù)據(jù)庫正在成為數(shù)據(jù)庫領域的重要力量。如果使用恰當，那么它會帶來很多好處。然而，企業(yè)應該非常小心并注意到這些數(shù)據(jù)庫的限制與問題。

NoSQL這兩年越來越熱，尤其是大型互聯(lián)網(wǎng)公司非常熱衷這門技術。根據(jù)筆者的經(jīng)驗，并不是任何場景，NoSQL都要優(yōu)于關系型數(shù)據(jù)庫。下面我們來具體聊聊，什么時候使用NoSQL比較給力：

1. 數(shù)據(jù)庫表schema經(jīng)常變化

比如在線商城，維護產(chǎn)品的屬性經(jīng)常要增加字段，這就意味著ORMapping層的代碼和配置要改，如果該表的數(shù)據(jù)量過百萬，新增字段會帶來額外開銷(重建索引等)。NoSQL應用在這種場景，可以極大提升DB的可伸縮性，開發(fā)人員可以將更多的精力放在業(yè)務層。

2. 數(shù)據(jù)庫表字段是復雜數(shù)據(jù)類型

對于復雜數(shù)據(jù)類型，比如SQL Sever提供了可擴展性的支持，像xml類型的字段。很多用過的同學應該知道，該字段不管是查詢還是更改，效率非常一般。主要原因是是DB層對xml字 段很難建高效索引，應用層又要做從字符流到dom的解析轉換。NoSQL以json方式存儲，提供了原生態(tài)的支持，在效率方便遠遠高于傳統(tǒng)關系型數(shù)據(jù)庫。

3. 高并發(fā)數(shù)據(jù)庫請求

此類應用常見于web2.0的網(wǎng)站，很多應用對于數(shù)據(jù)一致性要求很低，而關系型數(shù)據(jù)庫的事務以及大表join反而成了”性能殺手”。在高并發(fā)情況 下，sql與no-sql的性能對比由于環(huán)境和角度不同一直是存在爭議的，并不是說在任何場景，no-sql總是會比sql快。有篇article和大家 分享下，http://artur.ejsmont.org/blog/content/insert-performance-comparison-of-nosql-vs-sql-servers

4. 海量數(shù)據(jù)的分布式存儲

海量數(shù)據(jù)的存儲如果選用大型商用數(shù)據(jù)，如Oracle，那么整個解決方案的成本是非常高的，要花很多錢在軟硬件上。NoSQL分布式存儲，可以部署在廉價的硬件上，是一個性價比非常高的解決方案。Mongo的auto-sharding已經(jīng)運用到了生產(chǎn)環(huán)境。http://www.mongodb.org/display/DOCS/Sharding

并不是說NoSQL可以解決一切問題，像ERP系統(tǒng)、BI系統(tǒng)，在大部分情況還是推薦使用傳統(tǒng)關系型數(shù)據(jù)庫。主要的原因是此類系統(tǒng)的業(yè)務模型復雜，使用NoSQL將導致系統(tǒng)的維護成本增加。

五、選擇SQL還是NoSQL

上面說明了為什么要使用NoSQL。接下來我們看下如何把NoSQL引入到我們的項目中，我們到底要不要把NoSQL引入到項目中。

在過去，我們只需要學習和使用一種數(shù)據(jù)庫技術，就能做幾乎所有的數(shù)據(jù)庫應用開發(fā)。因為成熟穩(wěn)定的關系數(shù)據(jù)庫產(chǎn)品并不是很多，而供你選擇的免費版本就 更加少了，所以互聯(lián)網(wǎng)領域基本上都選擇了免費的MySQL數(shù)據(jù)庫。在高速發(fā)展的WEB2.0時代，我們發(fā)現(xiàn)關系數(shù)據(jù)庫在性能、擴展性、數(shù)據(jù)的快速備份和恢 復、滿足需求的易用性上并不總是能很好的滿足我們的需要，我們越來越趨向于根據(jù)業(yè)務場景選擇合適的數(shù)據(jù)庫，以及進行多種數(shù)據(jù)庫的融合運用。幾年前的一篇文 章《One Size Fits All - An Idea Whose Time Has Come and Gone》就已經(jīng)闡述了這個觀點。

當我們在討論是否要使用NoSQL的時候，你還需要理解NoSQL也是分很多種類的，在NoSQL百花齊放的今天，NoSQL的正確選擇比選擇關系數(shù)據(jù)庫還具有挑戰(zhàn)性。雖然NoSQL的使用很簡單，但是選擇卻是個麻煩事，這也正是很多人在觀望的一個原因。

六、NoSQL的分類

NoSQL僅僅是一個概念，NoSQL數(shù)據(jù)庫根據(jù)數(shù)據(jù)的存儲模型和特點分為很多種類。

以上NoSQL數(shù)據(jù)庫類型的劃分并不是絕對，只是從存儲模型上來進行的大體劃分。它們之間沒有絕對的分界，也有交差的情況，比如Tokyo Cabinet / Tyrant的Table類型存儲，就可以理解為是文檔型存儲，Berkeley DB XML數(shù)據(jù)庫是基于Berkeley DB之上開發(fā)的。

七、選擇和使用建議

雖然09年出現(xiàn)了比較激進的文章《關系數(shù)據(jù)庫已死》，但是我們心里都清楚，關系數(shù)據(jù)庫其實還活得好好的，你還不能不用關系數(shù)據(jù)庫。但是也說明了一個事實，關系數(shù)據(jù)庫在處理WEB2.0數(shù)據(jù)的時候，的確已經(jīng)出現(xiàn)了瓶頸。

那么我們到底是用NoSQL還是關系數(shù)據(jù)庫呢?我想我們沒有必要來進行一個絕對的回答。我們需要根據(jù)我們的應用場景來決定我們到底用什么。

如果關系數(shù)據(jù)庫在你的應用場景中，完全能夠很好的工作，而你又是非常善于使用和維護關系數(shù)據(jù)庫的，那么我覺得你完全沒有必要遷移到NoSQL上面， 除非你是個喜歡折騰的人。如果你是在金融，電信等以數(shù)據(jù)為王的關鍵領域，目前使用的是Oracle數(shù)據(jù)庫來提供高可靠性的，除非遇到特別大的瓶頸，不然也 別貿(mào)然嘗試NoSQL。

然而，在WEB2.0的網(wǎng)站中，關系數(shù)據(jù)庫大部分都出現(xiàn)了瓶頸。在磁盤IO、數(shù)據(jù)庫可擴展上都花費了開發(fā)人員相當多的精力來優(yōu)化，比如做分表分庫 (database sharding)、主從復制、異構復制等等，然而，這些工作需要的技術能力越來越高，也越來越具有挑戰(zhàn)性。如果你正在經(jīng)歷這些場合，那么我覺得你應該嘗 試一下NoSQL了。

1. 選擇合適的NoSQL

如此多類型的NoSQL，而每種類型的NoSQL又有很多，到底選擇什么類型的NoSQL來作為我們的存儲呢?這并不是一個很好回答的問題，影響我們選擇 的因素有很多，而選擇也可能有多種，隨著業(yè)務場景，需求的變更可能選擇又會變化。我們常常需要根據(jù)如下情況考慮：

• 數(shù)據(jù)結構特點。包括結構化、半結構化、字段是否可能變更、是否有大文本字段、數(shù)據(jù)字段是否可能變化。
• 寫入特點。包括insert比例、update比例、是否經(jīng)常更新數(shù)據(jù)的某一個小字段、原子更新需求。
• 查詢特點。包括查詢的條件、查詢熱點的范圍。比如用戶信息的查詢，可能就是隨機的，而新聞的查詢就是按照時間，越新的越頻繁。

2. NoSQL和關系數(shù)據(jù)庫結合

其實NoSQL數(shù)據(jù)庫僅僅是關系數(shù)據(jù)庫在某些方面(性能，擴展)的一個彌補，單從功能上講，NoSQL的幾乎所有的功能，在關系數(shù)據(jù)庫上都能夠滿足，所以選擇NoSQL的原因并不在功能上。

所以，我們一般會把NoSQL和關系數(shù)據(jù)庫進行結合使用，各取所長，需要使用關系特性的時候我們使用關系數(shù)據(jù)庫，需要使用NoSQL特性的時候我們使用NoSQL數(shù)據(jù)庫，各得其所。

舉個簡單的例子吧，比如用戶評論的存儲，評論大概有主鍵id、評論的對象aid、評論內(nèi)容content、用戶uid等字段。我們能確定的是評論內(nèi) 容content肯定不會在數(shù)據(jù)庫中用where content=’’查詢，評論內(nèi)容也是一個大文本字段。那么我們可以把 主鍵id、評論對象aid、用戶id存儲在數(shù)據(jù)庫，評論內(nèi)容存儲在NoSQL，這樣數(shù)據(jù)庫就節(jié)省了存儲content占用的磁盤空間，從而節(jié)省大量IO， 對content也更容易做Cache。

//從MySQL中查詢出評論主鍵id列表 commentIds=DB.query(“SELECT id FROM comments where aid=’評論對象id’ LIMIT 0,20”); //根據(jù)主鍵id列表，從NoSQL取回評論實體數(shù)據(jù) CommentsList=NoSQL.get(commentIds);NoSQL代替MySQL  

在某些應用場合，比如一些配置的關系鍵值映射存儲、用戶名和密碼的存儲、Session會話存儲等等，用NoSQL完全可以替代MySQL存儲。不但具有更高的性能，而且開發(fā)也更加方便。

3. NoSQL作為緩存服務器

MySQL+Memcached的架構中，我們處處都要精心設計我們的緩存，包括過期時間的設計、緩存的實時性設計、緩存內(nèi)存大小評估、緩存命中率等等。

NoSQL數(shù)據(jù)庫一般都具有非常高的性能，在大多數(shù)場景下面，你不必再考慮在代碼層為NoSQL構建一層Memcached緩存。NoSQL數(shù)據(jù)本身在Cache上已經(jīng)做了相當多的優(yōu)化工作。

Memcached這類內(nèi)存緩存服務器緩存的數(shù)據(jù)大小受限于內(nèi)存大小，如果用NoSQL來代替Memcached來緩存數(shù)據(jù)庫的話，就可以不再受限于內(nèi)存大小。雖然可能有少量的磁盤IO讀寫，可能比Memcached慢一點，但是完全可以用來緩存數(shù)據(jù)庫的查詢操作。

【本文為51CTO專欄作者“大數(shù)據(jù)和云計算”的原創(chuàng)稿件，轉載請通過微信公眾號獲取聯(lián)系和授權】

戳這里，看該作者更多好文