分割槽

解決問題：解決可擴充套件性

分割槽與複製

通常分割槽與複製是結合在一起的（多副本）

鍵值的分割槽

根據鍵的範圍分割槽

• 每個分割槽可用SSTable以順序方式儲存鍵
• 缺點：某些特定訪問模式會產生訪問熱點
• 解決方法：嘗試用多個欄位組合來建立鍵

根據鍵的HASH分割槽

• 保證平衡性但失去高效範圍查詢的能力

• Cassandra折中策略

  • 複合主鍵的第一列作為分割槽鍵，而後續鍵作為SSTable排序資料連線索引，雖不能在第一列做高效範圍查詢，但後續列可進行範圍掃描

負載傾斜與消除熱點

• 基於應用層，由使用者控制編寫程式將熱點資料打散至各分片，只對熱點資料作處理

分片與次級索引

鍵值的分割槽是針對於主鍵

按文件的二級索引(本地索引)

• 每個分割槽有獨立的二級索引，該索引只對本分割槽的文件建立

  • MongoDB，Riak 【15】，Cassandra 【16】，Elasticsearch 【17】，SolrCloud 【18】和VoltDB 【19】

根據關鍵詞的(全域性索引)

• 按關鍵詞分割槽，對關鍵詞範圍分割槽或對關鍵詞的HASH值進行分割槽

  • 範圍分割槽利於範圍掃描
  • HASH分割槽利於負載均衡

• 特點

  • 優點

    • 讀取查詢索引時只需要查詢一個分割槽

  • 缺點

    • 寫入時可能會修改多個分割槽

  • 寫入的文件與關鍵詞索引構成分散式事務

  • 通常全域性索引的寫入是非同步的

分割槽再平衡

反面教材：HASH MOD N，擴容（如MOD9 改為 MOD10）會造成大量資料遷移

固定數量分割槽，從原節點中遷移部分分割槽使負載能夠平衡

• 由於資料集大小很難預估，具體固定多少數量的分割槽難以確定

  • Riak 【15】，Elasticsearch 【24】，Couchbase
    【10】和Voldemort 【25】

動態分割槽

• 在分割槽大小超過一定值後，分離分割槽；小於一定值後，合併分割槽

  • 如HBase和RethinkDB

• 初始時資料集很小，只會有一個分割槽，隨著分割槽的增大才會分離出多個分割槽。對於多節點的叢集負載不均衡。

  • HBase和MongoDB採用預分割槽
  • MongoDB 2.4以後同時支援範圍和雜湊分割槽，並且都是進行動態分割分割槽

按節點比例分割槽

• 每個節點負責固定數量的分割槽，當叢集新增節點時，隨機選擇固定數量的分割槽，從選中的分割槽中分一半資料移至新節點

  • 例項：Cassandra和Ketama

請求路由

路由轉發

• 客戶端連線其中一個節點，如果訪問的資料不在該節點，則將請求轉發至對應節點，接收回復並傳回客戶端
• 新增路由層
• 由客戶端直接連線有資料的節點，需要客戶端管理路由

節點分割槽分配狀況改變了如何感知？

• 依賴於配置服務

  • 集中式

    • ZK

      • Espresso HBase，SolrCloud和Kafka

    • 自建

      • MongoDB

  • 分散式

    • 基於GOSSIP傳播協議，每個節點均儲存分割槽節點的配置狀況

      • Cassandra和Riak