Redis從入門到放棄 之 Nosql

1、爲何要使用Nosql

一、傳統關係型數據庫的瓶頸

        傳統的關係數據庫具備不錯的性能，高穩定型，久經歷史考驗，並且使用簡單，功能強大，同時也積累了大量的成功案例。在互聯網領域，MySQL成爲了絕對靠前的王者，絕不誇張的說，MySQL爲互聯網的發展作出了卓越的貢獻。在90年代，一個網站的訪問量通常都不大，用單個數據庫徹底能夠輕鬆應付。在那個時候，更多的都是靜態網頁，動態交互類型的網站很少。到了最近10年，網站開始快速發展。火爆的論壇、博客、sns、微博逐漸引領web領域的潮流。在初期，論壇的流量其實也不大，若是你接觸網絡比較早，你可能還記得那個時候還有文本型存儲的論壇程序，能夠想象通常的論壇的流量有多大。

二、Memcached+MySQL

後來，隨着訪問量的上升，幾乎大部分使用MySQL架構的網站在數據庫上都開始出現了性能問題，web程序再也不僅僅專一在功能上，同時也在追求性能。程序員們開始大量的使用緩存技術來緩解數據庫的壓力，優化數據庫的結構和索引。開始比較流行的是經過文件緩存來緩解數據庫壓力，可是當訪問量繼續增大的時候，多臺web機器經過文件緩存不能共享，大量的小文件緩存也帶了了比較高的IO壓力。在這個時候，Memcached就天然的成爲一個很是時尚的技術產品。

Memcached做爲一個獨立的分佈式的緩存服務器，爲多個web服務器提供了一個共享的高性能緩存服務，在Memcached服務器上，又發展了根據hash算法來進行多臺Memcached緩存服務的擴展，而後又出現了一致性hash來解決增長或減小緩存服務器致使從新hash帶來的大量緩存失效的弊端。

三、Mysql主從讀寫分離

因爲數據庫的寫入壓力增長，Memcached只能緩解數據庫的讀取壓力。讀寫集中在一個數據庫上讓數據庫不堪重負，

大部分網站開始使用主從複製技術來達到讀寫分離，以提升讀寫性能和讀庫的可擴展性。Mysql的master-slave模式

成爲這個時候的網站標配了。

 

 

四、分表分庫

隨着web2.0的繼續高速發展，在Memcached的高速緩存，MySQL的主從複製，讀寫分離的基礎之上，

這時MySQL主庫的寫壓力開始出現瓶頸，而數據量的持續猛增，因爲MyISAM使用表鎖，在高併發下

會出現嚴重的鎖問題，大量的高併發MySQL應用開始使用InnoDB引擎代替MyISAM。同時，開始流

行使用分表分庫來緩解寫壓力和數據增加的擴展問題。這個時候，分表分庫成了一個熱門技術，是

面試的熱門問題也是業界討論的熱門技術問題。也就在這個時候，MySQL推出了還不太穩定的表分

區，這也給技術實力通常的公司帶來了但願。雖然MySQL推出了MySQL Cluster集羣，可是因爲在

互聯網幾乎沒有成功案例，性能也不能知足互聯網的要求，只是在高可靠性上提供了很是大的保證。

 

 

五、MySQL的擴展性瓶頸

在互聯網，大部分的MySQL都應該是IO密集型的，事實上，若是你的MySQL是個CPU密集型的話，那麼極可能你的MySQL設計得有性能問題，須要優化了。大數據量高併發環境下的MySQL應用開發愈來愈複雜，也愈來愈具備技術挑戰性。分表分庫的規則把握都是須要經驗的。雖然有像淘寶這樣技術實力強大的公司開發了透明的中間件層來屏蔽開發者的複雜性，可是避免不了整個架構的複雜性。分庫分表的子庫到必定階段又面臨擴展問題。還有就是需求的變動，可能又須要一種新的分庫方式。

MySQL數據庫也常常存儲一些大文本字段，致使數據庫表很是的大，在作數據庫恢復的時候就致使很是的慢，不容易快速恢復數據庫。好比1000萬4KB大小的文本就接近40GB的大小，若是能把這些數據從MySQL省去，MySQL將變得很是的小。

關係數據庫很強大，可是它並不能很好的應付全部的應用場景。MySQL的擴展性差（須要複雜的技術來實現），大數據下IO壓力大，表結構更改困難，正是當前使用MySQL的開發人員面臨的問題。

六、Nosql應運而生

易擴展

NoSQL數據庫種類繁多，可是一個共同的特色都是去掉關係數據庫的關係型特性。數據之間無關係，這樣就很是容易擴展。也無形之間，在架構的層面上帶來了可擴展的能力。

大數據量，高性能

