第七十七期 再探分布式

上一次系統(tǒng)探討分布式數(shù)據(jù)庫還是在第三十六期，經(jīng)過大半年的“進(jìn)步”加上中間參加了不少國產(chǎn)數(shù)據(jù)庫的研討會或者交流，對分布式數(shù)據(jù)庫的理解還是有了些許進(jìn)步。

1 單機(jī)分布式

最近出現(xiàn)了所謂的“新詞”：單機(jī)分布式，簡言之就是一臺服務(wù)器運(yùn)行多個數(shù)據(jù)庫實(shí)例，通過spanner框架等技術(shù)，通過服務(wù)器本機(jī)內(nèi)存而不是網(wǎng)絡(luò)實(shí)現(xiàn)數(shù)據(jù)庫實(shí)例之間的數(shù)據(jù)交互。同時分片也能分布在不同服務(wù)器上，并實(shí)現(xiàn)跨服務(wù)器跨機(jī)房跨區(qū)域的副本。
在我看來單機(jī)分布式的出現(xiàn)有以下幾個原因：

• 高性能服務(wù)器性能卓越，CPU核心巨多、內(nèi)存巨大、NVMe SSD巨快
• 單個數(shù)據(jù)庫實(shí)例無法完全使用高性能服務(wù)器的硬件性能資源（數(shù)據(jù)庫本身差距或一些系統(tǒng)原因影響）
• 環(huán)境網(wǎng)絡(luò)能力不足，10GE網(wǎng)絡(luò)無法滿足大量數(shù)據(jù)庫實(shí)例間的網(wǎng)絡(luò)交互

第三十六期也講過，分布式數(shù)據(jù)庫的很多操作對內(nèi)存和網(wǎng)絡(luò)開銷是災(zāi)難性的，所以單機(jī)分布式也是為了減少這方面的影響。同時更少的服務(wù)器也能極大減輕維護(hù)壓力。
但是單機(jī)分布式本身又會帶來一些其他的問題，比如各個數(shù)據(jù)庫實(shí)例對CPU、內(nèi)存、IO的爭用，當(dāng)然對于CPU和內(nèi)存可以使用類似于Cgroup之類的技術(shù)實(shí)現(xiàn)隔離，IO則只能通過把不同實(shí)例分別部署在不同的物理磁盤上實(shí)現(xiàn)資源隔離。

2 分布式改造

正如我第六十九期講的一樣，各個使用分布式架構(gòu)的國產(chǎn)數(shù)據(jù)庫廠商基本上都在有意無意的避開分布式改造這件事情，其中需要涉及的代碼改造、業(yè)務(wù)邏輯改造、數(shù)據(jù)邏輯改造要么不提要么就一筆帶過，更有甚者直接說，我們的數(shù)據(jù)庫不需要分布式改造。我還是那句話，就算是用單機(jī)分布式，原來使用集中式數(shù)據(jù)庫向分布式數(shù)據(jù)庫遷移，不進(jìn)行分布式改造都是放屁和耍流氓。
為啥不提或隱去分布式改造需求，我認(rèn)為有以下幾點(diǎn)：

• 可以賣更多的數(shù)據(jù)庫實(shí)例license（向錢看，可能還能順便幫助客戶進(jìn)行服務(wù)器換代）
• 可以深度綁定數(shù)據(jù)庫廠商（跑不動就給優(yōu)化）
• 可以更加便捷的入場（反正坑的是業(yè)務(wù)開發(fā)方）

總而言之，只要上船了，就可能任人宰割了。

3 嘗試改造一個訂單系統(tǒng)

這里我自己“編”了一套基于Oracle數(shù)據(jù)庫架構(gòu)的商城訂單系統(tǒng)的數(shù)據(jù)庫表設(shè)計(jì)：

