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

1. 分散式資料庫設計要點

1).選擇分片物件

分散式資料庫設計的第一個要點，就是選擇需分片的物件。這其中需考慮幾個問題：

❖ 資料規模

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

❖ 熱點表

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

❖ 管理需求

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

誤區：所有表都需要分片

在分散式資料庫下，是否是所有物件都需要分片呢?答案是否定的。當表採用分片化設計後，在享受到分片帶來的收益的同時，勢必也會有損失。如資料庫約束會受到限制、資料表訪問存在約束、資料庫結構變更更為複雜等。因此，在分散式資料庫下仍可考慮採用“單表”設計。此時，就需要考慮如儲存位置(單片或廣播)等。

2).選擇分片鍵

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

3).關聯物件設計

當表確定了分片方式後，其關聯物件需同步進行設計。這裡面設計包括：

❖ 約束

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

❖ 索引

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

❖ 序列

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

❖ 檢視

一般來說，分散式資料庫支援簡單檢視，對於複雜檢視來說則各有差異。此外，需要注意的是最佳化器的差異。針對檢視類的最佳化，是比較考驗最佳化器能力的，這點各家產品差異較大。

❖ 庫內計算(儲存過程、函式、觸發器等)

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

4).關聯語句驗證

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

5).其他需考慮因素

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

❖ 分割槽表情況

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

❖ 複雜計算情況

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

❖ 資料分析需求

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

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

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

1).輸出解讀

❖ 概覽資訊

此部分主要為概覽性資訊，主要包括資料庫及分析語句。