Nosql

時間 2019-11-09

標籤 nosql 欄目 NoSQL 简体版

原文原文鏈接

單機MySQL的美好時代

在90年代，一個網站的訪問量通常都不大，用單個數據庫徹底能夠輕鬆應付。
在那個時候，更多的都是靜態網頁，動態交互類型的網站很少
初期架構 | centerhtml
DAL，（Data Access Layer）。其功能主要是負責數據庫的訪問。簡單地說就是實現對數據表的Select（查詢）、Insert（插入）、Update（更新）、Delete（刪除）等操做。
上述架構下，咱們來看看數據存儲的瓶頸是什麼？
- 一、數據量的總大小一個機器放不下時。（表要佔空間，表的索引要佔空間）
- 二、數據的索引（B+ Tree樹）一個機器的內存放不下時庫

若是知足了上述1 or 3個，則須要進化..java

Memcached(緩存,java上還有一個ehcache)+MySQL+垂直拆分

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

在這個時候，Memcached就天然的成爲一個很是時尚的技術產品。nginx

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

Mysql主從讀寫分離

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

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

在Memcached的高速緩存，MySQL的主從複製，讀寫分離的基礎之上，這時MySQL主庫的寫壓力開始出現瓶頸，而數據量的持續猛增，因爲MyISAM使用表鎖，在高併發下會出現嚴重的鎖問題，大量的高併發MySQL應用開始使用InnoDB引擎代替MyISAM。程序員
什麼是表鎖和行鎖，表鎖就是當一個事件在用這個表的時候，其餘的表候着，等於說把這個表鎖住了。就像去上衛生間把門先鎖上，行鎖也是這樣理解，表中有不少行，我使用的那個行，被我鎖住，其餘的事件不能用這個行。innodb就是使用的行鎖，而myISAM使用的是表鎖。行鎖相對於表鎖，限制少，因此行鎖的高併發高，因此用了inonodb
同時，開始流行使用分表分庫（就是儘量的緊耦合把業務相關的分在一塊兒，好比說用戶的身份證號碼。註冊信息都是長期補變的，這些數據都是一些趨於冷的冷數據，因此通常狀況下這些長期不變的數據放在一塊兒庫，而一些高度活躍的數據放在一個庫，分表指的是一部分表和分庫是同樣的原理）來緩解寫壓力和數據增加的擴展問題。這個時候，分表分庫成了一個熱門技術，是面試的熱門問題也是業界討論的熱門技術問題。也就在這個時候，MySQL推出了還不太穩定的表分區，這也給技術實力通常的公司帶來了但願。雖然MySQL推出了MySQL Cluster（這個單詞就是集羣的意思）集羣，但性能也不能很好知足互聯網的要求，只是在高可靠性上提供了很是大的保證web

MySQL的擴展性瓶頸

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

今天是什麼樣子

這張圖最開始是用戶，第二個是防火牆，第三個是nginx，表示反向代理服務器（反向代理就是根據客戶端的要求從本身關聯的一組或者多組服務器獲取資源進而反饋給客戶端，反向代理就是充當了服務端的代理，正常的代理服務器都是從客戶端到服務端，代理的是客戶端，隱藏真實的客戶，爲客戶端收發請求，使真實客戶端對服務器不可見，這而反向的代理的是服務端，獲取服務器ip的時候獲取的是反向代理服務器的IP,），用來處理負載均衡(負載均衡就是將請求分發到各個服務器)。

nginx 這個輕量級、高性能的 web server 主要能夠幹兩件事情：

　　〉直接做爲http server(代替apache，對PHP須要FastCGI處理器支持)；
　　〉另一個功能就是做爲反向代理服務器實現負載均衡

　　由於nginx在處理併發方面的優點，如今這個應用很是常見。固然了Apache的 mod_proxy和mod_cache結合使用也能夠實現對多臺app server的反向代理和負載均衡，可是在併發處理方面apache仍是沒有 nginx擅長。

爲何用NOSQL,

今天用戶生成的數據和用戶操做日誌已經成倍的增長，傳統的SQl數據庫已經難覺得繼

NoSQL是什麼

NoSQL(NoSQL = Not Only SQL )，意即「不只僅是SQL」，泛指非關係型的數據庫。隨着互聯網 web2.0網站的興起，傳統的關係數據庫在應付 web2.0網站，特別是超大規模和高併發的 SNS類型的 web2.0純動態網站已經顯得力不從心，暴露了不少難以克服的問題，而非關係型的數據庫則因爲其自己的特色獲得了很是迅速的發展。 NoSQL數據庫的產生就是爲了解決大規模數據集合多重數據種類帶來的挑戰，尤爲是大數據應用難題。

例如谷歌天天處理上萬億的比特的數據，這些類型的數據存儲不須要固定的模式，無需多餘的操做就能夠橫向擴展。

