你應該瞭解的一些資料庫概念！RDBMS vs NoSQL，分散式 vs 叢集 ，分割槽 分表 分片 分庫

早就想寫一篇資料庫概念類的文章，奈何本人能力實在有限，難以著筆。但實在又想多多瞭解資料庫方面知識，開拓瞭解更多相關理念，還是盡力收集一些資料彌合起來。我沒有發現知識，我只是收集一些我想了解的知識。本文前部分主要 根據五月的倉頡的《Sql Or NoSql，看完這一篇你就懂了》此文展開，加上自己知識盲區的部分補充！僅僅作為備忘記錄。

1️⃣資料儲存結構

資料庫，顧名思義是用來存取資料的。然而資料型別眾多，比如：文字、圖片、HTML、各類報表、視音訊等等，不同的資料儲存結構，會很大程度影響了資料庫引擎的選型。沒有一種事物是完美的，資料庫也一樣，有些資料庫擅長存取結構化的資料，有些則擅長存取非結構化的資料。為什麼擅長？因為需要，所以也會擯棄，做出權衡！下面瞭解一下資料儲存結構分類：

• 結構化資料
  結構化資料指的是由二維表結構來邏輯表達和實現的資料，嚴格遵循資料格式與長度規範，也稱作為行資料，特點為：資料以行為單位，一行資料表示一個實體的資訊，每一行資料的屬性是相同的。
  因為關係型資料庫完美契合結構化資料的特點，關係型資料庫也是關係型資料最主要的儲存與管理引擎。
• 半結構化資料
  不符合二維邏輯這種資料模型結構，但是包含相關標記，用來分割語義元素以及對記錄和欄位進行分層。常見的半結構化資料有XML和JSON。

<person>
    <name>張三</name>
    <age>18</age>
    <phone>12345</phone>
</person>

• 非結構化資料
  資料結構不規則或不完整，沒有任何預定義的資料模型，不方便用二維邏輯表來表現的資料。例如辦公文件（Word）、文字、圖片、HTML、視訊音訊等。

2️⃣NoSQL 體系介紹

關聯式資料庫自不必多說了，相信各位入門第一種資料庫課程就是關係型的資料庫。

NoSql的全稱為Not Only SQL，泛指非關係型資料庫，是對關係型資料庫的一種補充，特別注意補充這兩個字，這意味著NoSql與關係型資料庫並不是對立關係，二者各有優劣，取長補短，在合適的場景下選擇合適的儲存引擎才是正確的做法。

2.1❀ NoSQL 資料庫分類

型別	部分代表	特點
列儲存	1.Hbase 2.Cassandra 3.Hypertable	按列儲存資料的。最大的特點是方便儲存結構化和半結構化資料，方便做資料壓縮，對針對某一列或者某幾列的查詢有非常大的IO優勢。
文件儲存	1.MongoDB 2.CouchDB	文件儲存一般用類似json的格式儲存，儲存的內容是文件型的。這樣也就有機會對某些欄位建立索引，實現關聯式資料庫的某些功能。
key-value儲存	1.Redis 2.MemcacheDB	可以通過key快速查詢到其value。一般來說，儲存不管value的格式，照單全收。
搜尋型	ElasticSearch	全文搜尋能力強
圖儲存	1.Neo4J 2.FlockDB	圖形關係的最佳儲存。使用傳統關聯式資料庫來解決的話效能低下，而且設計使用不方便。
物件儲存	1.db4o 2.Versant	通過類似面嚮物件語言的語法運算元據庫，通過物件的方式存取資料。
xml資料庫	1.Berkeley DB XML 2.BaseX	高效的儲存XML資料，並支援XML的內部查詢語法，比如XQuery,Xpath。

2.2❀ 幾種常用NoSql講解

Redis
Redis又是KV型NoSql中應用最廣泛的NoSql。
優點：高效能（TPS 10萬級別）

• 資料基於記憶體，讀寫效率高
• KV型資料，時間複雜度為O(1)，查詢速度快

缺點：

• 只能根據K查V，無法根據V查K
• 查詢方式單一，只有KV的方式，不支援條件查詢，多條件查詢唯一的做法就是資料冗餘，但這會極大的浪費儲存空間
• 記憶體是有限的，無法支援海量資料儲存
• 由於KV型NoSql的儲存是基於記憶體的，會有丟失資料的風險

適用場景：快取

• 讀遠多於寫
• 沒有持久化的需求，可以容忍資料丟失，反正丟了再查詢一把寫入就是了
  例如根據使用者id查詢使用者資訊，每次根據使用者id去快取中查詢一把，查到資料直接返回，查不到去關係型資料庫裡面根據id查詢一把資料寫到快取中去。

