582      阿裏雲  技術社區[雲棲]

數據拆分策略__最佳實踐_分布式關係型數據庫 DRDS-阿裏雲

切分維度的選擇是決定我們的分布式數據最重要的一個權衡性因素，需要審慎選擇，一般而言，您可以按照以下五個維度進行思考和權衡，包括數據均衡度考慮、事務邊界因素、常用查詢效率考慮、異構索引考慮、簡單性策略。 每一個應用業務類型可能都不太一樣，也不太可能匹配所有因素的最優策略，具體采用何種方式，還需要通過綜合考量，每個因素都不能太走極端，否則會導致開發運維成本急劇增長。

容量和訪問均衡

一般來說數據容量和訪問均衡是我們考量的第一點，不均衡的數據分布和訪問可能不能充分發揮數據拆分的能力，讓訪問體驗變差，同時帶來成本上的損耗，相當於1+1<2的效果。所以一般來說拆分字段區分度比較大，數據分布和訪問相對會比較均衡，但是這點也需要考慮到某一個拆分值是否有熱點的問題。

那麼按照這個原則，能否按主鍵拆分(區分度最大)呢？我們沒有禁止按主鍵拆分，但是不推薦，因為按主鍵拆分，如果要保持最佳性能，你每個sql都需要帶上這個主鍵字段(當然不帶掃描所有數據分片也可以，隻是性能會降低)。

事務邊界

事務邊界越大(或者單個sql所執行的數據分片數)，那麼係統的鎖衝突概率越高，係統越難以擴展，性能越低。因此，若想將您的係統做到很好的擴展性，那麼一個最重要的原則就是想辦法劃小事務邊界，並盡可能讓事務的邊界限製在單台機器內。縮小事務邊界的方式，主要有以下三類：

第一種方式：事務邊界本來就很小

比如，您發現按照某個切分條件，數據分布均勻，並且事務邊界隻在單機內，不需要跨機事務，那麼恭喜，這個切分條件是非常合適的切分維度。

第二種方式：使用基於消息的最終一致模型，將強一致事務變為最終一致事務

針對事務的拆解，是個比較複雜的概念，我們會專門進行闡述，在這裏隻針對一個最常見的最終一致性事務拆解模型做出簡單說明。例如，當我們要通過分布式事務完成在兩台數據庫內的數據轉賬操作的時候，我們會發現有些操作不得不通過網絡而進行傳遞，這明顯的增加了單次事務的延遲，極大的降低了性能。

第三種方式：謹慎的使用分布式事務

使用最終一致性事務，一般隻能解決90%的業務場景，剩下的一些場景，可能還是需要使用分布式事務方式完成。但分布式事務必然帶來非常多的性能問題，因此，我們隻建議在不得不使用分布式事務的時候，才使用。

常用查詢

對於常用查詢優化的核心要義，就是盡可能讓您的一次前端請求，物理上直接發送到一台存儲的機器上，盡可能避免那些需要將請求下發到多台機器的查詢。下發到多台機器的查詢，雖然每次查詢的延遲不會出現問題，但這類查詢會導致一次請求物理上必須被發送到很大一批存儲的機器上，會額外占用過多下層數據節點的各類的資源，因此應該盡可能的與以避免。

異構索引

在上麵的例子中出現的都是隻按照一個維度進行查詢時的處理方式，那麼如果這個係統會有多個主要的查詢維度時，我們又能有什麼處理方式呢？

第一種方式

就是接受全表掃描，雖然這會帶來更多地讀取量，但我們可以通過水平加備庫的方式，近乎無限的擴展我們的讀取能力。因此是一個可行的方案，隻是成本略高。

第二種方式

如果想進一步降低成本，我們可以考慮使用異構索引表，其本質就是利用異步觸發器，將原表內的每一次更新，都換一個寫入的維度，寫入到新的表中。如果您對數據庫比較熟悉，那麼簡單映射一下，異構索引表的作用就基本等同於傳統數據庫中的索引概念，其不同之處，主要是索引構建過程從同步改成了異步，索引表和主表之間可能存在100ms左右的延遲

保持簡單

處理各方麵衝突，在真實的世界中，切分鍵的選擇往往都是充滿著各種誘惑，選擇A方案，有這些好處。而選擇B方案，也會有那些好處。

如果查詢優化與均衡讀寫訪問兩個選項發生了衝突，那麼請選擇均衡讀寫訪問作為優先考慮原則，因為查詢的問題相對的更好解決，無論是加機器做全表掃描或做異構索引複製都是可以解決的。而寫入或單機容量如果出現不均衡，那麼處理起來難度就比較大。

盡管複雜的切分規則或取巧的程序代碼能夠帶來短期係統性能或成本上的好處，但其後麵所帶來的係統運維複雜度上升將會吃掉之前您在係統中獲得的大部分好處。因此，從係統架構上來說，以82法則，簡單直接處理的方式往往是最有效的方式。

最後更新：2016-11-23 16:04:05

  上一篇： DRDS操作__快速開始_分布式關係型數據庫 DRDS-阿裏雲

  下一篇： 應用連接池選擇__最佳實踐_分布式關係型數據庫 DRDS-阿裏雲