NoSQL能幹什麼

NoSQL，有三大重要的特性：

易擴展

大數據量高性能

多樣靈活的數據模型

易擴展： NoSQL數據庫種類繁多，可是一個共同的特色都是去掉關係數據庫的關係型特性。數據之間無關係，這樣就很是容易擴展。

也無形之間，在架構的層面上帶來了可擴展的能力。

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

多樣靈活的數據模型：NoSQL無需事先爲要存儲的數據創建字段，隨時能夠存儲自定義的數據格式。而在關係數據庫裏，增刪字段是一件很是麻煩的事情（）。若是是很是大數據量的表，增長字段簡直就是一個噩夢，字段就是表的索引，由於在mysql中是表結構，而Nosql是字典結構。redis

NoSQL的3V+3高（這個怎麼記憶,v描述的是數據多，高描述的是性能好，）想像一下的如今的數據是類型多，數量大，實時性高（實時性不太容易想起來），性能表示的是高併發，高擴展，高性能。海量數據的應用（淘寶，微信，等等）

大數據時代的3V：算法
- 海量Volume
- 多樣Variety
- 實時Velocity
Volume、Variety、Velocity。這3V代表大數據的三方面特質：量大、多樣、實時。對，不光是數據量大了。對TB、PB數據級的處理，已經成爲基本配置。還能處理多樣性的數據類型，結構化數據和非結構化數據，能處理Web數據，能處理語音數據甚至是圖像、視頻數據。實時。之前的決策支持時代，能夠用批量處理的方式，隔夜處理數據，等決策者次日上班，能夠看到昨天的經營數據。但如今的互聯網時代，業務在24小時不間斷運營，決策已經不是次日上班才作出，而是在客戶每次瀏覽頁面，每次下訂單的過程當中都存在，都會須要對用戶進行實時的推薦，決策已經變得實時。sql

互聯網需求的3高
- 高併發
- 高可擴
- 高性能

當下Nosql的應用
當下是sql和Nosql一塊兒使用，阿里巴巴中文網站的商品信息如何存放。

講一下ali巴巴的網站的演變過程：

1》架構發展過程

5代開發的緣由：爲了開放，讓用戶參與進來

淘寶的數據架構的日益複雜性：

NoSQL數據模型簡介

NoSQL聚合模型和 NoSQL數據庫的四大分類：
- NoSQL聚合模型
  - KV鍵值
  - Bson（與java中的json（java程序與mysql等數據庫鏈接的中間橋樑）相似的一種二進制形式的存儲格式，簡稱binary JSon）
  - 列族
  - 圖形
NoSQL數據庫的四大分類：
- KV鍵值：這一類數據庫主要會使用到一個哈希表，這個表中有一個特定的鍵和一個指針指向特定的數據。Key/value模型對於IT系統來講的優點在於簡單、易部署。可是若是DBA只對部分值進行查詢或更新的時候，Key/value就顯得效率低下了。舉例如：Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB.
- 文檔型數據庫(bson格式比較多)：文檔型數據庫的靈感是來自於Lotus Notes辦公軟件的，並且它同第一種鍵值存儲相相似。該類型的數據模型是版本化的文檔，半結構化的文檔以特定的格式存儲，好比JSON。文檔型數據庫可以看做是鍵值數據庫的升級版，容許之間嵌套鍵值。並且文檔型數據庫比鍵值數據庫的查詢效率更高。如：CouchDB, MongoDb. 國內也有文檔型數據庫SequoiaDB，已經開源。
- 列存儲數據庫：這部分數據庫一般是用來應對分佈式存儲的海量數據。鍵仍然存在，可是它們的特色是指向了多個列。這些列是由列家族來安排的。如：Cassandra, HBase, Riak.
- 圖關係數據庫：圖形結構的數據庫同其餘行列以及剛性結構的SQL數據庫不一樣，它是使用靈活的圖形模型，而且可以擴展到多個服務器上。NoSQL數據庫沒有標準的查詢語言(SQL)，所以進行數據庫查詢須要制定數據模型。許多NoSQL數據庫都有REST式的數據接口或者查詢API。如：Neo4J, InfoGrid, Infinite Graph.

四大分類的典型介紹：

KV鍵值：典型介紹

新浪：BerkeleyDB+redis

美團：redis+tair

阿里、百度：memcache+redis

文檔型數據庫：典型介紹CouchDB MongoDB

列存儲數據庫 Cassandra, HBase

分佈式文件系統

圖關係數據庫它不是放圖形的，放的是關係好比:朋友圈社交網絡，廣告推薦系統社交網絡，推薦系統等。專一於構建關係圖譜 Neo4J, InfoGrid

若是隻想高速緩存就是memcached，而若是還想兼顧其餘，數據類型豐富，redis和tair更加出色

