讀構建可擴充套件分散式系統：方法與實踐09可擴充套件資料庫基礎

1. 可擴充套件資料庫基礎

1.1. 絕大多數應用程式都是基於關聯式資料庫技術構建的

1.2. 資料庫必須儲存大量資料，為分佈在全球的客戶端提供快速的查詢響應，並且全天候可用

1.3. NoSQL資料庫採用簡單的資料模型，可以複製和分割槽以支援海量資料集和請求量

1.4. Facebook以使用MySQL管理PB級社交相關活動（例如使用者評論和點贊）的資料而聞名

• 1.4.1. 基本架構基於副本集，一個主節點處理所有寫入請求

• 1.4.2. 資料更新被非同步複製到按地理分佈的只讀副本

• 1.4.3. 構建自己的儲存技術MyRocks

• 1.4.3.1. MyRocks提高了寫入效能並節省了50%的儲存空間

1.5. 百度公司從2012年開始使用MongoDB

• 1.5.1. 使用MongoDB來管理包括地圖、訊息和共享照片在內的多項服務的資料

• 1.5.2. 大概有2000億份檔案和超過1 PB的資料，由600個節點管理，並分佈在多個位置以確保可用性

2. 分散式資料庫

2.1. 網際網路大規模的應用程式讓資料集在規模和複雜性上有了長足的增長

• 2.1.1. 為數千萬使用者建立和管理大量異構資料，包括諸如使用者配置檔案、使用者偏好、行為資料、影像和影片、銷售資料、廣告、感測器讀數、監控資料等

• 2.1.2. 許多資料集實在是太大了，無法放在一臺機器上

2.2. 需要演化過的資料庫引擎來管理大量的分散式資料集合

• 2.2.1. 低成本、功能強大的硬體的發展，使得在數百甚至數千個節點和磁碟上以低成本高效地分發資料成為可能

• 2.2.2. 在節點間和磁碟上覆制資料增強了可擴充套件性和可用性

2.3. 當今網際網路應用程式需求的不斷變化是資料庫引擎創新的另一個主要驅動力

• 2.3.1. 關聯式資料庫的內在優勢（即事務和一致性）是以效能成本為代價的，在Twitter和Facebook等網站中並不總是合適的

• 2.3.1.1. 這類網站並不要求每個使用者總是看到相同版本的資訊

2.4. 當系統擁有數萬乃至數百萬的使用者時，可以放寬關聯式資料庫的各種資料約束，從而獲得更好的效能和可擴充套件性

• 2.4.1. 促使了非關係資料模型和原生分散式資料庫引擎誕生，以支援當今應用程式的各種用例

• 2.4.2. 魚和熊掌不可兼得，其中的取捨表現在資料庫支援的功能範圍及其程式設計模型的複雜性上

3. 擴充套件關聯式資料庫

3.1. 支援關係模型和SQL查詢語言的資料庫代表瞭如今最成熟、穩定和強大的資料庫軟體平臺

3.2. 關聯式資料庫是非常複雜且非常成功的技術

• 3.2.1. 關聯式資料庫技術是在資料集相對較小（與今天的標準相比）的時候設計和發展成熟的，資料庫可以在一臺機器上執行

3.3. 規範化

• 3.3.1. 關聯式資料庫的設計鼓勵規範化

• 3.3.2. 透過規範化構建業務域資料來消除資料冗餘，並支援資料完整性

• 3.3.3. 3NF資料模型旨在簡化資料管理

• 3.3.4. 域資料在多個關係之間拆分，使得每個資料項都有一個條目，在需要時引用唯一識別符號

• 3.3.5. 3NF資料模型中的資料可以機械地轉換為關係模式並由關聯式資料庫引擎例項化

3.4. 垂直擴充套件

• 3.4.1. 關聯式資料庫被設計為在一臺機器上執行，這樣就可以利用共享記憶體和磁碟來儲存資料及處理查詢

• 3.4.2. 使用者可以定製資料庫引擎使其執行在具有多個CPU、磁碟和大容量共享記憶體的機器上

• 3.4.3. 資料庫引擎可以利用更多的資源並行執行數千個查詢來提供極高的吞吐量

• 3.4.4. 資料庫遷移到新的、更強大的（虛擬）硬體

• 3.4.4.1. 我們有資料庫管理手段來執行遷移和調整資料庫配置，使其有效利用新資源，而無須改動應用程式程式碼

• 3.4.5. 主要缺點

• 3.4.5.1. 成本

