你們有沒有據說過「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數據庫的,但有一個重要的大前提,請你們必定不要誤解。這個大前提就是「關係型數據庫的性能絕對不低,它具備很是好的通用性和很是高的性能」。毫無疑問,對於絕大多數的應用來講它都是最有效的解決方案。 併發
突出的優點
關係型數據庫做爲應用普遍的通用型數據庫,它的突出優點主要有如下幾點: memcached
保持數據的一致性(事務處理) 高併發
因爲以標準化爲前提,數據更新的開銷很小(相同的字段基本上都只有一處)性能
能夠進行JOIN等複雜查詢網站
存在不少實際成果和專業技術信息(成熟的技術)
這其中,可以保持數據的一致性是關係型數據庫的最大優點。在須要嚴格保證數據一致性和處理完整性的狀況下,用關係型數據庫是確定沒有錯的。可是有些狀況不須要JOIN,對上述關係型數據庫的優勢也沒有什麼特別須要,這時彷佛也就沒有必要拘泥於關係型數據庫了。
不擅長的處理
就像以前提到的那樣,關係型數據庫的性能很是高。可是它畢竟是一個通用型的數據庫,並不能徹底適應全部的用途。具體來講它並不擅長如下處理:
大量數據的寫入處理
爲有數據更新的表作索引或表結構(schema)變動
字段不固定時應用
對簡單查詢須要快速返回結果的處理
。。。。。。
爲了彌補關係型數據庫的不足(特別是最近幾年),NoSQL數據庫出現了。關係型數據庫應用普遍,能進行事務處理和JOIN等複雜處理。相對地,NoSQL數據庫只應用在特定領域,基本上不進行復雜的處理,但它偏偏彌補了以前所列舉的關係型數據庫的不足之處。
易於數據的分散
如前所述,關係型數據庫並不擅長大量數據的寫入處理。本來關係型數據庫就是以JOIN爲前提的,就是說,各個數據之間存在關聯是關係型數據庫得名的主要緣由。爲了進行JOIN處理,關係型數據庫不得不把數據存儲在同一個服務器內,這不利於數據的分散。相反,NoSQL數據庫本來就不支持JOIN處理,各個數據都是獨立設計的,很容易把數據分散到多個服務器上。因爲數據被分散到了多個服務器上,減小了每一個服務器上的數據量,即便要進行大量數據的寫入操做,處理起來也更加容易。同理,數據的讀入操做固然也一樣容易。
提高性能和增大規模
下面說一點題外話,若是想要使服務器可以輕鬆地處理更大量的數據,那麼只有兩個選擇:一是提高性能,二是增大規模。下面咱們來整理一下這二者的不一樣。
首先,提高性能指的就是經過提高現行服務器自身的性能來提升處理能力。這是很是簡單的方法,程序方面也不須要進行變動,但須要一些費用。若要購買性能翻倍的服務器,須要花費的資金每每不僅是原來的2倍,可能須要多達5到10倍。這種方法雖然簡單,可是成本較高。
另外一方面,增大規模指的是使用多臺廉價的服務器來提升處理能力。它須要對程序進行變動,但因爲使用廉價的服務器,能夠控制成本。另外,之後只要依葫蘆畫瓢增長廉價服務器的數量就能夠了。
不對大量數據進行處理的話就沒有使用的必要嗎?
NoSQL數據庫基本上來講爲了「使大量數據的寫入處理更加容易(讓增長服務器數量更容易)」而設計的。但若是不是對大量數據進行操做的話,NoSQL數據庫的應用就沒有意義嗎?
答案是否認的。的確,它在處理大量數據方面頗有優點。但實際上NoSQL數據庫還有各類各樣的特色,若是可以恰當地利用這些特色將會是很是有幫助。具體的例子將會在第2章和第3章進行介紹,這些用途將會讓你感覺到利用NoSQL的好處。
但願順暢地對數據進行緩存(Cache)處理
但願對數組類型的數據進行高速處理
但願進行所有保存
多樣的NoSQL數據庫
NoSQL數據庫存在着「key-value存儲」、「文檔型數據庫」、「列存儲數據庫」等各類各樣的種類,每種數據庫又包含各自的特色。下一節讓咱們一塊兒來了解一下NoSQL數據庫的種類和特色。
NoSQL提及來簡單,但實際上到底有多少種呢?我在提筆的時候,到NoSQL的官方網站上確認了一下,居然已經有122種了。另外官方網站上也介紹了本書沒有涉及到的圖形數據庫和對象數據庫等各個類別。不知不覺間,原來已經出現了這麼多的NoSQL數據庫啊。
本節將爲你們介紹具備表明性的NoSQL數據庫。
這是最多見的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不是萬能的,但在大型項目中,你每每須要它!