什麼狀況下能夠用聚合模型來處理：
- 高併發的操做是不太建議有關聯查詢的，互聯網公司用冗餘數據來避免關聯查詢。
- 分佈式事務是支持不了太多的併發的

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

SQL 和 NoSQL

SQL和NOSQL特性 | center

SQL特性介紹
- A：（Atomicity）原子性:
  - 整個事務中的全部操做，要麼所有完成，要麼所有不完成，不可能停滯在中間某個環節。事務在執行過程當中發生錯誤，會被回滾（Rollback）到事務開始前的狀態，就像這個事務歷來沒有執行過同樣。
- C：（Consistency）一致性
  - 一個事務能夠封裝狀態改變（除非它是一個只讀的）。事務必須始終保持系統處於一致的狀態，無論在任何給定的時間併發事務有多少。
  - 也就是說：若是事務是併發多個，系統也必須如同串行事務同樣操做。其主要特徵是保護性和不變性(Preserving an Invariant)，
    - 以轉帳案例爲例，假設有五個帳戶，每一個帳戶餘額是100元，那麼五個帳戶總額是500元，若是在這個5個帳戶之間同時發生多個轉帳，不管併發多少個，好比在A與B帳戶之間轉帳5元，在C與D帳戶之間轉帳10元，在B與E之間轉帳15元，五個帳戶總額也應該仍是500元，這就是保護性和不變性
- I：（Isolation）隔離性
  - 隔離狀態執行事務，使它們好像是系統在給定時間內執行的惟一操做。若是有兩個事務，運行在相同的時間內，執行相同的功能，事務的隔離性將確保每一事務在系統中認爲只有該事務在使用系統。這種屬性有時稱爲串行化，爲了防止事務操做間的混淆，必須串行化或序列化請求，使得在同一時間僅有一個請求用於同一數據。
- D：（Durability）持久性
  - 在事務完成之後，該事務對數據庫所做的更改便持久的保存在數據庫之中，並不會被回滾。

acid怎麼記憶：給原子寫個故事，原子一致，持久隔離（咱們原子都是一致的，是持久的隔離開的，化學中，原子在化學反應中不可分割，因此根據化學的方法來記憶）

NoSQL特性介紹
- C：（Consistency）強一致性
  - 任何一個讀操做老是能讀取到以前完成的寫操做結果，也就是在分佈式環境中，多點的數據是一致的;
- A：（Availability）高可用性
  - 每個操做老是可以在肯定的時間內返回，也就是系統隨時都是可用的。
- P：（Partition tolerance）分佈式容忍性
  - 在出現網絡分區(好比斷網)的狀況下，分離的系統也能正常運行。
CAP的3進2
- CAP理論就是說在分佈式存儲系統中，最多隻能實現上面的兩點。
  而因爲當前的網絡硬件確定會出現延遲丟包等問題，因此分區容忍性是咱們必須須要實現的。（這個是Nosql必須具有的）
- 因此咱們只能在一致性和可用性之間進行權衡，沒有NoSQL系統能同時保證這三點。
  - C:強一致性 A：高可用性 P：分佈式容忍性
    - CA 傳統Oracle數據庫
    - AP 大多數網站架構的選擇
    - CP Redis、Mongodb
- 注：分佈式架構的時候必須作出取捨。一致性和可用性之間取一個平衡。多餘大多數web應用，其實並不須要強一致性。 所以犧牲C換取P，這是目前分佈式數據庫產品的方向。
- 好比雙十一的時候，基於用戶的大數據，訪問量的巨大，爲了保證網站不崩掉，通常都選擇，實現AP，而數據的一致性，在網站崩掉面前顯得微不足道，固然不是不保證一致性，而是弱一致性加AP，這個弱一致性能夠由關係型數據庫實現，而AP由非關係數據庫實現
- 爲啥只能三選2，而不能都選，這是由於他們之間有衝突，具體見 http://www.d1net.com/bigdata/solution/240330.html
一致性與可用性的決擇
- 對於web2.0網站來講，關係數據庫的不少主要特性卻每每無用武之地
- **數據庫事務一致性需求 **
  - 不少web實時系統並不要求嚴格的數據庫事務，對讀一致性的要求很低，有些場合對寫一致性要求並不高。容許實現最終一致性。
- 數據庫的寫實時性和讀實時性需求
  　* 對關係數據庫來講，插入一條數據以後馬上查詢，是確定能夠讀出來這條數據的，可是對於不少web應用來講，並不要求這麼高的實時性，比方說發一條消息之後，過幾秒乃至十幾秒以後，個人訂閱者纔看到這條動態是徹底能夠接受的。
