來(lái)源：云數(shù)據(jù)庫(kù)技術(shù)

數(shù)據(jù)庫(kù)打工仔喃喃自語(yǔ)的八卦

1. 老槍：Db2/z和可靠性
2. K.I.S.S (Keep it Simple, Stupid!)
3. 系統(tǒng)驗(yàn)證和測(cè)試：豬肉出廠的質(zhì)檢章

數(shù)據(jù)庫(kù)的可靠性

1、數(shù)據(jù)庫(kù)里的老槍 - Db2 for zOS

上次聊了瑞士軍刀SQLite, 從年紀(jì)上SQLite出生于大數(shù)據(jù)和手機(jī)時(shí)代之前，對(duì)比后來(lái)的大數(shù)據(jù)引擎和云原生數(shù)據(jù)庫(kù)，SQLite可謂個(gè)頭不大，輩分不小了。不過(guò)數(shù)據(jù)庫(kù)的爺爺輩應(yīng)該算是79年的Oracle和83年的Db2/z(z又叫mainframe,國(guó)內(nèi)稱主機(jī))。今天用這把老槍講講可靠性。

系統(tǒng)RAS(Reliability, availability and serviceability)概念最早是由IBM提出，來(lái)形容曾經(jīng)是神一樣存在的主機(jī)（也叫大機(jī)，mainframe)。為什么說(shuō)神一樣的存在呢？主機(jī)是第一批商用計(jì)算機(jī)，1950出現(xiàn)，活躍至今，最新（本文原稿為2022.1）版本為2019.9月的z15。最早的一批商用數(shù)據(jù)庫(kù)就包括主機(jī)上的DB2/z(1983年GA v2.3)。也許你從沒(méi)有聽(tīng)說(shuō)過(guò)，但是如果你每一天在消費(fèi)，過(guò)程中，不論銀行卡，支付寶，微信都會(huì)最終走到銀聯(lián)，而且很可能是工農(nóng)建交等大銀行，那么你的交易就是在主機(jī)上完成和記錄的。

2021年的AWS Re:Invest有一個(gè)session, 講AWS Mainframe Modernization; 2022年初某公告《8.38 億元、中國(guó)銀行單一來(lái)源采購(gòu)：IBM z15主機(jī)》也可見(jiàn)一斑。

神在我們身邊默默的存在，不打擾一片云彩

我們談?wù)摂?shù)據(jù)庫(kù)的可靠性時(shí)候，籠統(tǒng)的時(shí)候會(huì)泛指RAS，大部分時(shí)候單指Reliability。

可靠性Reliability

數(shù)據(jù)庫(kù)系統(tǒng)無(wú)故障可以持續(xù)運(yùn)行的能力。MTBF(Mean Time Between Failure)/MTTF(Mean Time to Faillure)，MTTR(Mean Time to Repair/Recover)。這些都是工業(yè)界通用的衡量標(biāo)準(zhǔn)。具體計(jì)算公式大家自己去Google/wiki。這里盜個(gè)圖湊數(shù)。

2、如何保證可靠性

教科書里有很多，架構(gòu)設(shè)計(jì)的書也可以輕而易舉的找到。本文既然是八卦篇，就只分享現(xiàn)實(shí)世界的事情。那些理論上支撐的功能，原則上不會(huì)宕機(jī)的架構(gòu)設(shè)計(jì)不是這里的重點(diǎn)

怎么能不犯錯(cuò)？do nothing;

要保證軟件不出bug? 一行不寫。

如果不得不code呢？可靠方面先思考這兩項(xiàng)。

2.1核心代碼的復(fù)雜度

架構(gòu)設(shè)計(jì)有個(gè)說(shuō)法K.I.S.S(Keep it Simple, Stupid!)。其實(shí)系統(tǒng)軟件的核心code, 揚(yáng)名天下立萬(wàn)的骨架，也就那么幾萬(wàn)行，完成系統(tǒng)80%的工作，換句話說(shuō)，系統(tǒng)連續(xù)運(yùn)行過(guò)程中每小時(shí)（甚至每分鐘）都必然運(yùn)行的code logic。這些code中簡(jiǎn)潔易懂是系統(tǒng)存活的關(guān)鍵。

