Redis之NoSql入門和概述(一)

1. 爲何用 NoSQL？

NoSQL指的是非關係型的數據庫，NoSQL也稱做Not Only SQL的縮寫，是對不一樣於傳統的關係型數據庫的數據庫管理系統的統稱。NoSQL用於超大規模數據的存儲。這些類型的數據存儲不須要固定的模式，無需多餘操做就能夠橫向擴展

1.1 單機 MySQL 的美好時代

在90年代，一個網站的訪問量通常都不大，用單個數據庫徹底能夠輕鬆應付。在那個時候，更多的都是靜態網頁，動態交互類型的網站很少。

備註：DAL : Data Access Layer（數據訪問層 – Hibernate，MyBatis）

上述架構下，咱們來看看數據存儲的瓶頸是什麼？

1. 數據量的總大小一個機器放不下時。
2. 數據的索引（B+ Tree）一個機器的內存放不下時。
3. 訪問量(讀寫混合)一個實例不能承受。
4. 若是知足了上述1 or 3個時，只能對數據庫的總體架構進行重構。

1.2 Memcached(緩存)+MySQL+垂直拆分

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

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

1.3 Mysql主從讀寫分離

因爲數據庫的寫入壓力增長，Memcached只能緩解數據庫的讀取壓力。讀寫集中在一個數據庫上讓數據庫不堪重負，大部分網站開始使用主從複製技術來達到讀寫分離，以提升讀寫性能和讀庫的可擴展性。Mysql的master-slave模式成爲這個時候的網站標配了。

1.4 分庫分表+水平拆分+mysql集羣

在Memcached的高速緩存，MySQL的主從複製，讀寫分離的基礎之上，這時MySQL主庫的寫壓力開始出現瓶頸，而數據量的持續猛增，因爲MyISAM在寫數據的時候會使用表鎖，在高併發寫數據的狀況下會出現嚴重的鎖問題，大量的高併發MySQL應用開始使用InnoDB引擎代替MyISAM。

ps：這就是爲何 MySQL 在 5.1版本以後使用 InnoDB 作爲默認存儲引擎的緣由 – MyISAM 寫會鎖表，InnoDB 有行鎖，發生衝突的概率低，併發性能高。

聊點題外話：MyISAM是非集聚引擎，支持全文索引;不支持事務;它是表級鎖;會保存表的具體行數.innoDB是集聚引擎，5.6之後纔有全文索引;支持事務；它是行級鎖;不會保存表的具體行數.

同時，開始流行使用分表分庫來緩解寫壓力和數據增加的擴展問題。這個時候，分表分庫成了一個熱門技術，是面試的熱門問題也是業界討論的熱門技術問題。也就在這個時候，MySQL推出了還不太穩定的表分區，這也給技術實力通常的公司帶來了但願。雖然MySQL推出了MySQL Cluster集羣，但性能也不能很好知足互聯網的要求，只是在高可靠性上提供了很是大的保證。

1.5 MySQL的擴展性瓶頸

MySQL數據庫也常常存儲一些大文本字段，致使數據庫表很是的大，在作數據庫恢復的時候就致使很是的慢，不容易快速恢復數據庫。好比1000萬4KB大小的文本就接近40GB的大小，若是能把這些數據從MySQL省去，MySQL將變得很是的小。關係數據庫很強大，可是它並不能很好的應付全部的應用場景。MySQL的擴展性差（須要複雜的技術來實現），大數據下IO壓力大，表結構更改困難，正是當前使用MySQL的開發人員面臨的問題。

1.6 今天是什麼樣子？

最前面的是企業級防火牆，後面經過負載均衡主機（軟負載：Nginx，硬負載：F5）在 web 服務器集羣之間進行調度，再由具體的 web 服務器（Tomcat）去訪問緩存，訪問數據庫。

1.7 爲何用NoSQL?

今天咱們能夠經過第三方平臺（如：Google,Facebook等）能夠很容易的訪問和抓取數據。用戶的我的信息，社交網絡，地理位置，用戶生成的數據和用戶操做日誌已經成倍的增長。咱們若是要對這些用戶數據進行挖掘，那SQL數據庫已經不適合這些應用了, NoSQL數據庫的發展也卻能很好的處理這些大的數據。