資料庫行業解決方案都寫了啥

隨著國產資料庫在各行業應用規模不斷增大，並開始進入深水區。國產資料庫從之前的不能用、不敢用逐漸過渡到如何用好。特別是以分散式資料庫為代表的新架構資料庫產品的出現，顛覆了原有架構產品，之前很多的知識不能複用，如何用好這些成為很多使用者所關注的問題。近期，筆者也觀察到部分國產資料庫廠商經過階段性實踐後，開始將使用心得形成行業解決方案，這無疑對使用者會帶來積極影響，加速行業推廣使用。本文將結合近期釋出的兩家廠商的行業解決方案為基礎，說明下資料庫行業解決方案都應包括什麼內容。

1. 場景：讓使用者判斷是否適合自己

使用者的場景千差萬別，沒有一款產品是可以通吃所有場景的，因此明確的場景描述尤為重要。透過這部分描述，使用者可以快速判斷是否適合自己。這其中場景分為兩種：

1).技術場景

一種方式是描述技術場景，如常見的 OLTP、OLAP、HTAP 等，但這些還是比較寬泛的，需要更進一步的細化。如處理的資料規模大小、計算邏輯怎樣、延遲要求如何等等。如下面這段描述：這是一款分散式資料庫，可滿足百TB以下的關係型資料儲存，可提供數萬的高併發支援，適用於資料計算邏輯簡單，支援簡單點查、範圍查詢及資料變更，在高併發下情況下可提供百毫秒級別的響應時間等。上述技術場景描述，會給使用者一個較為直觀的印象。如果使用者也整理有自己的資料庫場景地圖(如下圖)，就可以很容易的找到結合點。

2).業務場景

另一種方式是描述業務場景，這種方式對使用者而言會更加簡單直觀，畢竟使用者是最瞭解自有業務的。使用者在第一時間就明確了這一產品是否適合自己。如在金融行業，可以透過類似下面的一段話進行描述：某分散式資料庫產品適合於銀行核心系統分散式改造，過去此業務多是透過集中式架構、通用硬體來支撐，無法滿足日益增長的海量資料規模、業務連續性也較差。分散式資料庫產品具備海量規模、高效能處理、強一致事務保證、資料高可靠及服務連續性保證等，並已透過多年實踐在很多銀行系統核心改造中落地。透過上述一段描述，使用者可以很容易產生共鳴。使用者對自身業務是有著明確認知的，例如銀行業業務分類參考下圖。

2. 架構：讓使用者瞭解產品是什麼

資料庫產品是由多元件構成，對於分散式架構產品來說尤為如此。如何讓使用者快速瞭解產品，可透過架構部分進行描述。這裡可透過一張架構圖進行說明，包括哪些元件、元件有何功能、如何與周邊生態協作、高可用實現機理等等。透過這部分可以讓使用者快速瞭解產品構成、工作原理等內容，也為後面進一步展開功能說明做個鋪墊。下面透過一個分散式資料庫架構示意圖說明下

注意這裡不是技術架構、也不是部署架構。前者更強調技術原理及實現，後者則為實施規劃設計階段需考慮。這裡就是簡單的產品功能架構，讓使用者有個概括性瞭解即可。

3. 功能：讓使用者瞭解我能幹什麼

1).現狀描述

第一部分，重點是讓使用者瞭解現在產品能做什麼。這裡不是產品的功能手冊，因此無需對功能做很詳細的說明，但需要將一些重點的能力及使用者比較關注的部分都說到。這裡可包含但不限於這些內容：

• 基本能力：ACID、SQL引擎等

• 儲存結構：行存、列存、索引結構

• 高可用：單機、主備、雙活、多活

• 容災：單機房、同城多機房、異地等

• 擴充套件性：接入、計算、儲存擴充套件等

• 資料整合：匯入匯出、遷移同步等

• 安全能力：使用者、許可權、加密、審計等

• 運維相關：管理、監控、最佳化、備份等

• 生態相容：協議、語法、介面等

• 部署方式：物理機、虛擬化、容器、雲

• 國產化：軟硬體、上下游

2).歷史與發展

第二部分，是描述產品功能的發展歷史及未來路標。產品功能發展是有一定傳承關係的，使用者可從演進版本中找到發展脈絡，更好地瞭解產品。同時，產品未來發展也有助於使用者判斷產品未來發展策略及方向。下圖以 MySQL 為例，做個簡單說明。

4. 規劃：解決使用者產品上線問題

當使用者對產品有了初步瞭解後，並有意願後，該如何上手就是急需解決的問題。首當其中就是上線，需做如下一些工作。

1).硬體評估

資料庫，特別是分散式資料庫，通常有多個元件組成，不同元件的資源消耗模型不同，有的是 CPU 密集、有的是 IO 密集不等。這裡需根據不同元件，給出硬體推薦的配置，方便使用者快速上手。如考慮國產化問題，還需列明對應的國產化軟硬體產品列表，供使用者參考。此外，還和部署方式有一定關係，如雲、容器化部署也有著特殊要求。可參考下表

這裡需要注意的是，資源配置不僅與角色有關，也與負載有關係。上面硬體配置通常只是最低配置，實際生產環境可根據使用者負載進行精確評估，這部分會在資源評估中詳述。

