隨著分布式數據庫日漸成熟，在推廣使用上開始步入深水區。在這一過程中，對企業的架構、運維、開發都帶來不小的沖擊，如何快速掌握這一新技術，盡快落地成為大家關注的焦點。本文從開發者的視角出發，討論使用分布式數據庫所面臨的難點之一：數據分片策略，這也是阻礙很多企業上到分布式數據庫的核心問題。
1. 數據分片策略是什么
分布式數據庫的核心能力之一，就是通過數據分片存儲，來承載更大的數據規模和計算負載。數據分片，是把數據庫橫向擴展到多個物理節點上的一種分布式技術。可以理解為將表數據按照特定的分片規則水平切分成若干片段(shard)，使這些數據片段分布在不同物理節點上。數據分片從大類可分為垂直分片和水平分片，前者是按業務類別進行拆分，常見為業務拆庫；后者則是以字段為依據，按照一定策略拆分到若干表中。本文后面所談的數據分片，是針對后者。那么如何將數據從單體更換為分布式，這就需要考慮數據分片策略。數據分片策略包括分片算法、數據分布、分布關系等，簡單描述參見下表。
圖片
2. 分布式數據庫分片策略
業內分布式數據庫產品，針對數據分片策略通常有三種做法。一種是基于主鍵/唯一索引/隱含主鍵等做統一數據分片，即用戶無需人為設置分片策略；一種是開放若干數據分片算法，用戶可自行創建數據對象時人為指定；還有一些數據庫中間件產品，支持更為靈活的分片方式，可以讓用戶自行擴展。上面三種，我們可命名為內置、開放、自定義。下面從開發者角度，簡單對比下這幾種方式。
圖片
這里解釋一下：
- 內置方式產品，通常對開發者來說更容易上手，使用體驗與單機數據庫基本一致。但由于無法干預分片策略，其靈活性較差且與業務無關。在大部分業務場景下，是需要犧牲性能體驗、消耗更多硬件資源來彌補上述不足。
- 開放方式產品，需要開發者從內置策略中選擇一種相對最優解，其具備一定靈活性也兼具了性能表現，可滿足絕大多數場景的需要，只有個別業務因其特殊性很難找到合適分片策略，需要業務定制改造。
- 自定義方式產品，為開發者提供最大的靈活自由度，但也意味著易用性較差及需要開發運維方面做更多工作，很難做到標準產品化。
3. 分片實施難點與解法
除了第一種方式外，其余兩種都涉及一個問題就是現有數據對象如何拆分？好的拆分策略，一定是兼顧業務模型、性能最佳、穩定可靠、研發改造、運維難點等多種因素下，結合分布式數據庫的特點而做的最優解，這是在多種因素下平衡的結果。在具體實施上，需要收集大量信息后才能做出決定，下面將主要部分整理為一個表格。
圖片
圖片
從上表可見，數據分片設計過程中，需考慮的問題很多，是一個多維立體的模型分析過程。包括對企業的業務流、數據流、數據模型、業務特征、基礎環境等諸多方面的考慮。上述還需要結合分布式架構數據庫的能力理解才能得出一個相對“適合”的設計方案。這對于企業來說是非常痛苦的，也是阻礙企業上到分布式數據庫的難點之一。不能將上述包袱完全推給用戶去完成，而是盡量在數據庫產品側給出答案，即產品需具備數據分片優化推薦功能。如果分片設計不合理，可能造成影響到業務系統的穩定可靠、服務體驗，往往服務體驗是忽快忽慢且最可怕是某一些時刻或者業務場景是最慢的，從而導致排錯分析的困難復雜增加。當然，開始設計很難做到十全十美，但系統在運行中經過不斷摸索后還需數據庫具備一定的在線分片調整能力，例如針對分片類型或分片字段的調整。在這一過程中要做到不中斷現有業務服務的正常運行，其次要做到盡量少地影響現有業務服務的性能體驗（也即控制資源占用對生產環境的業務服務影響），最后要做到盡量快地完成分片信息的調整。
4. 業內產品現狀及展望
目前國內很多分布式數據庫廠商都加強了遷移能力的支持，一般是通過外置工具的方式提供收集、評估、輔助遷移、驗證等一系列流程的支持。下圖是以OceanBase的OMA工具舉例，說明其提供的支持能力。
圖片
通過上圖可見，產品針對數據分片策略部分做的不多，主要是對兼容類的評估工具；即根據數據庫自身能力，評估原有對象、SQL語句需要做哪些改造等。尚沒有實現數據分片策略的推薦工作，處于空白。其實去年公眾號也發布過一篇文章，就是想通過小工具去完成這一過程，只是目前還未看到有廠商產品支持。相信未來這一能力得到支持后，將加快國內企業選擇分布式數據庫實踐之路。
