Design Data Intensive Applications 筆記 (數據分片)

何爲SHARDING:

將大數據集分爲多個塊，存儲在不一樣的服務器上

目的：

可擴展性: 不一樣的分片能夠放在不一樣的服務器上，分散讀請求
複雜查詢能夠並行的在不一樣的分片上執行
寫請求分散到各個服務器上

問題1: 怎麼分？

每一個服務器上數據保持均勻,避免數據傾斜

• 隨機分配:
  優勢: 數據均勻
  缺點: 沒法知道數據在哪一個節點
• 每一個分片保存主鍵一個範圍內連續鍵值 (partition by key range)
  優勢: 容易算出主鍵在哪一個節點. 主鍵可有序存儲，方便範圍搜索
  缺點: 每一個分片數據可能不均勻，須要調節分片邊界 --> 手動或自動. 主鍵前綴解決分佈問題
• 按主鍵HASH值分片: （riak, couchbase, voldemort）
  優勢: 理論上數據均勻，取決於HASH算法. 容易算出數據在哪一個節點
  缺點: 難以進行範圍搜索
• 混合模式: 聯合主鍵，先按主鍵第一個屬性HASH，再按其餘屬性有序排列 (cassandra)
  適合處理一對多數據
  處理數據傾斜和熱點鍵讀寫:
  須要應用層解決: 如對鍵值增長隨機先後綴. 缺點: 同一個鍵值的數據分散在不一樣分片內，增長讀取複雜度

  問題2: 如何查詢數據?

  分片策略解決了寫和主鍵查詢的問題，可是如何解決其餘查詢條件查詢？如何在數據分片的狀況下創建二級索引?

• 本地索引: 每一個分片單獨維護二級查詢條件到主鍵列表的字典映射
  優勢：寫數據時更新索引時容易
  缺點：查詢必須在每一個分片的二級索引中查找，再合併結果
• 全局索引: 一個獨立的索引結構覆蓋全部分片，索引自己也分片，按照索引對應的查詢條件 （term partitioned)
  優勢：查詢索引落到單個分片,效率高，若是採用RANGE分片也支持範圍查詢
  缺點: 寫入數據複雜，寫操做會影響多個分片(數據分片和索引分片未必在同一個節點), 須要分佈式事務支持, 或者採用異步方式，犧牲一致性,新寫入的數據未必馬上在索引中可見.

  問題3: 集羣擴容或者有宕機節點分片數據如何處理?

  分片數據須要從一個節點遷移到另外一個節點 (partition rebalancing)

  數據重平衡需求:

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

     數據重平衡策略:

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

  人工或自動平衡:

  自動重平衡
  優勢：不須要人工干預
  缺點：分片數據移動是昂貴的操做，會對集羣性能產生不可知影響，並容易引發雪崩效應
  人工重平衡
  優勢：可控性強
  缺點：響應速度慢

請求路由：

重平衡以後客戶端須要知道鏈接到哪一個節點

• 客戶端可鏈接到任何節點，若是分區存在則處理請求，不然由節點負責將請求發往分片所在節點
  優勢：客戶端不須要存儲分片METADATA，
  缺點：請求roundtrip時間可能變長
• 單獨的路由層負責接收客戶端請求並轉發，路由層須要瞭解分片存儲METADATA
  優勢：客戶端不須要存儲分片METADATA，
  缺點：請求roundtrip時間可能變長

• 客戶端存儲分片METADATA並直接路由到新節點
  優勢：直接路由, 速度快
  缺點：客戶端須要感知分片topology變化

  客戶端感知路由變化是一個挑戰性的問題. (網絡延遲/分區等), 須要分佈式一致性協議，或者用集中式路由METADATA存儲如zookeeper等

並行QUERY執行:

分析型數據庫須要將複雜的QUERY分解成可多個併發執行的分片和階段，構成一個有向無環圖

其餘：通常SHARDING和REPLICATION會一塊兒使用，一個分片會保存在多個服務器上一致性HASH: 主要解決CDN網絡隨機選擇分片邊界而不須要一個集中式的一致性協議，通常不太適合使用於數據庫