NoSQL的前世今生

NoSQL的前世今生

Java大猿帥成長手冊，GitHub JavaEgg ，N線互聯網開發必備技能兵器譜

啥玩意：

NoSQL(NoSQL = Not Only SQL )，“不僅僅是SQL”，泛指非關係型的數據庫。隨着互聯網web2.0網站的興起，傳統的關係數據庫在處理web2.0網站，特別是超大規模和高併發的SNS類型的web2.0純動態網站已經顯得力不從心，暴露了很多難以克服的問題，而非關係型的數據庫則由於其本身的特點得到了非常迅速的發展。NoSQL數據庫的產生就是爲了解決大規模數據集合多重數據種類帶來的挑戰，尤其是大數據應用難題，包括超大規模數據的存儲。（例如谷歌或Facebook每天爲他們的用戶收集萬億比特的數據）。這些類型的數據存儲不需要固定的模式，無需多餘操作就可以橫向擴展。

互聯網時代背景下，數據庫的發展以及爲什麼要用nosql

1. 單機MySQL的美好年代

​ 在以前，一個網站的訪問量一般都不大，用單個數據庫完全可以輕鬆應付。在那個時候，更多的都是靜態網頁，動態交互類型的網站不多。上述架構下，我們來看看數據存儲的瓶頸是什麼？

• 數據量的總大小 一個機器放不下時
• 數據的索引（B+ Tree）一個機器的內存放不下時
• 訪問量(讀寫混合)一個實例不能承受

2. Memcached(緩存)+MySQL+垂直拆分

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

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

3. Mysql主從讀寫分離

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

4. 分表分庫+水平拆分+mysql集羣

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

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

5. MySQL的擴展性瓶頸

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

6. 爲什麼用NoSQL

​ 今天我們可以通過第三方平臺（如：Google,Facebook等）可以很容易的訪問和抓取數據（爬蟲私密信息有風險哈）。用戶的個人信息，社交網絡，地理位置，用戶生成的數據和用戶操作日誌已經成倍的增加。我們如果要對這些用戶數據進行挖掘，那SQL數據庫已經不適合這些應用了, NoSQL數據庫的發展也不能很好的處理這些大的數據。

NoSql的優缺點

優點

• 易擴展 ： NoSQL數據庫種類繁多，但是一個共同的特點都是去掉關係數據庫的關係型特性。數據之間無關係，這樣就非常容易擴展。也無形之間，在架構的層面上帶來了可擴展的能力。
• 大數據量高性能：NoSQL數據庫都具有非常高的讀寫性能，尤其在大數據量下，同樣表現優秀。這得益於它的無關係性，數據庫的結構簡單。一般MySQL使用Query Cache，每次表的更新Cache就失效，是一種大粒度的Cache，在針對web2.0的交互頻繁的應用，Cache性能不高。而NoSQL的Cache是記錄級的，是一種細粒度的Cache，所以NoSQL在這個層面上來說就要性能高很多了
• 多樣靈活的數據模型：NoSQL無需事先爲要存儲的數據建立字段，隨時可以存儲自定義的數據格式。而在關係數據庫裏，增刪字段是一件非常麻煩的事情。如果是非常大數據量的表，增加字段簡直就是一個噩夢

缺點

• 沒有標準化
• 有限的查詢功能（到目前爲止）
• 最終一致是不直觀的程序

傳統RDBMS VS NOSQL：

RDBMS

• 高度組織化結構化數據
• 結構化查詢語言（SQL）
• 數據和關係都存儲在單獨的表中。
• 數據操縱語言，數據定義語言
• 嚴格的一致性
• 基礎事務

NoSQL

• 代表着不僅僅是SQL
• 沒有聲明性查詢語言
• 沒有預定義的模式
• 鍵 - 值對存儲，列存儲，文檔存儲，圖形數據庫
• 最終一致性，而非ACID屬性
• 非結構化和不可預知的數據
• CAP定理
• 高性能，高可用性和可伸縮性

3V+3高

• 大數據時代的3V（海量Volume、多樣Variety、實時Velocity）
• 互聯網需求的3高（高併發、高可擴、高性能）

NoSQL數據模型簡介

聚合模型

• KV鍵值
• bson：BSON（）是一種類json的一種二進制形式的存儲格式，簡稱Binary JSON，它和JSON一樣，支持內嵌的文檔對象和數組對象
• 列族：顧名思義，是按列存儲數據的。最大的特點是方便存儲結構化和半結構化數據，方便做數據壓縮，對針對某一列或者某幾列的查詢有非常大的IO優勢。
• 圖形：

NoSQL數據庫的四大分類

KV鍵值：

​ 新浪：BerkeleyDB+redis

​ 美團：redis+tair

​ 阿里、百度：memcache+redis

文檔型數據庫(bson格式比較多)：

CouchDB

MongoDB：MongoDB 是一個基於分佈式文件存儲的數據庫。由 C++ 語言編寫。旨在爲 WEB 應用提供可擴展的高性能數據存儲解決方案。MongoDB 是一個介於關係數據庫和非關係數據庫之間的產品，是非關係數據庫當中功能最豐富，最像關係數據庫的。

列存儲數據庫

Cassandra, HBase

分佈式文件系統

圖關係數據庫

它不是放圖形的，放的是關係比如:朋友圈社交網絡、廣告推薦系統、社交網絡，推薦系統等。專注於構建關係圖譜

Neo4J, InfoGrid

四者對比