>  3.4.5.1.1. 隨著計算資源的增長，硬體成本往往呈指數級增長

• 3.4.5.2. 可用性

>  3.4.5.2.1. 儘管你擁有很強大的資料庫，但只有一個節點

  >   3.4.5.2.1.1. 如果它不可用，你的系統就要崩潰

• 3.4.5.3. 擴充套件

>  3.4.5.3.1. 如果你的資料庫繼續增長，則不可避免地要再次遷移到更強大的硬體

>  3.4.5.3.2. 資料庫增長到超出單個節點的處理能力

>  3.4.5.3.3. 需要低延遲資料庫訪問來服務遍佈全球的客戶

  >   3.4.5.3.3.1. 穿越洲際網路並不能解決問題

3.5. 水平擴充套件：只讀副本

• 3.5.1. 增加資料庫處理能力的一個常見策略是使用只讀副本進行水平擴充套件

• 3.5.2. 可以將一個或多個節點配置為主資料庫的只讀副本

• 3.5.2.1. 主資料庫節點稱為主節點，只讀副本稱為輔助節點

• 3.5.2.2. 輔助資料庫維護主資料庫的副本

• 3.5.2.3. 應用程式只能對主節點進行寫入操作，然後所有更改都會非同步複製到輔助節點

• 3.5.3. 只讀副本方法將所有讀取請求定向到只讀副本來增強可擴充套件性

• 3.5.3.1. 對於讀取密集型工作負載的應用程式來說，非常有效

• 3.5.3.2. 可以透過新增更多輔助節點來擴充套件讀取能力，從而減少主節點的負載，使它能夠更有效地處理寫入請求

• 3.5.3.3. 如果主節點由於暫時性故障而變得不可用，不會中斷面向輔助節點的讀取請求

• 3.5.3.4. 由於資料寫入主資料庫和成功複製到輔助資料庫之間存在延遲，客戶端有可能從輔助資料庫讀取陳舊資料

3.6. 水平擴充套件：資料分割槽

• 3.6.1. 在關聯式資料庫中拆分或分割槽儲存資料是一種將資料庫分佈在多個獨立磁碟分割槽和資料庫引擎上的技術

• 3.6.2. 水平分割槽將一個邏輯表拆分為多個物理分割槽

• 3.6.2.1. 根據某種分割槽策略將資料行分配給一個分割槽

• 3.6.2.2. 常見的分割槽策略是根據行中的某個值將行分配給分割槽，或者對行的主鍵進行雜湊計算

• 3.6.3. 垂直分割槽，也稱為行拆分，按行中的列對錶進行分割槽

• 3.6.3.1. 出於物理而非概念最佳化的原因，垂直分割槽將一行拆分為一個或多個部分

• 3.6.3.2. 一種常見的策略是對行中的靜態資料、只讀資料和動態資料進行分割槽

3.7. 分散式SQL連線

• 3.7.1. SQL連線在分散式關聯式資料庫中實現起來很複雜

• 3.7.2. SQL引擎之所以長時間受到青睞，是因為它們針對單個資料庫上的連線進行了高度最佳化

• 3.7.3. 當關系表被分割槽並分佈在大型計算機叢集中時，需要精心設計分散式連線，以儘量減少資料移動，從而降低延遲

• 3.7.4. 分散式SQL連線的常見策略

• 3.7.4.1. 定義相對較小、更改頻率低且需要經常連線的引用表

• 3.7.4.2. 在連線中使用分割槽鍵或二級索引，允許連線操作使用索引欄位在每個分割槽本地並行執行

• 3.7.4.3. 確保連線的一側存在具有高度選擇性的過濾器，可將行集減少為一個小集合

>  3.7.4.3.1. 然後將小集合傳送到每個分割槽節點，像在引用表連線中一樣進行連線操作

>  3.7.4.3.2. 最大限度地減少了資料移動

• 3.7.4.4. 高吞吐量的查詢需要仔細設計並選擇合適的連線演算法

3.8. Oracle RAC

• 3.8.1. Oracle的RAC（Real Application Cluster，實時應用叢集）資料庫

• 3.8.2. Oracle的RAC資料庫於2001年釋出，為大容量、高可用系統提供分散式版本的Oracle資料庫引擎

• 3.8.3. Oracle公司讓部署一個由多達100個Oracle資料庫引擎組成的叢集成為可能，這些引擎都訪問同一個物理資料庫

• 3.8.4. 為避免資料分割槽問題，Oracle RAC是一個共享一切資料庫的示例

