NoSql 入門和概述

NoSql

一、NoSql 入門和概述

1、入門概述

1、網際網路時代背景下大機遇，為什麼使用nosql

1、單機時代MySQL的美好年代

在90年代，一個網站的通路量一般都不大，單個資料庫完全可以輕松應付。

在哪個時候，更多的都是靜态網頁，動态互動類型的網站不多。

上述架構下，我們來看看資料存儲的瓶頸是什麼？

1、資料量的總大小一個機器放不下時

2、資料量的索引（B+Tree）一個機器的記憶體放不下時

3、通路量（讀寫混合）一個執行個體不能承受，如果滿足了上述1 or 3 個，進化…

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、今天是什麼樣子的？？？

7、為什麼使用Nosql？

今天我們可以通過第三方平台（如Google，Facebook等）可以很容易的通路和抓取資料。使用者的個人資訊，社交網絡，地理位置，使用者生成的資料和使用者記錄檔已經成倍的增加。我們如果要對這些使用者資料進行挖掘，那SQL資料庫已經不适合這些應用了，NoSQL資料庫的發展卻能很好的處理這些大的資料。

2 什麼是NoSQL

NoSQL(NoSQL = Not Only SQL)，即“不僅僅是SQL”，

泛指非關系型的資料庫。随着網際網路web2.0網站的興起，傳統的關系資料庫在應付web2.0網站，特别是超大規模和高并發的SNS類型的web2.0純動态網站已經顯得力不從心，暴露了很多難以克服的問題，而非關系型的資料庫則

由于其本身的特點得到了非常迅速的發展。NoSQL資料庫的産生就是為了，解決大規模資料集合多重資料種類帶來的挑戰，尤其是大資料應用難題，包括超大規模資料的存儲。

例如谷歌或Facebook每天為他們的使用者收集萬億比特的資料）。這些類型的資料存儲不需要固定的模式，無需多餘操作就可以橫向擴充

3、Nosql能幹嘛？

1、易擴充

NoSQL資料庫種類繁多，但是一個共同的特點都是去掉關系資料庫的關系型特性。資料之間無關系，這樣就非常容易擴充。也無形之間，在架構的層面上帶來了可擴充的能力。

2、大資料量高性能

NoSQL資料庫都具有非常高的讀寫性能，尤其在大資料量下，同樣表現優秀。

這得益于它的無關系性，資料庫的結構簡單。

一般MySQL使用Query Cache，每次表的更新Cache就失效，是一種大粒度的Cache，在針對web2.0的互動頻繁的應用，Cache性能不高。而NoSQL的Cache是記錄級的，是一種細粒度的Cache，是以NoSQL在這個層面上來說就要性能高很多了。

3、多樣靈活的資料模型

NoSQL無需事先為要存儲的資料建立字段，随時可以存儲自定義的資料格式。而在關系資料庫裡，增删字段是一件非常麻煩的事情。如果是非常大資料量的表，增加字段簡直就是一個噩夢。

4、傳統的RDBMS VS NoSQL

RDBMS VS NoSQL

RDBMS

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

NoSQL

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

4、常見的NoSQL

• Redis
• Memcached
• Mongdb

2 、時代發展需求（3V+3高）

1、大資料時代的3V

• 海量Volume
• 多樣Variety
• 實時Velocity

2、網際網路需求的3高

• 高并發
• 高可擴
• 高性能

3、當下的NoSQL經典應用

3、NoSQL資料模型簡介

以一個電商客戶、訂單訂購、位址模型來對比下關系型資料庫和非關系型資料庫。

傳統的關系型資料庫你如何設計?

ER圖（1:1/1:N/N:N，主外鍵等常見）

NoSQL你如何設計

什麼是BSON

BSON是一種類json的一種二進制形式的存儲格式，簡稱Binary JSON，它和JSON一樣，支援内嵌的文檔對象和數組對象

{
 "customer":{
   "id":1136,
   "name":"Z3",
   "billingAddress":[{"city":"beijing"}],
   "orders":[
    {
      "id":17,
      "customerId":1136,
      "orderItems":[{"productId":27,"price":77.5,"productName":"thinking in java"}],
      "shippingAddress":[{"city":"beijing"}]
      "orderPayment":[{"ccinfo":"111-222-333","txnid":"asdfadcd334","billingAddress":{"city":"beijing"}}],
      }
    ]
  }
}

           

兩者對比，問題和難點

為什麼上述的情況可以用聚合模型來處理

• 高并發的操作是不太建議有關聯查詢的，網際網路公司用備援資料來避免關聯查詢
• 分布式事務是支援不了太多的并發的

聚合模型

• kv鍵值

• Bson

  列族

  顧名思義，是按列存儲資料的。最大的特點是友善存儲結構化和半結構化資料，友善做資料壓縮，針對某一些列或者某幾列的查詢有非常大的IO優勢。

  

  圖形

  

5、NoSQL資料庫的四大分類

MongoDB：

MongoDB 是一個基于分布式檔案存儲的資料庫。由 C++ 語言編寫。旨在為 WEB 應用提供可擴充的高性能資料存儲解決方案。

MongoDB 是一個介于關系資料庫和非關系資料庫之間的産品，是非關系資料庫當中功能最豐富，最像關系資料庫的。