在分佈式數據庫中CAP原理CAP+BASE

傳統的ACID

A (Atomicity) 原子性

C (Consistency) 一致性

I (Isolation) 獨立性

D (Durability) 持久性

CAP

C (Consistency) 強一致性——所有節點在同一時間具有相同的數據

A (Availability) 可用性——保證每個請求不管成功或者失敗都有響應

P (Partition tolerance) 分區容錯性——系統中任意信息的丟失或失敗不會影響系統的繼續運作

CAP理論的核心是：一個分佈式系統不可能同時很好的滿足一致性，可用性和分區容錯性這三個需求，最多隻能同時較好的滿足兩個。而由於當前的網絡硬件肯定會出現延遲丟包等問題，所以分區容忍性是我們必須需要實現的。我們稱之爲**CAP的3進2，**所以我們只能在一致性和可用性之間進行權衡，沒有NoSQL系統能同時保證這三點。

因此，根據 CAP 原理將 NoSQL 數據庫分成了滿足 CA 原則、滿足 CP 原則和滿足 AP 原則三大類：

• CA - 單點集羣，滿足一致性，可用性的系統，通常在可擴展性上不太強大。傳統Oracle數據庫
• CP - 滿足一致性，分區容忍性的系統，通常性能不是特別高。Redis、Mongodb
• AP - 滿足可用性，分區容忍性的系統，通常可能對一致性要求低一些。大多數網站架構的選擇

?> 注意

分佈式架構的時候必須做出取捨：一致性和可用性之間取一個平衡。多餘大多數web應用，其實並不需要強一致性。因此犧牲C換取P，這是目前分佈式數據庫產品的方向

一致性與可用性的決擇：對於web2.0網站來說，關係數據庫的很多主要特性卻往往無用武之地

數據庫事務一致性需求 ：很多web實時系統並不要求嚴格的數據庫事務，對讀一致性的要求很低， 有些場合對寫一致性要求並不高。允許實現最終一致性。

數據庫的寫實時性和讀實時性需求：對關係數據庫來說，插入一條數據之後立刻查詢，是肯定可以讀出來這條數據的，但是對於很多web應用來說，並不要求這麼高的實時性，比方說發一條消息之 後，過幾秒乃至十幾秒之後，我的訂閱者纔看到這條動態是完全可以接受的。

對複雜的SQL查詢，特別是多表關聯查詢的需求 ：任何大數據量的web系統，都非常忌諱多個大表的關聯查詢，以及複雜的數據分析類型的報表查詢，特別是SNS類型的網站，從需求以及產品設計角度，就避免了這種情況的產生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大的弱化了。

BASE是什麼

BASE就是爲了解決關係數據庫強一致性引起的的可用性降低問題而提出的方案。

BASE其實是下面三個術語的縮寫：

• 基本可用（Basically Available）

• 軟狀態（Soft state）

• 最終一致（Eventually consistent）

它的思想是通過讓系統放鬆對某一時刻數據一致性的要求來換取系統整體伸縮性和性能上改觀。爲什麼這麼說呢，緣由就在於大型系統往往由於地域分佈和極高性能的要求，不可能採用分佈式事務來完成這些指標，要想獲得這些指標，我們必須採用另外一種方式來完成，這裏BASE就是解決這個問題的辦法

分佈式+集羣簡介

分佈式系統（distributed system）

由多臺計算機和通信的軟件組件通過計算機網絡連接（本地網絡或廣域網）組成。分佈式系統是建立在網絡之上的軟件系統。正是因爲軟件的特性，所以分佈式系統具有高度的內聚性和透明性。因此，網絡和分佈式系統之間的區別更多的在於高層軟件（特別是操作系統），而不是硬件。分佈式系統可以應用在在不同的平臺上如：PC、工作站、局域網和廣域網上等。

分佈式計算的優點

• 可靠性（容錯） ：分佈式計算系統中的一個重要的優點是可靠性。一臺服務器的系統崩潰並不影響到其餘的服務器。

• 可擴展性：在分佈式計算系統可以根據需要增加更多的機器。

• 資源共享：共享數據是必不可少的應用，如銀行，預訂系統。

• 靈活性：由於該系統是非常靈活的，它很容易安裝，實施和調試新的服務。

• 更快的速度：分佈式計算系統可以有多臺計算機的計算能力，使得它比其他系統有更快的處理速度。

• 開放系統：由於它是開放的系統，本地或者遠程都可以訪問到該服務。

• 更高的性能：相較於集中式計算機網絡集羣可以提供更高的性能（及更好的性價比）。

分佈式計算的缺點

• 故障排除： 故障排除和診斷問題。

• 軟件：更少的軟件支持是分佈式計算系統的主要缺點。

• 網絡：網絡基礎設施的問題，包括：傳輸問題，高負載，信息丟失等。

• 安全性：開發系統的特性讓分佈式計算系統存在着數據的安全性和共享的風險等問題。

由於它是開放的系統，本地或者遠程都可以訪問到該服務。

• 更高的性能：相較於集中式計算機網絡集羣可以提供更高的性能（及更好的性價比）。

分佈式計算的缺點

• 故障排除： 故障排除和診斷問題。

• 軟件：更少的軟件支持是分佈式計算系統的主要缺點。

• 網絡：網絡基礎設施的問題，包括：傳輸問題，高負載，信息丟失等。

• 安全性：開發系統的特性讓分佈式計算系統存在着數據的安全性和共享的風險等問題。