?分布式數據庫，無疑是近些年來數據庫領域的重大技術進步。越來越多的用戶考慮將傳統集中式或單機數據庫，遷移到分布式數據庫。然而，正如同其他新技術一樣，使用分布式數據庫同樣面臨一定的使用門檻。如何平滑地遷移到這一新架構，享受新架構帶來的優勢的同時，還需規避潛在的劣勢。盡管很多分布式數據庫產品，正努力降低使用門檻，讓用戶近似傳統數據庫的體驗去使用它，但這一過程仍面臨諸多問題。此外，要想更好地使用分布式數據庫，是需要其實現細節有著更多的了解。本文，嘗試從研發角度談談，如何上手分布式數據庫，針對常見的如何做表分片、如何選擇分片鍵等問題加以描述。為了降低過程難度，結合之前在項目實施中的一點經驗，自己也嘗試編寫工具來方便遷移分析。

1. 分布式數據庫設計要點

1).選擇分片對象

分布式數據庫設計的第一個要點，就是選擇需分片的對象。這其中需考慮幾個問題：

數據規模

一般來說，選擇分布式數據庫的常見原因之一就是原有數據庫容量不足，通過分布式架構存儲更多的數據。因此，大數據量的表是優先采用分片設計的首要理由。當然，也存在些特例情況，如表雖然規模很大，但無法明確使用到部分數據或數據不經常使用等，也可考慮使用數據分析或大數據平臺。

熱點表

還有一種常見的的情況是表雖然不大，但非常熱，在單機或集中式架構下成為熱點，存在性能擴展的瓶頸。這種情況下，也適合采用分片方式將其分而治之。

管理需求

第三種情況是有些表有著管理需求，如歸檔、清理、備份等，也可以通過分片設計更精準地滿足此類需求。

誤區：所有表都需要分片

在分布式數據庫下，是否是所有對象都需要分片呢？答案是否定的。當表采用分片化設計后，在享受到分片帶來的收益的同時，勢必也會有損失。如數據庫約束會受到限制、數據表訪問存在約束、數據庫結構變更更為復雜等。因此，在分布式數據庫下仍可考慮采用“單表”設計。此時，就需要考慮如存儲位置（單片或廣播）等。

2).選擇分片鍵

當確定了哪些表采用分片設計后，后面的問題就是確定每個表的分片鍵如何選擇？這往往也是分布式改造中最難取舍的地方。因為，分布式數據庫下，數據只能按照一種方式分布。數據分布的方式主要就是由分片鍵字段和選擇的分片算法來確定。因此，選擇一個最具有代表意義的字段最為分片鍵尤為重要。而選擇依據主要是看表是如何被訪問的及字段的數據特征，根據多種因素綜合考慮。當表按照某種分片邏輯拆分后，其他無法使用該拆分邏輯進行的訪問又該如何處理呢？這是可考慮如異構二級索引、冗余對象等方式來解決了。下文介紹的小工具，就是從SQL語句的角度分析潛在的劃分依據，供設計者參考。后面將詳細展開說明。

3).關聯對象設計

當表確定了分片方式后，其關聯對象需同步進行設計。這里面設計包括：

約束

在分布式架構下，傳統的約束會受到很大限制，這其中包括主鍵、外鍵、非空、唯一、檢查五類。很多分布式數據庫不再支持上面這些約束中的部分。這時就需在設計時有所考慮，將約束能力上移到應用側去解決。

索引

索引，是優化數據庫訪問最常用的手段之一。在分布式架構下，索引能力同樣有所限制。一般來說，若索引字段前綴包含分片字段，還可以支持；否則，只能通過異構索引方式來實現。可簡單理解為，分布式架構下的索引就是按照另一種方式存儲的分片表。當然，過多的索引在分布式架構下，開銷也是很大的。因此，因分布式架構下分片內的數據已經有限，某些索引是可以考慮不再創建。

序列

序列，主要是為了滿足唯一性或自增類需求的。這一能力在單機或集中式架構下比較簡單，在分布式架構下通常可考慮用“分布式ID”的方式實現。功能上較之前還是有所限制，特別是自增需求。有些分布式數據庫雖然支持，但性能也會較差。

視圖

一般來說，分布式數據庫支持簡單視圖，對于復雜視圖來說則各有差異。此外，需要注意的是優化器的差異。針對視圖類的優化，是比較考驗優化器能力的，這點各家產品差異較大。