MongoDB
文件型NoSql是沒有Schema的，由於沒有Schema的特性，我們可以隨意地儲存與讀取資料，因此文件型NoSql的出現是解決關係型資料庫表結構擴充套件不方便的問題的。

優點：

• 沒有預定義的欄位，擴充套件欄位容易
• 相較於關係型資料庫，讀寫效能優越，命中二級索引的查詢不會比關係型資料庫慢，對於非索引欄位的查詢則是全面勝出

缺點：

• 空間佔用較大，這個是MongDB的設計問題，空間預分配機制 + 刪除資料後空間不釋放，只有用db.repairDatabase()去修復才能釋放
• 多表之間的關聯查詢不支援（雖然有嵌入文件的方式），join查詢還是需要多次操作

適用場景：

MongDB的使用場景很大程度上可以對標關係型資料庫，但是比較適合處理那些沒有join、沒有強一致性要求且表Schema會常變化的資料。

ElasticSearch

傳統關係型資料庫主要通過索引來達到快速查詢的目的，但是在全文搜尋的場景下，索引是無能為力的，like查詢一來無法滿足所有模糊匹配需求，二來使用限制太大且使用不當容易造成慢查詢，搜尋型NoSql的誕生正是為了解決關係型資料庫全文搜尋能力較弱的問題

全文搜尋的原理是倒排索引，我們看一下什麼是倒排索引。要說倒排索引我們先看下什麼是正排索引，傳統的正排索引是文件–>關鍵字的對映，例如"Tom is my friend"這句話，會將其切分為"Tom"、“is”、“my”、"friend"四個單詞，在搜尋的時候對文件進行掃描，符合條件的查出來。這種方式原理非常簡單，但是由於其檢索效率太低，基本沒什麼實用價值。

倒排索引則完全相反，它是關鍵字–>文件的對映，我用張表格展示一下就比較清楚了：

意思是我現在這裡有四個短句：

• “Tom is Tom”
• “Tom is my friend”
• “Thank you, Betty”
• “Tom is Betty’s husband”

搜尋引擎會根據一定的切分規則將這句話切成N個關鍵字，並以關鍵字的維度維護關鍵字在每個文字中的出現次數。這樣下次搜尋"Tom"的時候，由於Tom這個詞語在"Tom is Tom"、“Tom is my friend”、"Tom is Betty’s husband"三句話中都有出現，因此這三條記錄都會被檢索出來，且由於"Tom is Tom"這句話中"Tom"出現了2次，因此這條記錄對"Tom"這個單詞的匹配度最高，最先展示。這就是搜尋引擎倒排索引的基本原理，假設某個關鍵字在某個文件中出現，那麼倒排索引中有兩部分內容：

• 文件ID
• 在該文件中出現的位置情況

可以舉一反三，我們搜尋"Betty Tom"這兩個詞語也是一樣，搜尋引擎將"Betty Tom"切分為"Tom"、"Betty"兩個單詞，根據開發者指定的滿足率，比如滿足率=50%，那麼只要記錄中出現了兩個單詞之一的記錄都會被檢索出來，再按照匹配度進行展示。

優點：

• 支援分詞場景、全文搜尋，這是區別於關係型資料庫最大特點
• 支援條件查詢，支援聚合操作，類似關係型資料庫的Group By，但是功能更加強大，適合做資料分析
• 資料寫檔案無丟失風險，在叢集環境下可以方便橫向擴充套件，可承載PB級別的資料
• 高可用，自動發現新的或者失敗的節點，重組和重新平衡資料，確保資料是安全和可訪問的

缺點：

• 效能全靠記憶體來頂，也是使用的時候最需要注意的點，非常吃硬體資源、吃記憶體，大資料量下64G + SSD基本是標配，算得上是資料庫中的愛馬仕了。至於ElasticSearch記憶體用在什麼地方，大概有如下這些：
  1. Indexing Buffer----ElasticSearch基於Luence，Lucene的倒排索引是先在記憶體裡生成，然後定期以Segment File的方式刷磁碟的，每個Segment File實際就是一個完整的倒排索引
  2.Segment Memory----倒排索引前面說過是基於關鍵字的，Lucene在4.0後會將所有關鍵字以FST這種資料結構的方式將所有關鍵字在啟動的時候全量載入到記憶體，加快查詢速度，官方建議至少留系統一半記憶體給Lucene
  3.各類快取----Filter Cache、Field Cache、Indexing Cache等，用於提升查詢分析效能，例如Filter Cache用於快取使用過的Filter的結果集
  4.Cluter State Buffer----ElasticSearch被設計為每個Node都可以響應使用者請求，因此每個Node的記憶體中都包含有一份叢集狀態的拷貝，一個規模很大的叢集這個狀態資訊可能會非常大
