破解分散式庫使用難點：資料分片策略

隨著分散式資料庫日漸成熟，在推廣使用上開始步入深水區。在這一過程中，對企業的架構、運維、開發都帶來不小的衝擊，如何快速掌握這一新技術，儘快落地成為大家關注的焦點。本文從開發者的視角出發，討論使用分散式資料庫所面臨的難點之一：資料分片策略，這也是阻礙很多企業上到分散式資料庫的核心問題。

1. 資料分片策略是什麼

分散式資料庫的核心能力之一，就是透過資料分片儲存，來承載更大的資料規模和計算負載。資料分片，是把資料庫橫向擴充套件到多個物理節點上的一種分散式技術。可以理解為將表資料按照特定的分片規則水平切分成若干片段(shard)，使這些資料片段分佈在不同物理節點上。資料分片從大類可分為垂直分片和水平分片，前者是按業務類別進行拆分，常見為業務拆庫;後者則是以欄位為依據，按照一定策略拆分到若干表中。本文後面所談的資料分片，是針對後者。那麼如何將資料從單體更換為分散式，這就需要考慮資料分片策略。資料分片策略包括分片演算法、資料分佈、分佈關係等，簡單描述參見下表。

2. 分散式資料庫分片策略

業內分散式資料庫產品，針對資料分片策略通常有三種做法。一種是基於主鍵/唯一索引/隱含主鍵等做統一資料分片，即使用者無需人為設定分片策略;一種是開放若干資料分片演算法，使用者可自行建立資料物件時人為指定;還有一些資料庫中介軟體產品，支援更為靈活的分片方式，可以讓使用者自行擴充套件。上面三種，我們可命名為內建、開放、自定義。下面從開發者角度，簡單對比下這幾種方式。

這裡解釋一下：

內建方式產品，通常對開發者來說更容易上手，使用體驗與單機資料庫基本一致。但由於無法干預分片策略，其靈活性較差且與業務無關。在大部分業務場景下，是需要犧牲效能體驗、消耗更多硬體資源來彌補上述不足。

開放方式產品，需要開發者從內建策略中選擇一種相對最優解，其具備一定靈活性也兼具了效能表現，可滿足絕大多數場景的需要，只有個別業務因其特殊性很難找到合適分片策略，需要業務定製改造。

自定義方式產品，為開發者提供最大的靈活自由度，但也意味著易用性較差及需要開發運維方面做更多工作，很難做到標準產品化。

3. 分片實施難點與解法

除了第一種方式外，其餘兩種都涉及一個問題就是現有資料物件如何拆分?好的拆分策略，一定是兼顧業務模型、效能最佳、穩定可靠、研發改造、運維難點等多種因素下，結合分散式資料庫的特點而做的最優解，這是在多種因素下平衡的結果。在具體實施上，需要收集大量資訊後才能做出決定，下面將主要部分整理為一個表格。

從上表可見，資料分片設計過程中，需考慮的問題很多，是一個多維立體的模型分析過程。包括對企業的業務流、資料流、資料模型、業務特徵、基礎環境等諸多方面的考慮。上述還需要結合分散式架構資料庫的能力理解才能得出一個相對“適合”的設計方案。這對於企業來說是非常痛苦的，也是阻礙企業上到分散式資料庫的難點之一。不能將上述包袱完全推給使用者去完成，而是儘量在資料庫產品側給出答案，即產品需具備資料分片最佳化推薦功能。如果分片設計不合理，可能造成影響到業務系統的穩定可靠、服務體驗，往往服務體驗是忽快忽慢且最可怕是某一些時刻或者業務場景是最慢的，從而導致排錯分析的困難複雜增加。當然，開始設計很難做到十全十美，但系統在執行中經過不斷摸索後還需資料庫具備一定的線上分片調整能力，例如針對分片型別或分片欄位的調整。在這一過程中要做到不中斷現有業務服務的正常執行，其次要做到儘量少地影響現有業務服務的效能體驗(也即控制資源佔用對生產環境的業務服務影響)，最後要做到儘量快地完成分片資訊的調整。

4. 業內產品現狀及展望

目前國內很多分散式資料庫廠商都加強了遷移能力的支援，一般是透過外接工具的方式提供收集、評估、輔助遷移、驗證等一系列流程的支援。下圖是以OceanBase的OMA工具舉例，說明其提供的支援能力。

透過上圖可見，產品針對資料分片策略部分做的不多，主要是對相容類的評估工具;即根據資料庫自身能力，評估原有物件、SQL語句需要做哪些改造等。尚沒有實現資料分片策略的推薦工作，處於空白。其實去年公眾號也釋出過一篇文章，就是想透過小工具去完成這一過程，只是目前還未看到有廠商產品支援。相信未來這一能力得到支援後，將加快國內企業選擇分散式資料庫實踐之路。