2).資源評估

在做資源評估時，會情況比較複雜，需要考慮多重因素。很多廠商都提供了一個評估模版，使用者可如實填入後，給出相關評估結果。下表簡單說明下需考慮的因素。

這其中會有一些閾值，是根據廠商產品長期實踐後所得出的，是與產品自身架構、功能有關。以負載維度為例，較大負載是需要更高的資源配置，可以簡單根據一些指標做下分列，這樣方便使用者選擇或內建到資源評估小工具。當然，如果能根據業務指標做相應的資源評估，無疑是更好的。

3).容災方式

很多行業都對業務連續性有一定的要求，因此需要確定具體應用的業務連續性目標、設計對應的高可用方案。很多資料庫產品也都支援瞭如單資料中心高可用、同城雙中心、兩地三中心、多地多中心等容災架構模式。技術上基於多副本冗餘技術、一致性複製技術和靈活高可用策略實現多種容災方案，單臺伺服器故障自動切換到本資料中心其他機器的副本上;雙中心以上的機房故障時，可快速切換到其他機房或者城市災難中心，最大程度保證業務連續性。

5. 開發：解決使用者應用開發問題

產品上線後，下一步的問題就是如何開發對接，這裡需要將開發所關心的問題一一說明。

1).快速入門

首先可以透過一個DEMO，讓使用者快速入門。選擇最主流的開發語言，實現一個簡單的 CRUD 即可。目的是使得使用者能夠快速上手。國內很多產品都提供了一定的相容性，例如相容 MySQL、PostgreSQL、Oracle 等，其目的正是降低使用者使用門檻。

2).開發接入

開發者使用此產品，需要關注的一些問題。包括如：連線池配置、應用高可用、負載均衡、字符集選擇、事務控制等。此外，還包括適配一些主流的開發框架、日誌跟蹤工具等，對於開發一開始關注的問題都可在此處說明。

3).資料建模

主流的資料建模方法，是否適用於本資料庫產品，需要有哪些注意事項。

4).結構設計

資料庫物件設計上，有哪些注意事項。對於分散式資料庫而言，物件設計上需要做一些調整以適應分散式架構，包括如資料分片策略、索引設計、自增型別、庫內計算(儲存過程、觸發器等)。特別是資料分片策略，尤為重要。分散式資料庫的基礎就是將資料“大而化小”，但不是所有資料物件都需要做分片。哪些做分片，哪些不做?選擇怎樣的分片演算法?分片的粒度如何?如何規避熱點?如何解決關聯物件的分片問題等等。上述問題都是需要解決的，有些資料庫產品結合在行業的經驗，將常規的分片策略抽象出來給出一定的最佳實踐，這對於使用者來講無疑會大大降低使用難度。通常有如下一些建議：

• 資料分片應儘量均衡

• 儘量減少跨節點事務

• 集合業務特點，梳理主題場景

• 同一主題選擇相同分片鍵

• 分片鍵欄位保持穩定

5).語句開發

制定一套應用開發遵循的開發規範，有利於避免重複觸及資料庫使用常見問題，提高可閱讀性和問題定位速度。包括但不限於：命名規範、事務控制、語句寫法，問題常見於索引、排序、函式、分組、關聯等。

6).效能最佳化

將常用的效能最佳化手段，加以說明。可能包括如：效能分析手段、引數最佳化、模型最佳化、SQL調優等。

6. 遷移：解決使用者資料上線問題

如何將使用者資料平穩遷移上線，很多產品都提供了獨立工具實現對異構資料庫的遷移。這裡可分為三個步驟：

1).事前評估

完成遷移動作，涉及到資料物件結構遷移、資料自身的遷移以及負載評估。前者需要支援異構資料庫物件的對映，這其中包括很多細節(如字符集、空值等)，很多廠商都內建於工具中來完成;資料遷移則涉及對遷移速度、斷點續傳、異常處理等問題;最後則是資料庫負載能否在新產品中得以支撐。除此之外，還包括可能得回退步驟。

2).事中遷移

正式的資料遷移，一般都包括全量資料遷移、增量資料遷移及資料比對三個階段。很多產品都內建於工具中，提供一整套遷移方案。

3).事後割接

當都完成後，需完成最後的割接動作，一般是透過流量重定向到新庫來完成。此時，如果需要後備，可一併提供迴流能力，保證可回切。

7. 運維：解決使用者日常管理問題

運維部分，包括的比較龐雜，如備份恢復、監控報警、擴縮容、升降級、日誌分析等。很多產品都提供了運維平臺來輔助完成上面這些管理動作。

8. 安全：解決使用者的後顧之憂

安全部分，範圍也比較廣，包括主機安全、賬戶安全、傳輸安全、儲存安全、安全審計等。

9. 案例：實踐出真知，效果案例見

很多使用者非常關心同行業的案例情況，一方面這些案例都是經過實踐，具備一定的可參考性;另一方面同行業案例，往往還能反映出很多共性的問題。這其中需重點描述出場景、架構、效果即可。讓使用者有直觀印象即可，也勾起使用者嘗試使用的興趣。