• 讀寫之間有延遲，寫入的資料差不多1s樣子會被讀取到，這也正常，寫入的時候自動加入這麼多索引肯定影響效能
• 資料結構靈活性不高，ElasticSearch這個東西，欄位一旦建立就沒法修改型別了，假如建立的資料表某個欄位沒有加全文索引，想加上，那麼只能把整個表刪了再重建

適用場景：

1. 有條件搜尋尤其是全文搜尋的場景，作為關係型資料庫的一種替代方案。

2. 另外，搜尋型資料庫還有一種特別重要的應用場景。我們可以想，一旦對資料庫做了分庫分表後，原來可以在單表中做的聚合操作、統計操作是否統統失效？例如我把訂單表分16個庫，1024張表，那麼訂單資料就散落在1024張表中，我想要統計昨天浙江省單筆成交金額最高的訂單是哪筆如何做？我想要把昨天的所有訂單按照時間排序分頁展示如何做？這就是搜尋型NoSql的另一大作用了，我們可以把分表之後的資料統一打在搜尋型NoSql中，利用搜尋型NoSql的搜尋與聚合能力完成對全量資料的查詢。

HBase
列式NoSql，大資料時代最具代表性的技術之一了，以HBase為代表。

列式NoSql是基於列式儲存的，那麼什麼是列式儲存呢，列式NoSql和關係型資料庫一樣都有主鍵的概念，區別在於關係型資料庫是按照行組織的資料：

看到每行有name、phone、address三個欄位，這是行式儲存的方式，且可以觀察id = 2的這條資料，即使phone欄位沒有，它也是佔空間的。

列式儲存完全是另一種方式，它是按每一列進行組織的資料：

這麼做有什麼好處呢？大致有以下幾點：

• 查詢時只有指定的列會被讀取，不會讀取所有列
• 儲存上節約空間，Null值不會被儲存，一列中有時候會有很多重複資料（尤其是列舉資料，性別、狀態等），這類資料可壓縮， 行式資料庫壓縮率通常在3:1至 ~ 5:1之間，列式資料庫的壓縮率一般在8:1 ~ 30:1左右
• 列資料被組織到一起，一次磁碟IO可以將一列資料一次性讀取到記憶體中

第二點說到了資料壓縮，什麼意思呢，以比較常見的字典表壓縮方式舉例：

優點：

• 海量資料無限儲存，PB級別資料隨便存，底層基於HDFS（Hadoop檔案系統），資料持久化
• 讀寫效能好，只要沒有濫用造成資料熱點，讀寫基本隨便玩
• 橫向擴充套件在關係型資料庫及非關係型資料庫中都是最方便的之一，只需要新增新機器就可以實現資料容量的線性增長，且可用在廉價伺服器上，節省成本
• 本身沒有單點故障，可用性高
• 可儲存結構化或者半結構化的資料
• 列數理論上無限，HBase本身只對列族數量有要求，建議1~3個

缺點：

• HBase是Hadoop生態的一部分，因此它本身是一款比較重的產品，依賴很多Hadoop元件，資料規模不大沒必要用，運維還是有點複雜的
• KV式，不支援條件查詢，或者說條件查詢非常非常弱吧，HBase在Scan掃描一批資料的情況下還是提供了字首匹配這種API的，條件查詢除非定義多個RowKey做資料冗餘
• 不支援分頁查詢，因為統計不了資料總數

適用場景：
HBase比較適用於那種KV型的且未來無法預估資料增長量的場景

3️⃣關係型資料庫 vs 非關係型資料庫

3.1❀ 基礎對比