簡(jiǎn)潔可減少系統(tǒng)的bug。MySQL依賴最簡(jiǎn)單可靠的nest-loop join算法二十多年，而"先進(jìn)"的Hash Join是在最近兩年才實(shí)現(xiàn)，在MySQL8.0.18正式GA。從算法復(fù)雜度看(兩個(gè)都有改進(jìn)版本)，Nest Loop J是O(MN), Hash J是O(M+N)。Hash join 在教科書里屬于advance的章節(jié)，直接翻譯是“進(jìn)步”，褒義詞。可是另一方面，幾乎所有的advance技術(shù)都更復(fù)雜(電車是個(gè)反例，降維打擊了），需要更多或更特殊的資源才能發(fā)揮其能力。Hash Join就需要在大內(nèi)存支持下才能發(fā)揮，否則要么OOM，要么落盤造成性能斷崖，尤其不適合高并發(fā)的TP場(chǎng)景。比如各位同學(xué)中午在食堂買飯，就是高并發(fā)場(chǎng)景，如果系統(tǒng)中突然出現(xiàn)一個(gè)大查詢把內(nèi)存都吃掉，也把各位的飯就吃掉了。

如何解決這個(gè)問(wèn)題呢？workload management(WLM) 就要被引入，以自動(dòng)調(diào)低“爛”query的優(yōu)先級(jí)，限制其資源。而又引入進(jìn)一步的系統(tǒng)復(fù)雜度。

nest loop保證了每個(gè)join的內(nèi)存空間消耗是固定的，所以在上面場(chǎng)景中，不用WLM，不用系統(tǒng)DBA也可以保證各位吃上午飯。

給我自己頂個(gè)鍋蓋保護(hù)一下，絕沒(méi)有想引戰(zhàn)NLJ vs HJ的意思，PG有比較完整成熟的優(yōu)化器，就好很多?？?，又跑題到MySQL vs PG 了。只是想說(shuō)，如果一個(gè)系統(tǒng)可以簡(jiǎn)單化，就可以減少其bug數(shù)，增加可靠性。

有興趣研究軟件工程的東西，可以看看Unix philosophy。哲學(xué)的事情咱不懂，用數(shù)據(jù)說(shuō)話，第一版Unix據(jù)稱是不到5千行的匯編語(yǔ)言；linux 0.0.1版是10243 line of code(C) 和386LoC(匯編)。多年前，我參與系統(tǒng)軟件項(xiàng)目排期的時(shí)候，是按1.5KLoC/Person-Year 做的計(jì)劃。所以偶爾聽(tīng)說(shuō)系統(tǒng)開(kāi)發(fā)同學(xué)談績(jī)效的時(shí)候提一年幾萬(wàn)行代碼，還經(jīng)常是早春二三月份提交的，兄弟我怕呀。前端同學(xué)代碼量會(huì)多些，不過(guò)這些代碼的生命力會(huì)差些。其實(shí)我認(rèn)為衡量一個(gè)開(kāi)發(fā)的代碼能力不應(yīng)簡(jiǎn)單的line of code, 更應(yīng)該與服務(wù)年掛勾。

那么如果做到simple/簡(jiǎn)單呢，上次八卦SQL的時(shí)候?qū)Ｗ⒌疆a(chǎn)品邊界，就是要有節(jié)制，開(kāi)發(fā)有明確的特點(diǎn)的產(chǎn)品，而不要試圖做大而全的產(chǎn)品。

2.2 測(cè)試

測(cè)試經(jīng)常在數(shù)據(jù)庫(kù)設(shè)計(jì)和實(shí)現(xiàn)過(guò)程中被忽略，尤其在相對(duì)不成熟的開(kāi)發(fā)團(tuán)隊(duì)中 只做簡(jiǎn)單的功能測(cè)試，甚至是單邏輯flow，而不考慮邊界條件。更談不上系統(tǒng)壓力測(cè)試(system stress testing)，比如說(shuō)連接數(shù)/concurrency突然提升情況下，是否還能夠保證吞吐量和延時(shí)保持著正常水平，后面的任務(wù)可以排隊(duì)，而不會(huì)因?yàn)?a target="_blank">高壓力下造成系統(tǒng)完全不可用。

寫code就會(huì)有bug, 越早發(fā)現(xiàn)fix的成本約少。軟件工程中這張圖是1996的文章。每每在前線客戶反饋一個(gè)簡(jiǎn)單的bug, 我腦海里就是這張圖和16000美刀

鄙視鏈那都有，軟件開(kāi)發(fā)也不例外，常常一方面說(shuō)測(cè)試多么重要，一方面測(cè)試工程師的工資級(jí)別屬于末端集結(jié)號(hào)。自然沒(méi)有牛人過(guò)來(lái)投入。這是全球普世的，而某些團(tuán)隊(duì)尤甚。尤其是近些年，開(kāi)始學(xué)Agile，學(xué)開(kāi)源，甚至不設(shè)測(cè)試崗位。殊不知，開(kāi)源社區(qū)最注重測(cè)試，測(cè)試代碼量常常是產(chǎn)品代碼的3X。筆者有幸十年前在HBase社區(qū)打醬油，很是佩服一個(gè)健康社區(qū)對(duì)代碼質(zhì)量的管理。而當(dāng)時(shí)的主席Stack，自號(hào)HBase Janitor（清潔工），最重要的工作就是QA。

