何為SHARDING:

將大數(shù)據(jù)集分為多個塊，存儲在不同的服務器上

專注于為中小企業(yè)提供成都網(wǎng)站建設(shè)、網(wǎng)站設(shè)計服務,電腦端+手機端+微信端的三站合一,更高效的管理,為中小企業(yè)江南免費做網(wǎng)站提供優(yōu)質(zhì)的服務。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動了成百上千企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設(shè)實現(xiàn)規(guī)模擴充和轉(zhuǎn)變。

目的：

可擴展性: 不同的分片可以放在不同的服務器上，分散讀請求
復雜查詢可以并行的在不同的分片上執(zhí)行
寫請求分散到各個服務器上

問題1: 怎么分？

每個服務器上數(shù)據(jù)保持均勻,避免數(shù)據(jù)傾斜

• 隨機分配:
  優(yōu)點: 數(shù)據(jù)均勻
  缺點: 無法知道數(shù)據(jù)在哪個節(jié)點
• 每個分片保存主鍵一個范圍內(nèi)連續(xù)鍵值 (partition by key range)
  優(yōu)點: 容易算出主鍵在哪個節(jié)點. 主鍵可有序存儲，方便范圍搜索
  缺點: 每個分片數(shù)據(jù)可能不均勻，需要調(diào)節(jié)分片邊界 --> 手動或自動. 主鍵前綴解決分布問題
• 按主鍵HASH值分片: （riak, couchbase, voldemort）
  優(yōu)點: 理論上數(shù)據(jù)均勻，取決于HASH算法. 容易算出數(shù)據(jù)在哪個節(jié)點
  缺點: 難以進行范圍搜索
• 混合模式: 聯(lián)合主鍵，先按主鍵第一個屬性HASH，再按其他屬性有序排列 (cassandra)
  適合處理一對多數(shù)據(jù)
  處理數(shù)據(jù)傾斜和熱點鍵讀寫:
  需要應用層解決: 如對鍵值增加隨機前后綴. 缺點: 同一個鍵值的數(shù)據(jù)分散在不同分片內(nèi)，增加讀取復雜度

  問題2: 如何查詢數(shù)據(jù)?

  分片策略解決了寫和主鍵查詢的問題，但是如何解決其他查詢條件查詢？如何在數(shù)據(jù)分片的情況下建立二級索引?

• 本地索引: 每個分片單獨維護二級查詢條件到主鍵列表的字典映射
  優(yōu)點：寫數(shù)據(jù)時更新索引時容易
  缺點：查詢必須在每個分片的二級索引中查找，再合并結(jié)果
• 全局索引: 一個獨立的索引結(jié)構(gòu)覆蓋所有分片，索引本身也分片，按照索引對應的查詢條件 （term partitioned)
  優(yōu)點：查詢索引落到單個分片,效率高，如果采用RANGE分片也支持范圍查詢
  缺點: 寫入數(shù)據(jù)復雜，寫操作會影響多個分片(數(shù)據(jù)分片和索引分片未必在同一個節(jié)點), 需要分布式事務支持, 或者采用異步方式，犧牲一致性,新寫入的數(shù)據(jù)未必立刻在索引中可見.

  問題3: 集群擴容或者有宕機節(jié)點分片數(shù)據(jù)如何處理?

  分片數(shù)據(jù)需要從一個節(jié)點遷移到另一個節(jié)點 (partition rebalancing)

  數(shù)據(jù)重平衡需求:

  1. 遷移后負載必須保持均勻 (集群擴容)
  2. 遷移中集群必須可用，讀寫無影響
  3. 遷移必須最小化不必要的數(shù)據(jù)移動，減少集群IO開銷

     數(shù)據(jù)重平衡策略:

• hash取模會導致擴容后大量分片所處節(jié)點發(fā)生變化, 不滿足上述需求3
• 不直接把key映射到node，而是先把key映射到partition, 再把partition映射到node. partition的數(shù)量遠大于node的數(shù)量, 這樣新增node獲取部分partition數(shù)據(jù), 同時保持key到partition的映射不變 （riak, elasticsearch, couchbase, voldemort)
  優(yōu)點: 最小化擴容過程中的數(shù)據(jù)移動
  缺點: partition數(shù)量是永遠固定的，不可增減, 決定partition的數(shù)量很難，每個partition的數(shù)據(jù)量過大或者過小都會帶來額外開銷
• 動態(tài)主鍵范圍分片: 數(shù)據(jù)分片按照主鍵排序, 當分片超過配置大小后自動分裂為兩個分片, 當分片由于數(shù)據(jù)刪除過小后和相鄰的分片做合并. (hbase, rethinkDB)
  優(yōu)點: 分片大小自動適配集群數(shù)據(jù)量
  缺點: 數(shù)據(jù)庫剛初始化時僅有一個分片, 讀寫負載不能有效分散. 解決方案: 配置預分片.
  動態(tài)分片也可應用于HASH分片
• 分片數(shù)同比例于節(jié)點數(shù): 即每個節(jié)點上分片數(shù)固定. 新節(jié)點加入時，隨機選取一定數(shù)量的分片做等分，把一半數(shù)據(jù)移動到新節(jié)點. (cassandra, ketama)
  缺點：只支持HASH分片. 隨機選取可能導致數(shù)據(jù)不均勻

  人工或自動平衡:

  自動重平衡
  優(yōu)點：不需要人工干預
  缺點：分片數(shù)據(jù)移動是昂貴的操作，會對集群性能產(chǎn)生不可知影響，并容易引起雪崩效應
  人工重平衡
  優(yōu)點：可控性強
  缺點：響應速度慢

請求路由：

重平衡之后客戶端需要知道連接到哪個節(jié)點

• 客戶端可連接到任何節(jié)點，如果分區(qū)存在則處理請求，否則由節(jié)點負責將請求發(fā)往分片所在節(jié)點
  優(yōu)點：客戶端不需要存儲分片METADATA，
  缺點：請求roundtrip時間可能變長
• 單獨的路由層負責接收客戶端請求并轉(zhuǎn)發(fā)，路由層需要了解分片存儲METADATA
  優(yōu)點：客戶端不需要存儲分片METADATA，
  缺點：請求roundtrip時間可能變長

• 客戶端存儲分片METADATA并直接路由到新節(jié)點
  優(yōu)點：直接路由, 速度快
  缺點：客戶端需要感知分片topology變化

  客戶端感知路由變化是一個挑戰(zhàn)性的問題. (網(wǎng)絡(luò)延遲/分區(qū)等), 需要分布式一致性協(xié)議，或者用集中式路由METADATA存儲如zookeeper等

并行QUERY執(zhí)行:

分析型數(shù)據(jù)庫需要將復雜的QUERY分解成可多個并發(fā)執(zhí)行的分片和階段，構(gòu)成一個有向無環(huán)圖

其他：

一般SHARDING和REPLICATION會一起使用，一個分片會保存在多個服務器上
一致性HASH: 主要解決cdn網(wǎng)絡(luò)隨機選擇分片邊界而不需要一個集中式的一致性協(xié)議，一般不太適合使用于數(shù)據(jù)庫