庫內計算（存儲過程、函數、觸發器等）

針對庫內計算，是單機或集中式數據庫的一大優勢。離數據越近的運算，其效率往往也越高，但對于分布式數據庫，存在較大技術難點。目前行業內，能較完美地支持分布式架構下的庫內計算，尚有不小的差距。建議還是在應用側去解決。

4).關聯語句驗證

在做好上述分片設計后，很重要的一步就是要驗證上面設計是否滿足需要。驗證的方式就是將對象關聯的語句提取出來，分析在分布式條件下的運行情況。這里包括語法是否支持、語義是否等價、效率是否有保障？若上述驗證不滿足預期，就需要考慮做出調整。有些可通過改寫方式解決，有些更為復雜情況可能需考慮在應用側甚至架構層面來解決。這一過程也是很多分布式改造的痛點，存在大量驗證過程。

5).其他需考慮因素

除去上述要點外，還有其他因素值得關注：

分區表情況

在傳統數據庫中，應對海量數據規模的有效手段之一就是分區。是否在分片條件下仍然使用分區，是需要綜合考慮的。原則上來講，數據經過分片設計，已經減少處理規模，分區必要性有所降低，要綜合考慮。

復雜計算情況

分布式架構下，有些計算是無法下推到分片內完成的，這就需要提取分片數據，匯聚后計算。這對于上面的計算層的壓力較大，也會造成很大的資源開銷。這點要關注到分布式數據庫的處理邏輯，驗證其這方面能力如何。

數據分析需求

針對數據分析類需求，很多分布式數據庫考慮到這點，引入諸如HTAP方向的技術能力來解決。有此類需求的場景，需重點驗證。

2. 工具實踐：分片設計輔助分析

如上面闡述，在分布式數據庫改造中，選擇需分片的表、確定分片字段及方式是非常重要的環節。之前在不少客戶實施過程中，這一過程較為繁瑣。雖然通過用戶培訓，能夠了解原理上手設計，但在實操中如何從紛繁復雜的運行環境中找到要點，在眾多可能選擇中選出相對較優仍比較困難。為解決上述問題，自己嘗試通過工具解決上述痛點，降低遷移難度、減少工作量。其原理是以運行環境中SQL為輸入，通過解析SQL語句，找到業務核心對象及使用方式；再關聯數據字典提取數據特征，方便設計者快速做出選擇且不遺漏重要信息。下面根據工具輸出，簡單介紹下，感興趣者可與我私聊。

1).輸出解讀

概覽信息

此部分主要為概覽性信息，主要包括數據庫及分析語句。

此部分為收集數據庫信息。目前支持MySQL，其他數據庫可擴展支持。

此部分為分析SQL文本。根據輸入，可能為多條。

設計參考

此部分是根據輸入的SQL語句，提取出表。根據數據字典信息提取表的統計信息。這里需重點關注表大小。如上面所說，表大小分片設計的考慮因素之一。小規模的表，是可以考慮設計為單表或廣播表。

此部分是根據數據表，提取索引信息。這些原有的索引設計，可作為后續分片設計的參考之一。此外，分片情況下索引代價過大，也可根據此信息做取舍設計。

此部分根據SQL語句解析結果，提取關聯或過濾謂詞；并進一步將謂詞左右的字段及字段數據特征顯示出來。這些提取出的字段，可作為分片鍵字段選擇的重要參考依據。其對應的數據類型、是否為空、基數及使用它的謂詞，可方便設計者快速決策。

2).使用建議

工具使用上，可依據如下步驟：

提取業務SQL。可通過系統日志、數據庫日志等，提取業務SQL，作為工具輸入。提取的SQL需真實反應線上情況，不遺漏重要的業務SQL。

分析業務SQL。通過工具分析提取SQL，獲取輸出報告。

輔助設計。得到報告后，可根據數據量定位待分片表；根據表字段及謂詞字段，確定分片鍵的范圍；根據前面信息和索引，做出初步的設計決策。

驗證設計。根據初步的設計結果，在分布式環境下驗證上述設計，判斷是否滿足之前提到的語法、語義及性能。

3).增強改進

這一工具，目前僅考慮到SQL文本，未來可增加對runtime信息的捕獲能力，可更為準確描述業務負載。從上述信息中增加對不同語句權重，為后續設計判斷提供更為豐富的依據。?