6、在分布式資料庫中CAP原理CAP+BASE

傳統的ACID分别是什麼

關系型資料庫遵循ACID規則

事務在英文中是transaction，和現實世界中的交易很類似，它有如下四個特性：

1、A (Atomicity) 原子性

原子性很容易了解，也就是說事務裡的所有操作要麼全部做完，要麼都不做，事務成功的條件是事務裡的所有操作都成功，隻要有一個操作失敗，整個事務就失敗，需要復原。比如銀行轉賬，從A賬戶轉100元至B賬戶，分為兩個步驟：1）從A賬戶取100元；2）存入100元至B賬戶。這兩步要麼一起完成，要麼一起不完成，如果隻完成第一步，第二步失敗，錢會莫名其妙少了100元。

2、C (Consistency) 一緻性

一緻性也比較容易了解，也就是說資料庫要一直處于一緻的狀态，事務的運作不會改變資料庫原本的一緻性限制。

3、I (Isolation) 獨立性

所謂的獨立性是指并發的事務之間不會互相影響，如果一個事務要通路的資料正在被另外一個事務修改，隻要另外一個事務未送出，它所通路的資料就不受未送出事務的影響。比如現有有個交易是從A賬戶轉100元至B賬戶，在這個交易還未完成的情況下，如果此時B查詢自己的賬戶，是看不到新增加的100元的

4、D (Durability) 持久性

持久性是指一旦事務送出後，它所做的修改将會永久的儲存在資料庫上，即使出現當機也不會丢失。

CAP的3進2

CAP理論就是說在分布式存儲系統中，最多隻能實作上面的兩點。

而由于目前的網絡硬體肯定會出現延遲丢包等問題，是以

分區容忍性是我們必須需要實作的。

是以我們隻能在一緻性和可用性之間進行權衡，沒有NoSQL系統能同時保證這三點。

C:強一緻性 A：高可用性 P：分布式容忍性

CA 傳統Oracle資料庫

AP 大多數網站架構的選擇

CP Redis、Mongodb

注意：分布式架構的時候必須做出取舍。

一緻性和可用性之間取一個平衡。多餘大多數web應用，其實并不需要強一緻性。

是以犧牲C換取P，這是目前分布式資料庫産品的方向

一緻性與可用性的決擇

對于web2.0網站來說，關系資料庫的很多主要特性卻往往無用武之地

資料庫事務一緻性需求

　　很多web實時系統并不要求嚴格的資料庫事務，對讀一緻性的要求很低， 有些場合對寫一緻性要求并不高。允許實作最終一緻性。

資料庫的寫實時性和讀實時性需求

　　對關系資料庫來說，插入一條資料之後立刻查詢，是肯定可以讀出來這條資料的，但是對于很多web應用來說，并不要求這麼高的實時性，比方說發一條消息之 後，過幾秒乃至十幾秒之後，我的訂閱者才看到這條動态是完全可以接受的。

對複雜的SQL查詢，特别是多表關聯查詢的需求

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

經典CAP圖

base是什麼

BASE就是為了解決關系資料庫強一緻性引起的問題而引起的可用性降低而提出的解決方案。

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

基本可用（Basically Available）

軟狀态（Soft state）

最終一緻（Eventually consistent）

它的思想是通過讓系統放松對某一時刻資料一緻性的要求來換取系統整體伸縮性和性能上改觀。為什麼這麼說呢，緣由就在于大型系統往往由于地域分布和極高性能的要求，不可能采用分布式事務來完成這些名額，要想獲得這些名額，我們必須采用另外一種方式來完成，這裡BASE就是解決這個問題的辦法

分布式+叢集簡介

分布式系統

分布式系統（distributed system）

由多台計算機和通信的軟體元件通過計算機網絡連接配接（本地網絡或廣域網）組成。分布式系統是建立在網絡之上的軟體系統。正是因為軟體的特性，是以分布式系統具有高度的内聚性和透明性。是以，網絡和分布式系統之間的差別更多的在于高層軟體（特别是作業系統），而不是硬體。分布式系統可以應用在在不同的平台上如：Pc、工作站、區域網路和廣域網上等。

簡單來講：

1分布式：不同的多台伺服器上面部署不同的服務子產品（工程），他們之間通過Rpc/Rmi之間通信和調用，對外提供服務群組内協作。

2叢集：不同的多台伺服器上面部署相同的服務子產品，通過分布式排程軟體進行統一的排程，對外提供服務和通路。

）

由多台計算機和通信的軟體元件通過計算機網絡連接配接（本地網絡或廣域網）組成。分布式系統是建立在網絡之上的軟體系統。正是因為軟體的特性，是以分布式系統具有高度的内聚性和透明性。是以，網絡和分布式系統之間的差別更多的在于高層軟體（特别是作業系統），而不是硬體。分布式系統可以應用在在不同的平台上如：Pc、工作站、區域網路和廣域網上等。

簡單來講：

1分布式：不同的多台伺服器上面部署不同的服務子產品（工程），他們之間通過Rpc/Rmi之間通信和調用，對外提供服務群組内協作。

2叢集：不同的多台伺服器上面部署相同的服務子產品，通過分布式排程軟體進行統一的排程，對外提供服務和通路。

以上知識大部分來源于尚矽谷，個人隻是把知識整理了一番