關係型資料庫和NoSQL資料庫

什麼是NoSQL

大家有沒有聽說過“NoSQL”呢？近年，這個詞極受關注。看到“NoSQL”這個詞，大家可能會誤以為是“No！SQL”的縮寫，並深感憤怒：“SQL怎麼會沒有必要了呢？”但實際上，它是“Not Only SQL”的縮寫。它的意義是：適用關係型資料庫的時候就使用關係型資料庫，不適用的時候也沒有必要非使用關係型資料庫不可，可以考慮使用更加合適的資料儲存。 

為彌補關係型資料庫的不足，各種各樣的NoSQL資料庫應運而生。

為了更好地瞭解本書所介紹的NoSQL資料庫，對關係型資料庫的理解是必不可少的。那麼，就讓我們先來看一看關係型資料庫的歷史、分類和特徵吧。

關係型資料庫簡史

1969年，埃德加•弗蘭克•科德（Edgar Frank Codd）發表了劃時代的論文，首次提出了關係資料模型的概念。但可惜的是，刊登論文的《IBM Research Report》只是IBM公司的內部刊物，因此論文反響平平。1970年，他再次在刊物《Communication of the ACM》上發表了題為“A Relational Model of Data for Large Shared Data banks”（大型共享資料庫的關係模型）的論文，終於引起了大家的關注。

科德所提出的關係資料模型的概念成為了現今關係型資料庫的基礎。當時的關係型資料庫由於硬體效能低劣、處理速度過慢而遲遲沒有得到實際應用。但之後隨著硬體效能的提升，加之使用簡單、效能優越等優點，關係型資料庫得到了廣泛的應用。

通用性及高效能

雖然本書是講解NoSQL資料庫的，但有一個重要的大前提，請大家一定不要誤解。這個大前提就是“關係型資料庫的效能絕對不低，它具有非常好的通用性和非常高的效能”。毫無疑問，對於絕大多數的應用來說它都是最有效的解決方案。 

突出的優勢
關係型資料庫作為應用廣泛的通用型資料庫，它的突出優勢主要有以下幾點:   

• 保持資料的一致性（事務處理）  
• 由於以標準化為前提，資料更新的開銷很小（相同的欄位基本上都只有一處）
• 可以進行JOIN等複雜查詢
• 存在很多實際成果和專業技術資訊（成熟的技術） 

這其中，能夠保持資料的一致性是關係型資料庫的最大優勢。在需要嚴格保證資料一致性和處理完整性的情況下，用關係型資料庫是肯定沒有錯的。但是有些情況不需要JOIN，對上述關係型資料庫的優點也沒有什麼特別需要，這時似乎也就沒有必要拘泥於關係型資料庫了。

關係型資料庫的不足

不擅長的處理
就像之前提到的那樣，關係型資料庫的效能非常高。但是它畢竟是一個通用型的資料庫，並不能完全適應所有的用途。具體來說它並不擅長以下處理： 

• 大量資料的寫入處理  
• 為有資料更新的表做索引或表結構（schema）變更
• 欄位不固定時應用
• 對簡單查詢需要快速返回結果的處理   

。。。。。。

NoSQL資料庫

為了彌補關係型資料庫的不足（特別是最近幾年），NoSQL資料庫出現了。關係型資料庫應用廣泛，能進行事務處理和JOIN等複雜處理。相對地，NoSQL資料庫只應用在特定領域，基本上不進行復雜的處理，但它恰恰彌補了之前所列舉的關係型資料庫的不足之處。 

易於資料的分散
如前所述，關係型資料庫並不擅長大量資料的寫入處理。原本關係型資料庫就是以JOIN為前提的，就是說，各個資料之間存在關聯是關係型資料庫得名的主要原因。為了進行JOIN處理，關係型資料庫不得不把資料儲存在同一個伺服器內，這不利於資料的分散。相反，NoSQL資料庫原本就不支援JOIN處理，各個資料都是獨立設計的，很容易把資料分散到多個伺服器上。由於資料被分散到了多個伺服器上，減少了每個伺服器上的資料量，即使要進行大量資料的寫入操作，處理起來也更加容易。同理，資料的讀入操作當然也同樣容易。

提升效能和增大規模
下面說一點題外話，如果想要使伺服器能夠輕鬆地處理更大量的資料，那麼只有兩個選擇：一是提升效能，二是增大規模。下面我們來整理一下這兩者的不同。 

首先，提升效能指的就是通過提升現行伺服器自身的效能來提高處理能力。這是非常簡單的方法，程式方面也不需要進行變更，但需要一些費用。若要購買效能翻倍的伺服器，需要花費的資金往往不只是原來的2倍，可能需要多達5到10倍。這種方法雖然簡單，但是成本較高。 

另一方面，增大規模指的是使用多臺廉價的伺服器來提高處理能力。它需要對程式進行變更，但由於使用廉價的伺服器，可以控制成本。另外，以後只要依葫蘆畫瓢增加廉價伺服器的數量就可以了。 

不對大量資料進行處理的話就沒有使用的必要嗎？
NoSQL資料庫基本上來說為了“使大量資料的寫入處理更加容易（讓增加伺服器數量更容易）”而設計的。但如果不是對大量資料進行操作的話，NoSQL資料庫的應用就沒有意義嗎？ 

答案是否定的。的確，它在處理大量資料方面很有優勢。但實際上NoSQL資料庫還有各種各樣的特點，如果能夠恰當地利用這些特點將會是非常有幫助。具體的例子將會在第2章和第3章進行介紹，這些用途將會讓你感受到利用NoSQL的好處。 

• 希望順暢地對資料進行快取（Cache）處理
• 希望對陣列型別的資料進行高速處理
• 希望進行全部儲存