- *對複雜的SQL查詢，特別是多表關聯查詢的需求 **
  　任何大數據量的web系統，都很是忌諱多個大表的關聯查詢，以及複雜的數據分析類型的報表查詢，特別是SNS類型的網站，從需求以及產品設計角度，就避免了這種狀況的產生。每每更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大的弱化了。
經典CAP圖
- CAP理論的核心是：一個分佈式系統不可能同時很好的知足一致性，可用性和分區容錯性這三個需求，
- 最多隻能同時較好的知足兩個。
- 所以，根據 CAP 原理將 NoSQL 數據庫分紅了知足 CA 原則、知足 CP 原則和知足 AP 原則三大類：
  - CA - 單點集羣，知足一致性，可用性的系統，一般在可擴展性上不太強大。
  - CP - 知足一致性，分區容忍必的系統，一般性能不是特別高。
  - AP - 知足可用性，分區容忍性的系統，一般可能對一致性要求低一些

BASE理論

BASE就是爲了解決關係數據庫強一致性引發的問題而引發的可用性下降而提出的解決方案。
BASE實際上是下面三個術語的縮寫：
- 基本可用（Basically Available）
- 軟狀態（Soft state）
- 最終一致（Eventually consistent）
它的思想是經過讓系統放鬆對某一時刻數據一致性的要求來換取系統總體伸縮性和性能上改觀。爲何這麼說呢，原因就在於大型系統每每因爲地域分佈和極高性能的要求，不可能採用分佈式事務來完成這些指標，要想得到這些指標，咱們必須採用另一種方式來完成，這裏BASE就是解決這個問題的辦法，BASE的最終一致性是最重要的一句話，好比說雙十一的時候，咱們只須要保證基本可用的一致性（稱爲弱一致性），A（高可用性）P（分區容錯）後面這兩個必須保證，然會保證AP，在雙十一完了以後，開發程序員還須要去統計數據的精準，這個就是實現最終一致。

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

擴起來的這些話來自百度百科或者是維基百科，忘了

最終一致性根據更新數據後各進程訪問到數據的時間和方式的不一樣，又能夠區分爲：

因果一致性。若是進程A通知進程B它已更新了一個數據項，那麼進程B的後續訪問將返回更新後的值，且一次寫入將保證取代前一次寫入。與進程A無因果關係的進程C的訪問遵照通常的最終一致性規則。

「讀己之所寫（read-your-writes）」一致性。當進程A本身更新一個數據項以後，它老是訪問到更新過的值，毫不會看到舊值。這是因果一致性模型的一個特例。

會話（Session）一致性。這是上一個模型的實用版本，它把訪問存儲系統的進程放到會話的上下文中。只要會話還存在，系統就保證「讀己之所寫」一致性。若是因爲某些失敗情形令會話終止，就要創建新的會話，並且系統的保證不會延續到新的會話。

單調（Monotonic）讀一致性。若是進程已經看到過數據對象的某個值，那麼任何後續訪問都不會返回在那個值以前的值。

單調寫一致性。系統保證來自同一個進程的寫操做順序執行。要是系統不能保證這種程度的一致性，就很是難以編程了。

上述最終一致性的不一樣方式能夠進行組合，例如單調讀一致性和讀己之所寫一致性就能夠組合實現。而且從實踐的角度來看，這二者的組合，讀取本身更新的數據，和一旦讀取到最新的版本不會再讀取舊版本，對於此架構上的程序開發來講，會少不少額外的煩惱。

從服務端角度，如何儘快將更新後的數據分佈到整個系統，下降達到最終一致性的時間窗口，是提升系統的可用度和用戶體驗很是重要的方面。對於分佈式數據系統：

N — 數據複製的份數
W — 更新數據是須要保證寫完成的節點數
R — 讀取數據的時候須要讀取的節點數

若是W+R>N，寫的節點和讀的節點重疊，則是強一致性。例如對於典型的一主一備同步複製的關係型數據庫，N=2,W=2,R=1，則無論讀的是主庫仍是備庫的數據，都是一致的。

若是W+R<=N，則是弱一致性。例如對於一主一備異步複製的關係型數據庫，N=2,W=1,R=1，則若是讀的是備庫，就可能沒法讀取主庫已經更新過的數據，因此是弱一致性。

對於分佈式系統，爲了保證高可用性，通常設置N>=3。不一樣的N,W,R組合，是在可用性和一致性之間取一個平衡，以適應不一樣的應用場景。

若是N=W,R=1，任何一個寫節點失效，都會致使寫失敗，所以可用性會下降，可是因爲數據分佈的N個節點是同步寫入的，所以能夠保證強一致性。
若是N=R,W=1，只須要一個節點寫入成功便可，寫性能和可用性都比較高。可是讀取其餘節點的進程可能不能獲取更新後的數據，所以是弱一致性。這種狀況下，若是W<(N+1)/2，而且寫入的節點不重疊的話，則會存在寫衝突