NoSQL數據庫都具備很是高的讀寫性能，尤爲在大數據量下，一樣表現優秀。這得益於它的無關係性，數據庫的結構簡單。通常MySQL使用Query Cache，每次表的更新Cache就失效，是一種大粒度的Cache，在針對web2.0的交互頻繁的應用，Cache性能不高。而NoSQL的Cache是記錄級的，是一種細粒度的Cache，因此NoSQL在這個層面上來講就要性能高不少了。

靈活的數據模型

NoSQL無需事先爲要存儲的數據創建字段，隨時能夠存儲自定義的數據格式。而在關係數據庫裏，增刪字段是一件很是麻煩的事情。若是是很是大數據量的表，增長字段簡直就是一個噩夢。這點在大數據量的web2.0時代尤爲明顯。

高可用

NoSQL在不太影響性能的狀況，就能夠方便的實現高可用的架構。好比Cassandra，HBase模型，經過複製模型也能實現高可用。

 

NoSQL數據庫的出現，彌補了關係數據（好比MySQL）在某些方面的不足，在某些方面能極大的節省開發成本和維護成本。

MySQL和NoSQL都有各自的特色和使用的應用場景，二者的緊密結合將會給web2.0的數據庫發展帶來新的思路。讓關係數據庫關注在關係上，NoSQL關注在存儲上。

 

2、什麼是Nosql

 

  NoSQL，泛指非關係型的數據庫。NoSQL = not only sql

一、四大分類

 

Key-Value 型數據庫：

鍵值數據庫就像在傳統語言中使用的哈希表。你能夠經過key來添加、查詢或者刪除數據，

鑑於使用主鍵訪問，因此會得到不錯的性能及擴展性。

 

主要框架：Redis

 

應用場景：儲存用戶信息，好比會話、配置文件、參數、購物車等等。這些信息通常都和ID（鍵）掛鉤，

    這種情景下鍵值數據庫是個很好的選擇

文檔型數據庫：

文檔型數據庫同第一種鍵值存儲相相似，該類型的數據模型是以特定的格式存儲，好比JSON（BSON）。

文檔型數據庫可 以看做是鍵值數據庫的升級版，容許之間嵌套鍵值。並且文檔型數據庫比鍵值數據庫的查詢效率更高。

 

主要框架：MongoDB

應用場景：日誌。企業環境下，每一個應用程序都有不一樣的日誌信息。Document-Oriented數據庫並無固定的模式，

因此咱們可使用它儲存不一樣的信息。分析。鑑於它的弱模式結構，不改變模式下就能夠儲存不一樣的度量方法及添加新的度量。

 

 

列存儲數據庫。

 

這部分數據庫一般是用來應對分佈式存儲的海量數據。鍵仍然存在，可是它們的特色是指向了多個列。

這些列是由列家族來安排的。如：Cassandra, HBase, Riak.

 

應用場景：日誌。由於咱們能夠將數據儲存在不一樣的列中，每一個應用程序能夠將信息寫入本身的列族中。

博客平臺。咱們儲存每一個信息到不一樣的列族中。舉個例子，標籤能夠儲存在一個，類別能夠在一個，而文章則在另外一個。

圖形(Graph)數據庫

 

圖形結構的數據庫同其餘行列以及剛性結構的SQL數據庫不一樣，它是使用靈活的圖形模型，

而且可以擴展到多個服務器上。NoSQL數據庫沒有標準的查詢語言(SQL)，所以進行數據

庫查詢須要制定數據模型。許多NoSQL數據庫都有REST式的數據接口或者查詢API。

Neo4J、Infinite Graph、OrientDB

 

應用場景：在一些關係性強的數據中，推薦引擎。若是咱們將數據以圖的形式表現，那麼將會很是有益於推薦的制定

 

 

二、其餘

通常nosql適用的場景都是讀多寫少，由於數據庫主要壓力來自於用戶的讀取數據。

在衆多NoSQL中咱們通常拿Redis替換Memecached使用。    

 

 

衆多語言都支持Redis，由於Redis交換數據快，因此在服務器中經常使用來存儲一些須要頻繁調取的數據，

這樣能夠大大節省系統直接讀取磁盤來得到數據的I/O開銷，更重要的是能夠極大提高速度。

 

拿大型網站來舉個例子，好比a網站首頁一天有100萬人訪問，其中有一個板塊爲推薦新聞。要是直接

從數據庫查詢，那麼一天就要多消耗100萬次數據庫請求。上面已經說過，Redis支持豐富的數據類型，

因此這徹底能夠用Redis來完成，將這種熱點數據存到Redis（內存）中，要用的時候，直接從內存取，

極大的提升了速度和節約了服務器的開銷。

 

 

 

 

 

 

 

 

文章引用：

一、http://www.infoq.com/cn/news/2011/01/nosql-why