比對	關係型資料庫	非關係型資料庫
定義	採用了關係模型來組織資料的資料庫，關係模型中只包含單一的資料結構——關係，在使用者看來關係模型中資料的邏輯結構是一張扁平的二維表，關係型資料庫就是由二維表及其之間的聯絡所組成的一個資料組織。	NoSQL的資料儲存不需要固定的模式，無需多餘操作就可以橫向擴充套件。
特徵	1.高度組織化結構化資料 2.結構化查詢語言（SQL） 3.資料和關係都儲存在單獨的表中 4. 資料操縱語言，資料定義語言 5.嚴格的一致性 6.基礎事務	1.代表著不僅僅是SQL 2.沒有宣告性查詢語言 3. 沒有預定義的模式 4.鍵 - 值對儲存，列儲存，文件儲存，圖形資料庫 5. 最終一致性，而非ACID屬性 6.非結構化和不可預知的資料 7.CAP定理 8. 高效能，高可用性和可伸縮性
優點	1.資料一致性，支援ACID特性，可以維護資料之間的一致性，是關係型資料庫的核心。 2.易理解，支因為行 + 列的二維表邏輯是非常貼近邏輯世界的一個概念，關係模型相對網狀、層次等其他模型更加容易被理解。 3.為維護資料一致性付出的代價大，SQL標準為事務定義了不同的隔離級別，從低到高依次是讀未提交、讀已提交、可重複度、序列化，事務隔離級別越低，可能出現的併發異常越多，但是通常而言能提供的併發能力越強。那麼為了保證事務一致性，資料庫就需要提供併發控制與故障恢復兩種技術，前者用於減少併發異常，後者可以在系統異常的時候保證事務與資料庫狀態不會被破壞。對於併發控制，其核心思想就是加鎖，無論是樂觀鎖還是悲觀鎖，只要提供的隔離級別越高，那麼讀寫效能必然越差。 4.資料穩定，資料持久化到磁碟，沒有丟失資料風險，支援海量資料儲存。 5.服務穩定，最常用的關係型資料庫產品MySql、Oracle伺服器效能卓越，服務穩定，通常很少出現當機異常。	1.高可擴充套件性，使用者可以根據需要去新增的欄位，不需要改變這個表的結構。 2.適用分散式 3.沒有複雜的關係 4.低成本，Nosql資料庫簡單易部署，基本都是開源軟體 5.儲存資料的格式多，Nosql的儲存格式是key,value形式、文件形式、圖片形式等等，所以可以儲存基礎型別以及物件或者是集合等各種格式，而資料庫則只支援基礎型別。 6.查詢速度快，Nosql資料庫將資料儲存於快取之中，而且不需要經過SQL層的解析，關係型資料庫將資料儲存在硬碟中，自然查詢速度遠不及Nosql資料庫。
缺點	1.高併發下IO壓力大，資料按行儲存，即使只針對其中某一列進行運算，也會將整行資料從儲存裝置中讀入記憶體，導致IO較高。 2.為維護索引付出的代價大，為了提供豐富的查詢能力，通常熱點表都會有多個二級索引，一旦有了二級索引，資料的新增必然伴隨著所有二級索引的新增，資料的更新也必然伴隨著所有二級索引的更新，這不可避免地降低了關係型資料庫的讀寫能力，且索引越多讀寫能力越差。有機會的話可以看一下自己公司的資料庫，除了資料檔案不可避免地佔空間外，索引佔的空間其實也並不少。 3.為維護資料一致性付出的代價大，通用的SQL語言使得操作關係型資料庫非常方便，支援join等複雜查詢，Sql + 二維關係是關係型資料庫最無可比擬的優點。 4.水平擴充套件後帶來的種種問題難處理，做了分庫之後，資料遷移（1個庫的資料按照一定規則打到2個庫中）、跨庫join（訂單資料裡有使用者資料，兩條資料不在同一個庫中）、分散式事務處理都是需要考慮的問題，尤其是分散式事務處理，業界當前都沒有特別好的解決方案。 5.表結構擴充套件不方便，由於資料庫儲存的是結構化資料，因此表結構schema是固定的，擴充套件不方便，如果需要修改表結構，需要執行DDL（data definition language）語句修改，修改期間會導致鎖表，部分服務不可用。 6.全文搜尋功能弱，例如like "%中國真偉大%"，只能搜尋到"2019年中國真偉大，愛祖國"，無法搜尋到"中國真是太偉大了"這樣的文字，即不具備分詞能力，且like查詢在"%中國真偉大"這樣的搜尋條件下，無法命中索引，將會導致查詢效率大大降低。	1.沒有標準化 2.有限的查詢功能（到目前為止） 3.最終一致是不直觀的程式，非關係型資料庫一般強調的是資料最終一致性，不像關係型資料庫一樣強調資料的強一致性，從非關係型資料庫中讀到的有可能還是處於一箇中間態的資料，
代表	1.Oracle，大型資料庫 效能強 價格貴 支援原生內建分散式。 2.MS SQL Server，一般用於.net程式設計 3.My SQL，開源免費，體積小 PostgreSQL，DB2， Microsoft Access， SQLite等等	1.Redis 2.ElasticSearch 3.Mongodb 4.Hbase
規範	ACID 原子性(Atomicity) 一致性(Consistency) 隔離性(Isolation) 永續性 (Durable)	Base 基本可用(Basically Available) 軟狀態/柔性事務(Soft state) 最終一致性 (Eventual consistency)