上次提到的SQLite, 每一行code對(duì)應(yīng)600行測(cè)試程序?！癉ue to its reliability, SQLite is often used in mission-critical applications such as flight software“

試問(wèn)你所在的團(tuán)隊(duì)，能否保證測(cè)試程序LOC與開(kāi)發(fā)程序LOC是1:1的關(guān)系？產(chǎn)品發(fā)布時(shí)最后的否決權(quán)，是否在測(cè)試手里？

豬肉出廠還要蓋個(gè)質(zhì)檢章呢。如果客戶現(xiàn)場(chǎng)發(fā)現(xiàn)了一個(gè)bug, 你的團(tuán)隊(duì)的復(fù)盤時(shí)，是否能確認(rèn)這個(gè)bug應(yīng)該在軟件工程的那個(gè)環(huán)節(jié)被發(fā)現(xiàn)？

3、總結(jié)

一個(gè)系統(tǒng)的可靠性（其實(shí)是系統(tǒng)的各個(gè)方面了）是從三方面完成的：

3.1 系統(tǒng)的架構(gòu)設(shè)計(jì)

對(duì)于大部分軟件工程師這一點(diǎn)上不需要太重視， 為什么呢？因?yàn)橄駭?shù)據(jù)庫(kù)有歷史以來(lái)，它的基本架構(gòu)就那么幾種（single-node/monolithic, shared-storage/everything, shared-nothing)， 架構(gòu)帶來(lái)的優(yōu)勢(shì)和劣勢(shì)已經(jīng)被無(wú)數(shù)學(xué)術(shù)論文討論和工業(yè)系統(tǒng)驗(yàn)證過(guò)。我們99.9%是在前人肩膀上討生活，在高手腳邊打醬油。

3.2 系統(tǒng)的實(shí)現(xiàn)

也就是code的工程能力。同樣打個(gè)桌子，朱由校（明熹宗）很可以超越我周邊所有的朋友。同樣實(shí)現(xiàn)一個(gè)hash join, 其實(shí)現(xiàn)算法至少?gòu)淖钤绲膔elation model和關(guān)系幾何就有了。隨便找一篇三十年前的吧，An Adaptive Hash Join Algorithm for Multiuser Environments。

開(kāi)發(fā)實(shí)現(xiàn)的好壞要看工程能力和工匠精神了。如果有理論就能沖出亞洲，中國(guó)男足也不會(huì)這樣。這樣就是軟件開(kāi)發(fā)工程化的問(wèn)題。如何使團(tuán)隊(duì)更有效的開(kāi)發(fā)，要對(duì)功能有節(jié)制，明確產(chǎn)品的邊界，求精而不求全。

3.3 系統(tǒng)的驗(yàn)證

上邊專門提到，也是最容易被忽視的。大家常常會(huì)提到雙活（active-active)，兩地三中心， 跨城分布， 高可用，多少個(gè)九。這些高大上的詞我也常常用， 有時(shí)候認(rèn)真一點(diǎn)，我去請(qǐng)問(wèn)這些系統(tǒng)能力是如何驗(yàn)證通過(guò)的？高興的時(shí)候我會(huì)再多問(wèn)點(diǎn)直擊靈魂的，W H W（who 誰(shuí)測(cè)的，how 怎么測(cè)的，what 那些場(chǎng)景被測(cè)了？）。比如簡(jiǎn)單的雙活， 用什么樣的workload(W:R 比例？），多大數(shù)據(jù)量， 連續(xù)跑了多長(zhǎng)時(shí)間，P95延時(shí)是多少？

4、一點(diǎn)思考

當(dāng)一個(gè)軟件架構(gòu)師用呵護(hù)培養(yǎng)兒女的心寫code的時(shí)候，她/他就不會(huì)為三個(gè)月的短期目標(biāo)commit code，讓孩子長(zhǎng)歪了，比如"My"SQL和“Maria”DB。

做正確的事情是很難的，筆者在壓力下往repo里扔的爛code估計(jì)不比其他人少。"I always knew what the right path was. ....It was too damn hard." （聞香識(shí)女人）。做正確的事情太他媽難！】

5、注

傳奇老頭莫辛納甘：對(duì)應(yīng)火器庫(kù)，可以對(duì)應(yīng)古董級(jí)數(shù)據(jù)庫(kù)，可能就是 Mosin–Nagant 傳奇老頭莫辛納甘。

原始稿：本文原稿為2022.1，故部分內(nèi)容非最新信息

審核編輯 黃昊宇