這里的設(shè)計(jì)并非涉及訂單系統(tǒng)的方方面面，主要還是涉及訂單的主要內(nèi)容：其中備注中的外面標(biāo)識僅表示有主外鍵關(guān)系并非一定建立外鍵；表類型涉及基礎(chǔ)數(shù)據(jù)、生產(chǎn)數(shù)據(jù)；各表按照范式要求進(jìn)行設(shè)計(jì)。
接下來我們以5個分片為例，嘗試對這個系統(tǒng)的數(shù)據(jù)庫設(shè)計(jì)進(jìn)行分布式改造，這里不考慮分片內(nèi)是多副本還是主備，也不考慮高可用等因素：

3.1 表類型和分片鍵選擇

表的類型（單表、復(fù)制表、分片表）和分片鍵的選擇其實(shí)是相關(guān)聯(lián)的，如何選擇分片鍵也就選擇了表的類型。首先我們可以判定本次涉及的表不會涉及到使用單表（當(dāng)然如果加上一些系統(tǒng)配置信息是可以使用單表的）；那么在分片鍵的選擇就是重中之重。
下面以黃色指代復(fù)制表，以紅色指代分片表。

• 以用戶進(jìn)行劃分
  這里我認(rèn)為沒有必要根據(jù)用戶進(jìn)行劃分，因?yàn)槿说南M(fèi)能力、消費(fèi)習(xí)慣是千差萬別的，通過用戶進(jìn)行劃分，即便是通過hash方式打散都很難做到最終涉及訂單分片的跨分片數(shù)據(jù)平衡。

• 以商品類型進(jìn)行劃分
  同和用戶劃分類似，商品的銷售量也是千差萬別的，涉及國計(jì)民生的商品銷量可能很大，而奢侈品銷量則可能很小，而這里又無法以自然劃分的方式像地域那樣進(jìn)行劃分，更可能的是某些大類需要拆成幾種小類到多幾個分片（甚至出現(xiàn)小類也需要分片或分片內(nèi)分區(qū)），而某些大類則可能需要合并在一起到一個或少數(shù)幾個分片。

• 根據(jù)地域進(jìn)行劃分
  首先我們需要考慮一點(diǎn)，每個省根據(jù)人口、消費(fèi)水平，各省的訂單數(shù)量差距是有點(diǎn)大的，為了確保每個分片所涉及的數(shù)據(jù)量保持一致，所以需要在省表之上建立一個片區(qū)表，根據(jù)訂單數(shù)量對片區(qū)進(jìn)行劃分，同時對省表、訂單表和地址表還要做一些調(diào)整：
  
  分片情況如下：
  
  這里訂單主表通過與片區(qū)表的主外鍵關(guān)系確保訂單信息和地址相關(guān)信息都會存放在一個分片內(nèi)；訂單主表與詳表之間的關(guān)聯(lián)數(shù)據(jù)也通過主外鍵保持在一個分片內(nèi)；而由于商品信息是全國化的，所以商品表是全局保持一致的復(fù)制表。這里需要考慮下面幾個問題：
  – 商品表也可能出現(xiàn)數(shù)據(jù)量過大的問題，甚至?xí)驗(yàn)橄嗤纳唐吩诓煌赇仯ū敬挝瓷婕埃┲g而出現(xiàn)更加龐大的數(shù)據(jù)量維護(hù)，這就可能出現(xiàn)分片內(nèi)關(guān)聯(lián)查詢數(shù)據(jù)比較大的問題。因此在涉及商品數(shù)據(jù)查詢時，要把SQL語句寫好，或者換一種方式獲取商品信息（列存、全局搜索等）。
  – 用戶表數(shù)據(jù)量可能非常龐大，如果按照片區(qū)進(jìn)行關(guān)聯(lián)分片則需要考慮用戶跨片區(qū)下單和用戶變更片區(qū)的問題，主要是跨分片查詢；如果作為復(fù)制表則可能每個分片都要維護(hù)一個賊大的用戶表，分片內(nèi)關(guān)聯(lián)查詢則可能出現(xiàn)一些性能問題。但用戶跨片區(qū)購買和片區(qū)變更畢竟是少數(shù)，因此用戶表仍然可以考慮使用分片表。但還是建議根據(jù)更加詳細(xì)的數(shù)據(jù)模型進(jìn)行判斷，并需要考慮用戶相關(guān)的業(yè)務(wù)邏輯、語句書寫。
  – 如果地域相關(guān)表完全分片有兩個問題，首先是地域表數(shù)據(jù)量是非常小的其實(shí)沒必要分片，第二是在跨分片查詢時需要上升到元數(shù)據(jù)獲取分片信息，因此其實(shí)可以數(shù)據(jù)還是按照地域進(jìn)行劃分，而地域相關(guān)的表則配置為復(fù)制表。
  綜上進(jìn)行一些變更：
  
  我認(rèn)為這樣的設(shè)計(jì)就當(dāng)前涉及范圍是相對比較合理的。