3.2❀ ACID vs BASE

關係型資料庫遵循ACID規則

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

1、A (Atomicity) 原子性

原子性很容易理解，也就是說事務裡的所有操作要麼全部做完，要麼都不做，事務成功的條件是事務裡的所有操作都成功，只要有一個操作失敗，整個事務就失敗，需要回滾。

比如銀行轉賬，從A賬戶轉100元至B賬戶，分為兩個步驟：1）從A賬戶取100元；2）存入100元至B賬戶。這兩步要麼一起完成，要麼一起不完成，如果只完成第一步，第二步失敗，錢會莫名其妙少了100元。

2、C (Consistency) 一致性

一致性也比較容易理解，也就是說資料庫要一直處於一致的狀態，事務的執行不會改變資料庫原本的一致性約束。

例如現有完整性約束a+b=10，如果一個事務改變了a，那麼必須得改變b，使得事務結束後依然滿足a+b=10，否則事務失敗。

3、I (Isolation) 獨立性

所謂的獨立性是指併發的事務之間不會互相影響，如果一個事務要訪問的資料正在被另外一個事務修改，只要另外一個事務未提交，它所訪問的資料就不受未提交事務的影響。

比如現在有個交易是從A賬戶轉100元至B賬戶，在這個交易還未完成的情況下，如果此時B查詢自己的賬戶，是看不到新增加的100元的。

4、D (Durability) 永續性

永續性是指一旦事務提交後，它所做的修改將會永久的儲存在資料庫上，即使出現當機也不會丟失。

BASE規則

CAP理論的核心是：一個分散式系統不可能同時很好的滿足一致性，可用性和分割槽容錯性這三個需求，最多隻能同時較好的滿足兩個。

BASE是NoSQL資料庫通常對可用性及一致性的弱要求原則:

• Basically Availble --基本可用
• Soft-state --軟狀態/柔性事務。 “Soft state” 可以理解為"無連線"的, 而 “Hard state” 是"面向連線"的
• Eventual Consistency – 最終一致性， 也是 ACID 的最終目的。

資料庫排名：https://db-engines.com/en/ranking

4️⃣ 關係型資料庫效能瓶頸和解決方案

4.1❀ 效能瓶頸

在網際網路場景下，關係型資料庫常見的效能瓶頸主要有兩個

• 大量的併發 讀/寫操作，導致倒庫出現難以承受的負載壓力
• 單表儲存資料量過大，導致檢索效率低下

具體表現：
資料庫佔CPU高、Sql執行慢、客戶端報資料庫連線池不夠等錯誤，因此例如萬人秒殺這種場景，我們絕對不可能通過關係型資料庫直接去扣減庫存。

優化操作：

4.2❀ 資料庫讀寫分離

在系統初期，整體的併發了相對較小，因此一般都是將所有的資料資訊儲存在單庫中進行讀/寫操作。但是隨著使用者規模不斷提升，單庫逐漸力不從心，TPS（系統吞吐量）/QPS（每秒查詢次數）越來越低。因此可將資料庫設定為讀寫分離狀態（生產環境一般會採用一主一從或者一主多從），Master負責寫操作，Slave作為備庫，不開放寫操作，但是允許讀操作，主從之間保持資料同步即可。

讀寫分離之後，可以大大提升單庫無法支撐的負載壓力。

需要注意的是：如果Master存在TPS存在較高的情況，Master之前最好將同一份資料落到快取中，以避免高併發情況下，從Slave中獲取不到指定資料的情況發生。

4.3❀ 資料垂直分庫

讀寫分離讓系統的吞吐量相對於單庫來說有了一定的提升，但是隻依靠讀寫分離並不能一勞永逸，隨著使用者規模攀升，系統瓶頸一定會暴露。

垂直分庫就是根據自身業務垂直劃分，將表拆分到不同的業務庫中。實現分而治之的資料管理和讀寫操作。

單表資料量一大，讀操作會逐漸成為瓶頸。
寫操作因為是順序寫，所以基本上資料庫的寫入操作不會因為資料膨脹而成為瓶頸，但是讀操作一定會存在上限；
讀操作成為瓶頸的時候，就該做水平分庫了

4.4❀ 資料庫水平分庫與水平分表

水平分表:將原本冗餘在單庫中的單個業務表拆分成為n個“邏輯相關”的業務字表(如：tab_000、tab_0001、……)
水平分庫:如果Master的TPS過高，則還可以對垂直分庫後的單一業務進行水平化，同水平分表類似。

