來(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ū)W⒌疆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)容非最新信息
審核編輯 黃昊宇
-
數(shù)據(jù)庫(kù)
+關(guān)注
關(guān)注
7文章
3900瀏覽量
65728 -
MySQL
+關(guān)注
關(guān)注
1文章
849瀏覽量
27494
發(fā)布評(píng)論請(qǐng)先 登錄
半導(dǎo)體測(cè)試可靠性測(cè)試設(shè)備

提供半導(dǎo)體工藝可靠性測(cè)試-WLR晶圓可靠性測(cè)試
電機(jī)微機(jī)控制系統(tǒng)可靠性分析
做賊心虛:部分國(guó)產(chǎn)碳化硅MOSFET廠商“避談柵氧可靠性”的本質(zhì)

IGBT的應(yīng)用可靠性與失效分析

電路可靠性設(shè)計(jì)與工程計(jì)算技能概述

半導(dǎo)體集成電路的可靠性評(píng)價(jià)

一文讀懂芯片可靠性試驗(yàn)項(xiàng)目

霍爾元件的可靠性測(cè)試步驟
PCB高可靠性化要求與發(fā)展——PCB高可靠性的影響因素(上)

針對(duì)高可靠性應(yīng)用的電壓轉(zhuǎn)換

基于可靠性設(shè)計(jì)感知的EDA解決方案

燈具可靠性之關(guān)鍵:高低溫沖擊試驗(yàn)全面解析

汽車功能安全與可靠性的關(guān)系

評(píng)論