AntDB 分布式資料庫如何合理選擇分片鍵

AntDB 如何合理選擇分片鍵

本文主要探讨AntDB 分片鍵設計規則。

通過本文闡述下列功能：

• AntDB 分片介紹
• AntDB 分片要解決的問題
• 常用分片字段優缺點分析

AntDB 分片

分片鍵(sharding Key)

分片是将一張分布式表按照指定的分片鍵(sharding Key)和分片模式(sharding Mode)水準拆分成多個資料片，分散在多個資料存儲節點中。對于分片的表，要選取一個分片鍵。一張分布式表隻能有一個分片鍵，分片鍵是用于劃分和定位表的列，不能修改。

分片模式(sharding Mode)

• 散列Hash

  即按表的分片鍵（sharding Key）來計算哈希值，并将取模後的值(哈希值%1024)與資料節點建立映射關系,進而将哈希值不同的資料分布到不同的資料節點上。

分片目的

解決資料庫擴充性問題，突破單節點資料庫伺服器的 I/O 能力限制。

分片政策

1. 1000萬以内的表，不建議分片. 通過合适的索引，可以更好地解決性能問題。
2. 分片鍵不能修改。
3. 分片鍵選擇時，盡量保證資料能夠均勻分布。
4. 分片鍵選擇時，盡量保證事務控制在分片範圍内(本節點)，避免出現跨分片(跨節點)。
5. 繼承表的分片鍵，子表保持和父表一緻。

總體上來說，分片鍵盤的選擇是取決于最頻繁的查詢 SQL 的條件。找出每個表最頻繁的 SQL，分析其查詢條件，以及互相的關系，就能比較準确的選擇每個表的分片政策。

分片要解決的問題

跨節點join問題

隻要是進行切分，跨節點Join的問題是不可避免的。但是良好的設計和切分可以減少此類情況的發生。

解決這一問題，要求分片字段和join連接配接字段保持一緻，當查詢可以下推至節點運算時，可以有效解決此類問題。

如果運算不允許下推至節點，可以将資料量較小的表修改為複制表後(資料量不超過1000萬)，也能實作本節點運算的能力。

跨節點order by,group by,count等聚合函數問題

這些是一類問題，因為它們都需要基于全部資料集合進行計算。

解決這一問題，要求分片字段和聚合字段保持一緻，當聚合可以下推至節點運算時，可以有效解決此類問題。

常用分片字段優缺點分析

考慮使用 phone-number(唯一值) 字段作為分片鍵

每個人通常都有自己獨一無二的電話号碼,這類重複率低的字段作為分片鍵 能夠保證叢集中資料的均勻分布,是一種推薦的分片方式。

考慮使用 areacode(區号) 字段作為分片鍵

這個字段的取值範圍是給定的一個清單,由于總的區号的個數并不多,所有areacode相同的資料都會分布在同一個資料節點中.由于各個地區的資料量不均勻,導緻資料分布産生不均衡,這會帶來一些影響:

當按區号聚合查詢時，SQL整體執行效率完全取決于 資料量較大的區号 的響應時間，産生圓桶效應。

考慮使用 date(日期) 字段作為分片鍵

這個字段和 areacode 類似，也是一個範圍區間，但是可以有效避免資料分布不均勻的問題。但當查詢的日期區間不是資料節點倍數的時候，查詢目标結果集的資料量卻産生了不均勻，也會産生圓通效應。

如一個8節點的叢集，某表按日期分片後，隻查詢連續12天的資料，此類場景，将産生計算不均勻的現象。