分庫分表操作主要是為了解決：高併發場景下單庫的效能瓶頸，並充分利用分散式的威力提升資料庫的讀/寫能力。

假設後續業務表中的資料量又一次達到儲存閾值並對效能產生影響時，DBA只需要再次對現有業務庫和業務表橫向擴容，並遷移資料即可。

4.5❀ 關聯式資料庫儲存架構的演進

關係型資料庫儲存的是關係型資料，它有優點，同時也有明顯的缺點，因此通常在企業規模不斷擴大的情況下，不會一味指望通過增強資料庫的能力來解決資料儲存問題，而是會引入其他儲存，也就是我們說的NoSql。

5️⃣資料庫設計和選型

5.1❀ 資料庫設計

5.2❀ 資料庫選型建議

第一點，不多解釋應該都理解，非關係型資料庫都是通過犧牲了ACID特性來獲取更高的效能的，假設兩張表之間有比較強的一致性需求，那麼這類資料是不適合放在非關係型資料庫中的。

第二點，核心資料不走非關係型資料庫，例如使用者表、訂單表，但是這有一個前提，就是這一類核心資料會有多種查詢模式，例如使用者表有ABCD四個欄位，可能根據AB查，可能根據AC查，可能根據D查，假設核心資料，但是就是個KV形式，比如使用者的聊天記錄，那麼HBase一存就完事了。

非核心資料尤其是日誌、流水一類中間資料千萬不要寫在關係型資料庫中，這一類資料通常有兩個特點：

• 寫遠高於讀
• 寫入量巨大

此時，一旦使用關係型資料庫作為儲存引擎，將大大降低關係型資料庫的能力，正常讀寫QPS不高的核心服務會受這一類資料讀寫的拖累。

實際一個系統，通常是多種資料庫配合使用的。

6️⃣分散式資料庫構架

大多數的NoSql多可以通過簡單的配置實現分散式部署。

6.1❀分散式與叢集區別

1）分散式是指 多個系統協同合作完成一個特定任務的系統。

分散式是解決中心化管理的問題，把所有的任務疊加到一個節點處理，太慢了。

所以把一個大的問題拆分為多個小的問題，並分別解決，最終協同合作。分散式的主要工作是分解任務，將職能拆解。

2）叢集主要的使用場景是為了分擔請求的壓力，也就是在幾個伺服器上部署相同的應用程式，來分擔客戶端請求。

當壓力進一步增大的時候，可能在需要儲存的部分，mysql 無法面對很多的寫壓力。因為在 mysql 做成叢集之後，主要的寫壓力還是在 master 的機器上面，其他 slave 機器無法分擔寫壓力，從而這個時候，也就引出來分散式。

分散式的主要應用場景是單臺機器已經無法滿足這種效能的要求，必須要融合多個節點，並且節點之間是相關之間有互動的。相當於在寫 mysql 的時候，每個節點儲存部分資料，也就是分散式儲存的由來。儲存一些非結構化資料：靜態檔案、圖片、pdf、小視訊 … 這些也就是分散式檔案系統的由來。

3）叢集主要是簡單加機器解決問題，對於問題本身不做任何分解；

分散式處理裡必然包含任務分解與答案歸併。分散式中的某個子任務節點，可能由一個叢集來代替；叢集中任一節點，都是做一個完整的任務。

叢集和分散式都是由多個節點組成，但是叢集之間的通訊協調基本不需要；而分散式各個節點的通訊協調必不可少。

將一套系統拆分成不同子系統部署在不同伺服器上（這叫分散式），
然後部署多個相同的子系統在不同的伺服器上（這叫叢集），部署在不同伺服器上的同一個子系統應做負載均衡。

分散式：一個業務拆分為多個子業務，部署在多個伺服器上 。
叢集：同一個業務，部署在多個伺服器上 。

叢集master選舉
1、投票制

• 投票制的一般流程
  在叢集啟動或Leader當機時，會先比較所有例項的事務號，以具有最新事務的例項作為Leader，若多個例項都有最新的事務號，則從中隨機取一個(或根據例項ID選取最大或最小的，看具體實現)作為Leader，Follower再從新的Leader中同步事務。總結來說，有以下幾點
  a）對比事務號，取最新事務號的
  b） 若多個例項的事務號都是最新的，則按照一定的規則選(隨機/例項ID最大(ZK)/例項ID最小(Neo4j))
• 常見的用投票制的元件
  a）Zookeeper，Zookeeper的事務號又叫ZXID，若ZXID相同，myid大的作為Leader；
  b）Neo4j，Neo4j官網沒有介紹因果叢集的Leader選舉機制，但介紹了HA叢集的Master選舉機制，和Zookeeper不同的是，在transaction ID一致的情況下，ha.server_id最低的會被選舉為Master