• 3.8.5. 所有節點都透過SAN（儲存區域網路）來訪問物理儲存

• 3.8.5.1. SAN提供對Oracle資料庫的高速網路訪問

• 3.8.6. 兩個專有軟體元件

• 3.8.6.1. Clusterware

>  3.8.6.1.1. 支援叢集中資料庫引擎之間的通訊和協調

>  3.8.6.1.2. 支援叢集中資料庫引擎之間的通訊和協調

• 3.8.6.2. Cache Fusion（快取融合）

>  3.8.6.2.1. 使每個叢集資料庫節點中的快取能夠有效共享，從而最大限度地減少對持久儲存的訪問

• 3.8.7. Oracle RAC展示了一種用於擴充套件關聯式資料庫的架構方法，即共享一切

• 3.8.7.1. 增強了Oracle部署的處理能力和高可用性，同時（在理論上）無須更改應用程式程式碼

• 3.8.7.2. 資料庫需要多個專有的Oracle軟體元件以及昂貴的冗餘儲存和互連硬體

• 3.8.7.3. 加上Oracle許可成本，無論如何你都沒有低成本的解決方案

• 3.8.7.4. 是一種以高成本換取有限的按需擴充套件能力的架構

4. 向NoSQL轉變

4.1. 廣泛可用的低成本商業計算節點和儲存的非共享架構

• 4.1.1. 功能強大、低成本的商業硬體的發展，包括多核CPU，速度更快、容量更大的磁碟，以及更高速的網路

• 4.1.2. 處理非結構化資料型別的應用程式的出現，及其業務和資料模型的快速發展

• 4.1.3. 面向網際網路的應用程式在可擴充套件性和可用性方面的需求激增

• 4.1.4. 收集原始資料並將其用於新業務洞察和分析的新機會

4.2. 向NoSQL轉變的核心特徵

• 4.2.1. 簡化的資料模型，可以輕鬆擴充套件

• 4.2.2. 專有的查詢語言，限制或不支援連線

• 4.2.3. 原生支援低成本商業硬體的水平擴充套件

4.3. NoSQL連線查詢

• 4.3.1. 資料模型的規範化(normalization)

• 4.3.1.1. 由於SQL和連線的強大功能，你不必過多考慮訪問資料時所使用的怪異而奇妙的方式，無論是立即訪問還是將來訪問

• 4.3.2. 使用NoSQL，建模重點從問題域建模轉變為方法域(solution domain)建模

• 4.3.3. 方法域建模的另一種方法是為每個用例建立一個表

• 4.3.4. 資料分割槽和資料分發變得更加容易，並且這些優勢在大規模使用中累積

4.4. NoSQL資料模型

• 4.4.1. 鍵值資料庫

• 4.4.1.1. 鍵值(Key-Value，KV)資料庫基本上是一個雜湊對映表

• 4.4.1.2. Redis

• 4.4.1.3. Oracle NoSQL

• 4.4.2. 面向文件資料庫

• 4.4.2.1. 面向文件資料庫建立在鍵值模型之上，同理，資料庫中的每個文件都需要一個唯一的鍵

• 4.4.2.2. 與鍵關聯的值對資料庫來說是透明的

• 4.4.2.3. 它通常以JSON格式進行編碼，從而可以在查詢中引用文件中的各個元素，並讓資料庫在文件欄位上建立索引

• 4.4.2.4. MongoDB

• 4.4.2.5. Couchbase

• 4.4.3. 列儲存資料庫

• 4.4.3.1. 列儲存資料庫是對鍵值模型的擴充套件，管理與命名列中的鍵相關聯的資料

• 4.4.3.2. 本質上是一個二維雜湊對映，使行中的列能夠使用列名進行唯一標識和排序

• 4.4.3.3. Apache Cassandra

• 4.4.3.4. Google Bigtable

• 4.4.4. 圖資料庫

• 4.4.4.1. 圖是一種很好理解的資料結構，用於儲存和查詢高度連線的資料

• 4.4.4.2. 圖資料庫在概念上最接近關聯式資料庫

• 4.4.4.3. Neo4j

• 4.4.4.4. Amazon Neptune

4.5. NoSQL資料庫通常被稱為無模式資料庫

• 4.5.1. 不可避免的代價是應用程式有責任解析它讀取的資料的結構，需要將資料物件與後設資料（用於解析結構，基本上是欄位名稱）一起儲存在資料庫中

• 4.5.2. 寫時模式（schema-on-write，定義模式）