多樣的NoSQL資料庫
NoSQL資料庫存在著“key-value儲存”、“文件型資料庫”、“列儲存資料庫”等各種各樣的種類，每種資料庫又包含各自的特點。下一節讓我們一起來了解一下NoSQL資料庫的種類和特點。

NoSQL資料庫是什麼

NoSQL說起來簡單，但實際上到底有多少種呢？我在提筆的時候，到NoSQL的官方網站上確認了一下，竟然已經有122種了。另外官方網站上也介紹了本書沒有涉及到的圖形資料庫和物件資料庫等各個類別。不知不覺間，原來已經出現了這麼多的NoSQL資料庫啊。 

本節將為大家介紹具有代表性的NoSQL資料庫。

key-value儲存

這是最常見的NoSQL資料庫，它的資料是以key-value的形式儲存的。雖然它的處理速度非常快，但是基本上只能通過key的完全一致查詢獲取資料。根據資料的儲存方式可以分為臨時性、永久性和兩者兼具三種。

臨時性
memcached屬於這種型別。所謂臨時性就是 “資料有可能丟失”的意思。memcached把所有資料都儲存在記憶體中，這樣儲存和讀取的速度非常快，但是當memcached停止的時候，資料就不存在了。由於資料儲存在記憶體中，所以無法操作超出記憶體容量的資料（舊資料會丟失）。 

• 在記憶體中儲存資料
• 可以進行非常快速的儲存和讀取處理
• 資料有可能丟失

永久性
Tokyo Tyrant、Flare、ROMA等屬於這種型別。和臨時性相反，所謂永久性就是“資料不會丟失”的意思。這裡的key-value儲存不像memcached那樣在記憶體中儲存資料，而是把資料儲存在硬碟上。與memcached在記憶體中處理資料比起來，由於必然要發生對硬碟的IO操作，所以效能上還是有差距的。但資料不會丟失是它最大的優勢。 

• 在硬碟上儲存資料
• 可以進行非常快速的儲存和讀取處理（但無法與memcached相比）
• 資料不會丟失

兩者兼具
Redis屬於這種型別。Redis有些特殊，臨時性和永久性兼具，且集合了臨時性key-value儲存和永久性key-value儲存的優點。Redis首先把資料儲存到記憶體中，在滿足特定條件（預設是15分鐘一次以上，5分鐘內10個以上，1分鐘內10000個以上的key發生變更）的時候將資料寫入到硬碟中。這樣既確保了記憶體中資料的處理速度，又可以通過寫入硬碟來保證資料的永久性。這種型別的資料庫特別適合於處理陣列型別的資料。

• 同時在記憶體和硬碟上儲存資料
• 可以進行非常快速的儲存和讀取處理
• 儲存在硬碟上的資料不會消失（可以恢復）
• 適合於處理陣列型別的資料

面向文件的資料庫

MongoDB、CouchDB屬於這種型別。它們屬於NoSQL資料庫，但與key-value儲存相異。 

不定義表結構
面向文件的資料庫具有以下特徵：即使不定義表結構，也可以像定義了表結構一樣使用。關係型資料庫在變更表結構時比較費事，而且為了保持一致性還需修改程式。然而NoSQL資料庫則可省去這些麻煩（通常程式都是正確的），確實是方便快捷。 

可以使用複雜的查詢條件
跟key-value儲存不同的是，面向文件的資料庫可以通過複雜的查詢條件來獲取資料。雖然不具備事務處理和JOIN這些關係型資料庫所具有的處理能力，但除此以外的其他處理基本上都能實現。這是非常容易使用的NoSQL資料庫。 

• 不需要定義表結構
• 可以利用複雜的查詢條件

面向列的資料庫

Cassandra、Hbase、HyperTable屬於這種型別。由於近年來資料量出現爆發性增長，這種型別的NoSQL資料庫尤其引人注目。 

面向行的資料庫和麵向列的資料庫
普通的關係型資料庫都是以行為單位來儲存資料的，擅長進行以行為單位的讀入處理，比如特定條件資料的獲取。因此，關係型資料庫也被稱為面向行的資料庫。相反，面向列的資料庫是以列為單位來儲存資料的，擅長以列為單位讀入資料。 

高擴充套件性
面向列的資料庫具有高擴充套件性，即使資料增加也不會降低相應的處理速度（特別是寫入速度），所以它主要應用於需要處理大量資料的情況。另外，利用面向列的資料庫的優勢，把它作為批處理程式的儲存器來對大量資料進行更新也是非常有用的。但由於面向列的資料庫跟現行資料庫儲存的思維方式有很大不同，應用起來十分困難。 

• 高擴充套件性（特別是寫入處理）
• 應用十分困難

最近，像Twitter和Facebook這樣需要對大量資料進行更新和查詢的網路服務不斷增加，面向列的資料庫的優勢對其中一些服務是非常有用的，但是由於這與本書所要介紹的內容關係不大，就不進行詳細介紹了。

總結：

NoSQL並不是No-SQL，而是指Not Only SQL。

NoSQL的出現是為了彌補SQL資料庫因為事務等機制帶來的對海量資料、高併發請求的處理的效能上的欠缺。

NoSQL不是為了替代SQL而出現的，它是一種替補方案，而不是解決方案的首選。

絕大多數的NoSQL產品都是基於大記憶體和高效能隨機讀寫的（比如具有更高效能的固態硬碟陣列），一般的小型企業在選擇NoSQL時一定要慎重！不要為了NoSQL而NoSQL，可能會導致花了冤枉錢又耽擱了專案程序。

NoSQL不是萬能的，但在大型專案中，你往往需要它！