2、藉助ZK

• 流程
  Zookeeper有一種臨時節點，所有的例項都去Zookeeper中建立路徑相同的臨時節點，建立成功的就是新的Leader。
• 常見的藉助ZK選舉Leader的元件
  1、Kafka，Kafka所有的Broker都會嘗試在Zookeeper的/controller路徑下建立臨時節點，成功建立的那個broker就會成為leader，其他的broker就會成為follower

6.2❀ 分散式系統

分散式系統（distributed system）由多臺計算機和通訊的軟體元件通過計算機網路連線（本地網路或廣域網）組成。

分散式系統是建立在網路之上的軟體系統。正是因為軟體的特性，所以分散式系統具有高度的內聚性和透明性。

6.3❀ 分散式計算的優點

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

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

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

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

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

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

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

6.4❀ 分散式計算的缺點

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

• 軟體：
  更少的軟體支援是分散式計算系統的主要缺點。

• 網路：
  網路基礎設施的問題，包括：傳輸問題，高負載，資訊丟失等。

• 安全性：
  開放系統的特性讓分散式計算系統存在著資料的安全性和共享的風險等問題。

6.5❀ CAP定理

在電腦科學中, CAP定理（CAP theorem）, 又被稱作 布魯爾定理（Brewer’s theorem）, 它指出對於一個分散式計算系統來說，不可能同時滿足以下三點:

• 一致性(Consistency) (所有節點在同一時間具有相同的資料)
• 可用性(Availability) (保證每個請求不管成功或者失敗都有響應)
• 分隔容忍(Partition tolerance) (系統中任意資訊的丟失或失敗不會影響系統的繼續運作)

CAP理論的核心是：一個分散式系統不可能同時很好的滿足一致性，可用性和分割槽容錯性這三個需求，最多隻能同時較好的滿足兩個。

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

CA - 單點叢集，滿足一致性，可用性的系統，通常在可擴充套件性上不太強大。
CP - 滿足一致性，分割槽容忍性的系統，通常效能不是特別高。
AP - 滿足可用性，分割槽容忍性的系統，通常可能對一致性要求低一些。

7️⃣分庫 分表 分割槽 分片

7.1❀ 分割槽(Partition)

資料分割槽是一種物理資料庫的設計技術，它的目的是為了在特定的SQL操作中減少資料讀寫的總量以縮減響應時間。

分割槽並不是生成新的資料表，而是將表的資料均衡分攤到不同的硬碟，系統或是伺服器的其他儲存介質中，實際上還是一張表。

優點：業務無感，多個物理儲存，邏輯上還是一張表

1、相對於單個檔案系統或是硬碟，分割槽可以儲存更多的資料；

2、資料管理比較方便，比如要清理或廢棄某年的資料，就可以直接刪除該日期的分割槽資料即可；

3、精準定位分割槽查詢資料，不需要全表掃描查詢，大大提高資料檢索效率；

4、可跨多個分割槽磁碟查詢，來提高查詢的吞吐量；

5、在涉及聚合函式查詢時，可以很容易進行資料的合併；

侷限：侷限於單庫，不能跨主機

分類：

• 水平分割槽
  保持列，劃分行
• 垂直分割槽
  劃分列，保持行
  對錶的垂直劃分來減少目標表的寬度，使某些特定的列被劃分到特定的分割槽

表結構設計垂直切分。常見的一些場景包括

1. 大欄位的垂直切分。單獨將大欄位建在另外的表中，提高基礎表的訪問效能，原則上在效能關鍵的應用中應當避免資料庫的大欄位
2. 按照使用用途垂直切分。例如企業物料屬性，可以按照基本屬性、銷售屬性、採購屬性、生產製造屬性、財務會計屬性等用途垂直切分
3. 按照訪問頻率垂直切分。例如電子商務、Web 2.0系統中，如果使用者屬性設定非常多，可以將基本、使用頻繁的屬性和不常用的屬性垂直切分開

表結構設計水平切分。常見的一些場景包括

1. 比如線上電子商務網站，訂單表資料量過大，按照年度、月度水平切分。
2. Web 2.0網站註冊使用者、線上活躍使用者過多，按照使用者ID範圍等方式，將相關使用者以及該使用者緊密關聯的表做水平切分。
3. 例如論壇的置頂帖子，因為涉及到分頁問題，每頁都需要顯示置頂貼，這種情況可以把置頂貼水平切分開來，避免取置頂帖子時從所有帖子的表中讀取。