3.2 擴(kuò)展分片

這里我們考慮一個情況，咱們東邊的（原屬于北區(qū)和南區(qū)的部分區(qū)域）業(yè)務(wù)量增長比較迅速，導(dǎo)致分片3和4有點(diǎn)扛不住了，需要通過增加一個分片的方式把東區(qū)（江浙滬）以外給劃分出去，這里就會涉及部分分片數(shù)據(jù)變更的問題：

之前也講過，這樣的操作對集群壓力還是挺大的，這里需要將原來在分片3和4上的部分數(shù)據(jù)查出來并傳輸?shù)椒制?上（按照很多廠商的說法這個是業(yè)務(wù)無感的），如果業(yè)務(wù)仍然在運(yùn)行還需要考慮遷移過程中的數(shù)據(jù)一致性；遷移完成校驗(yàn)數(shù)據(jù)后還需要在分片3和4上刪除移走的數(shù)據(jù)。這一系列操作會對服務(wù)器性能以及網(wǎng)絡(luò)的極大占用，是大概率影響數(shù)據(jù)庫性能的，還有就是集群元數(shù)據(jù)更新的壓力；另一方面如果分片是使用的副本，那么操作成本更大。
這里薛老師也補(bǔ)充了一下，如果某些業(yè)務(wù)按照hash分片是一次性從10個分片擴(kuò)展至20個分片，那么還是停機(jī)吧，數(shù)據(jù)重新平衡的過程數(shù)據(jù)庫是幾乎不可用的。

3.3 業(yè)務(wù)擴(kuò)展

根據(jù)精細(xì)化、網(wǎng)格化要求需要添加街道表：

同時還要在地址表添加相關(guān)內(nèi)容：

以上兩個操作在集中式數(shù)據(jù)庫中僅需增加一個表、變更一個表（操作也不小就是了）。而在6個分片上總共相當(dāng)于要增加6個表并變更6個表，同時至少增加6個新增表的元數(shù)據(jù)維護(hù)，并增加集群間復(fù)制表的同步壓力。
這只是一個簡單的需求增加，如果涉及復(fù)雜的需求變更在分布式數(shù)據(jù)庫上要考慮的更多的東西，做更多的操作（原諒我想不出來復(fù)雜的變更，歡迎大佬添加）。

總結(jié)

我不是一個開發(fā)，也不是架構(gòu)師，加上上面的一個例子也沒有完全覆蓋對應(yīng)的業(yè)務(wù)場景，所以大家看看就好。
我覺得上分布式還是很難的，而且根據(jù)當(dāng)前的硬件發(fā)展水平來看也是沒有必要的，當(dāng)然也提到過用不完硬件資源這個問題，就完全是很尷尬的為了分布式而分布式了。
老規(guī)矩，不知道寫了些啥。文章來源地址http://www.zghlxwxcb.cn/news/detail-481254.html

到了這里，關(guān)于數(shù)據(jù)庫管理-第七十七期 再探分布式（20230523）的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！