• 4.5.3. 讀時模式（schema-on-read，無模式）

4.6. 查詢語言

• 4.6.1. NoSQL資料庫查詢語言幾乎總是特定資料庫專有的，並且與基於顯式API和類似SQL的宣告性語言有所不同

• 4.6.2. 由供應商和第三方實現的支援不同語言的客戶端庫可供應用程式使用

• 4.6.3. 鍵值資料庫可能只提供支援基於單個鍵值的CRUD操作的API

• 4.6.4. 文件資料庫通常支援單個文件欄位的索引

• 4.6.4.1. 使得檢索結果集和更新文件等查詢能夠高效實現，並滿足不同的文件搜尋標準

• 4.6.5. 列儲存資料庫具有多種查詢功能

• 4.6.6. 圖資料庫支援更豐富的查詢功能

• 4.6.6.1. Cypher，最初是為Neo4j圖資料庫設計的，並透過openCypher專案

4.7. 分散式資料儲存

• 4.7.1. NoSQL資料庫通常為方便分散式計算節點水平擴充套件而設計，節點配備了本地儲存

• 4.7.2. 由於沒有共享狀態，效能瓶頸和單點故障被消除，效能、可擴充套件性和可用性均得到增強

• 4.7.3. 分散式圖資料庫

• 4.7.3.1. 由圖資料庫實現的圖資料結構明確表示圖中節點之間的關係

• 4.7.3.2. 水平擴充套件圖資料庫以提高效能並非易事

• 4.7.4. 分割槽，通常稱為分片，需要一種演算法來跨多個伺服器節點實現分散式儲存邏輯資料庫集合中的資料物件

• 4.7.4.1. 分片需要一個分片或分割槽鍵，將給定資料物件分配到特定分割槽

• 4.7.4.2. 雜湊鍵

>  4.7.4.2.1. 任何給定資料物件的分割槽都是將分片鍵雜湊（即應用雜湊函式）後，再將結果對映到分割槽

>  4.7.4.2.2. 使用模數方法或名為一致性雜湊的演算法

• 4.7.4.3. 基於分片鍵值

>  4.7.4.3.1. 分割槽是根據分片鍵的值進行選擇的

• 4.7.4.4. 基於分片鍵值範圍

>  4.7.4.4.1. 分割槽託管特定範圍內分片鍵值所在的資料物件

>  4.7.4.4.2. 分割槽可以透過增加處理資源和磁碟容量，並在額外的資源中分佈資料來擴充套件資料庫

4.8. 引入副本來解決可用性問題

• 4.8.1. 每個分割槽中的資料物件通常被複制到兩個或更多節點

• 4.8.2. 如果其中一個節點變得不可用，應用程式可以透過訪問其他副本繼續執行

• 4.8.3. 副本增強了可用性和可擴充套件性

• 4.8.3.1. 儲存副本的額外資源也可用於處理來自應用程式的讀取和寫入請求

• 4.8.3.2. 當發生資料更新請求時，資料庫需要更新所有的副本

• 4.8.4. 領導者-追隨者模式(leader-follower)

• 4.8.4.1. 其中一個副本被指定為領導者，它始終持有任何資料物件的最新值

• 4.8.5. 無領導模式(leaderless)

• 4.8.5.1. 所有副本都可以處理讀取請求和更新請求

• 4.8.6. 如果一個資料庫可以確保所有副本始終具有相同的值，那麼它可以對外提供強一致性(strong consistency)

• 4.8.6.1. 所有客戶端訪問都會針對每個資料物件返回相同的值

• 4.8.7. 將資料庫允許副本不一致的行為稱為最終一致性(eventually consistent)

5. CAP定理

5.1. Eric Brewer著名的CAP定理優雅地闡述了使用分散式資料庫時副本一致性和可用性的選擇

5.2. 描述了資料庫系統在存在網路分割槽時的選擇，即當資料庫節點之間傳送的訊息存在網路延遲和丟失時

5.3. 如果網路執行正常，系統就可以同時保持一致性和可用性

5.4. 如果發生網路分割槽，系統可以是一致的(CP)或可用的(AP)

• 5.4.1. 返回錯誤，因為它無法確保副本一致性(CP)

• 5.4.2. 將更新應用於可見的副本子集(AP)

• 5.4.2.1. 意味著在資料庫透過分割槽修復使所有副本一致之前，副本是不一致的

• 5.4.2.2. 在解決不一致問題之前，客戶端可能會看到同一資料物件的不同值