7.2❀ 分片(sharding)

類似分庫，且只有部分資料（redis,mysql…）庫由此特性。
分片是把資料庫橫向擴充套件（Scale Out）到多個物理節點上的一種有效的方式，其主要目的是為突破單節點資料庫伺服器的 I/O 能力限制，解決資料庫擴充套件性問題。Shard這個詞的意思是“碎片”。如果將一個資料庫當作一塊大玻璃，將這塊玻璃打碎，那麼每一小塊都稱為資料庫的碎片（DatabaseShard）。將整個資料庫打碎的過程就叫做sharding，可以翻譯為分片。

形式上，Sharding可以簡單定義為將大資料庫分佈到多個物理節點上的一個分割槽方案。每一個分割槽包含資料庫的某一部分，稱為一個shard，分割槽方式可以是任意的，並不侷限於傳統的水平分割槽和垂直分割槽。一個shard可以包含多個表的內容甚至可以包含多個資料庫例項中的內容。每個shard被放置在一個資料庫伺服器上。一個資料庫伺服器可以處理一個或多個shard的資料。系統中需要有伺服器進行查詢路由轉發，負責將查詢轉發到包含該查詢所訪問資料的shard或shards節點上去執行。

優點：無限擴充套件，可以跨庫、跨主機
侷限：擴充套件時需要調整業務配置

分類：
垂直分片：不同的表分散到不同的資料庫或主機，適用於低耦合系統；
水平分片：同一張表的資料分散到不同的資料庫或主機，適用於複雜系統。

7.3❀ 分表

把一張表按一定的規則分解成N個具有獨立儲存空間的實體表。系統讀寫時需要根據定義好的規則得到對應的字表明，然後操作它。

分割槽和分表的區別與聯絡

• 分割槽和分表的目的都是減少資料庫的負擔，提高表的增刪改查效率。
• 分割槽只是一張表中的資料的儲存位置發生改變，分表是將一張表分成多張表。
• 當訪問量大，且表資料比較大時，兩種方式可以互相配合使用。
• 當訪問量不大，但表資料比較多時，可以只進行分表。

分表能夠解決單表資料量過大帶來的查詢效率下降的問題，但是，卻無法給資料庫的併發處理能力帶來質的提升。面對高併發的讀寫訪問，當資料庫master伺服器無法承載寫操作壓力時，不管如何擴充套件slave伺服器，此時都沒有意義了。因此，我們必須換一種思路，對資料庫進行拆分，從而提高資料庫寫入能力，這就是所謂的分庫。

7.4❀ 分庫

單臺DB的儲存空間不夠，隨著查詢量的增加單臺資料庫伺服器已經沒辦法支撐

其主要目的是為突破單節點資料庫伺服器的 I/O 能力限制，解決資料庫擴充套件性問題。

方式：

• 垂直拆分
  將系統中不存在關聯關係或者需要join的表可以放在不同的資料庫不同的伺服器中。
  按照業務垂直劃分。比如：可以按照業務分為資金、會員、訂單三個資料庫。
  需要解決的問題：跨資料庫的事務、jion查詢等問題。

• 水平拆分
  例如，大部分的站點。資料都是和使用者有關，那麼可以根據使用者，將資料按照使用者水平拆分。
  按照規則劃分，一般水平分庫是在垂直分庫之後的。比如每天處理的訂單數量是海量的，可以按照一定的規則水平劃分。需要解決的問題：資料路由、組裝。

• 讀寫分離
  對於時效性不高的資料，可以通過讀寫分離緩解資料庫壓力。需要解決的問題：在業務上區分哪些業務上是允許一定時間延遲的，以及資料同步問題。

思路：垂直分庫–>水平分庫–>讀寫分離

存在問題：

• 事務的支援，分庫分表，就變成了分散式事務
• join時跨庫，跨表的問題
• 分庫分表，讀寫分離使用了分散式，分散式為了保證強一致性，必然帶來延遲，導致效能降低，系統的複雜度變高。

常用的解決方案：

對於不同的方式之間沒有嚴格的界限，特點不同，側重點不同。需要根據實際情況，結合每種方式的特點來進行處理。

選用第三方的資料庫中介軟體（Atlas，Mycat，TDDL，DRDS），同時業務系統需要配合資料儲存的升級。

=============================================================================================
參考文件：
Sql Or NoSql，看完這一篇你就懂了
簡述關係型資料庫和非關係型資料庫
NoSQL 簡介
大白話解說，半分鐘就懂 — 分散式與叢集是什麼 ？ 區別是什麼？
關係型資料庫的架構演變