2024數(shù)據(jù)庫內(nèi)核技術(shù)新領(lǐng)域探索123Contents目錄問題：最近這些年，最重要的數(shù)據(jù)庫技術(shù)有什么？重要的數(shù)據(jù)庫技術(shù)：分布式云原生矢量化計(jì)算存儲(chǔ)分離AI與自動(dòng)化HTAP……這個(gè)名單，還可以更長。這些技術(shù)，有一個(gè)共同特點(diǎn)。它們，已經(jīng)發(fā)展了好多年。都已經(jīng)十分成熟。重要的數(shù)據(jù)庫技術(shù)：分布式云原生矢量化計(jì)算存儲(chǔ)分離AI與自動(dòng)化HTAP……以分布式為例，PolarDB、OB、OpenGause、TDSQL、TiDB、……，還有誰不是分布式的嗎？重要的數(shù)據(jù)庫技術(shù)：分布式云原生矢量化計(jì)算存儲(chǔ)分離AI與自動(dòng)化HTAP……以分布式為例，PolarDB、OB、OpenGause、TDSQL、TiDB、……，還有誰不是分布式的嗎？我們的云原生技術(shù)，也已經(jīng)做到了全球領(lǐng)先。重要的數(shù)據(jù)庫技術(shù)：分布式云原生矢量化計(jì)算存儲(chǔ)分離AI與自動(dòng)化HTAP……以分布式為例，PolarDB、OB、OpenGause、TDSQL、TiDB、……，還有誰不是分布式的嗎？我們的云原生技術(shù)，也已經(jīng)做到了全球領(lǐng)先。矢量化，……正如本小節(jié)標(biāo)題，輕舟已過萬重山。無數(shù)數(shù)據(jù)庫難題，被我們解決了。但有一個(gè)研究，值得注意：VLDB論文《DBMSs

On

A

Modern

Processor:Where

Does

Time

Go?》烏云1VLDB論文《DBMSs

On

A

Modern

Processor:Where

Does

Time

Go?》，研究了A/B/C/D四種數(shù)據(jù)庫的三種操作下，CPU算力使用情況：順序范圍選擇：40%左右的CPU在計(jì)算，60%STALLJoin操作

：40~50%在計(jì)算，50%~60%

STALLVLDB論文《DBMSs

On

A

Modern

Processor:Where

DoesTime

Go?》，研究了A/B/C/D四種數(shù)據(jù)庫的三種操作下，

CPU算力使用情況：順序范圍選擇：40%左右的CPU在計(jì)算，60%STALLJoin操作

：40~50%在計(jì)算，50%~60%

STALL不斷進(jìn)化的微架構(gòu)標(biāo)量CPU超標(biāo)量Uop

Cache/ROB/RS/LB/SB

等流水線化緩存亂序編譯器滯后的后端優(yōu)化模式不斷發(fā)展的計(jì)算機(jī)體系結(jié)構(gòu)，和停滯不前的后端優(yōu)化間的矛盾。編譯器要兼顧通用性，但運(yùn)行數(shù)據(jù)庫的服務(wù)器，只有有限幾款CPU。編譯器強(qiáng)大的通用性，對數(shù)據(jù)庫而言意義甚微。但編譯器無法Cover復(fù)雜的體系結(jié)構(gòu)，導(dǎo)致無法發(fā)揮現(xiàn)代CPU的特性，這是問題的關(guān)鍵。有問題，就有方向。問題在哪兒，方向就在哪兒！方向MySQL由于其開源協(xié)議的限制，也使得PostgreSQL成為最佳的改造目標(biāo)。以STALL高達(dá)80%的Index

Range

Scan為例，

B*Tree

的葉子節(jié)點(diǎn)是一個(gè)雙向鏈表，Range

Scan要沿這個(gè)鏈表做部分Node的遍歷。鏈表的遍歷，太簡單了：for

（循環(huán)）{操作node_ptr->datanode_ptr=node_ptr->next}這樣的代碼，結(jié)果就是80%的ON

CPU時(shí)間在

STALL。我第一次學(xué)習(xí)這樣的鏈表遍歷是在1995年前后，就是在這本譚老師的教材中，學(xué)習(xí)的鏈表遍歷。1996年，我參加工作，進(jìn)入

IT行業(yè)至今，將近30年了，CPU早已今非昔比，鏈表遍歷，還是那個(gè)鏈表遍歷。能充分發(fā)揮現(xiàn)代CPU能效的方式是這樣的：for

（循環(huán)）{操作node_ptr1->data操作node_ptr2->data……node_ptr1

=

node_ptr->next1node_ptr2

=

node_ptr->next2……node_ptr

=

node_ptrN}數(shù)據(jù)結(jié)構(gòu)也要改，原來里面只有一個(gè)next指針。現(xiàn)在要有多個(gè)。更改之后，性能至少提升1倍，STALL甚至可以減少至0。123456789123456789123456789123456789

……987654321987654321987654321987654321

……123456789123456789123456789123456789

……987654321987654321987654321987654321

……123456789123456789123456789123456789

……987654321987654321987654321987654321

……123456789123456789123456789123456789

……987654321987654321987654321987654321

……123456789123456789123456789123456789

……987654321987654321987654321987654321

……123456789123456789123456789123456789

……987654321987654321987654321987654321

……123456789123456789123456789123456789

……987654321987654321987654321987654321

………………對于這樣的二維數(shù)組，假設(shè)要讀出所有的數(shù)據(jù)做運(yùn)算，怎樣才最快？先列后行，X軸方向讀每一個(gè)元素，Y軸加1，再X軸方向讀，……，不斷重復(fù)這個(gè)過程，這叫使用局部性。123456789123456789123456789123456789

……987654321987654321987654321987654321

……123456789123456789123456789123456789

……987654321987654321987654321987654321

……123456789123456789123456789123456789

……987654321987654321987654321987654321

……123456789123456789123456789123456789

……987654321987654321987654321987654321

……123456789123456789123456789123456789

……987654321987654321987654321987654321

……123456789123456789123456789123456789

……987654321987654321987654321987654321

……123456789123456789123456789123456789

……987654321987654321987654321987654321

………………對于這樣的二維數(shù)組，假設(shè)要讀出所有的數(shù)據(jù)做運(yùn)算，怎樣才最快？先列后行，X軸方向讀每一個(gè)元素，Y軸加1，再X軸方向讀，……，不斷重復(fù)這個(gè)過程，這叫使用局部性。在數(shù)組小于32KB的情況下，先行后列，才是最優(yōu)解。局部性在這里，和CPU的CACHE組件工作模式相沖突了。大于32KB，把數(shù)組分隔成32KB的小塊，先行后列。32KB內(nèi)，先行后列，可以壓滿CPU的內(nèi)存帶寬，先把數(shù)據(jù)以最短的時(shí)間，讀入L1Cache，再在L1

Cache中進(jìn)行計(jì)算。而且這和SIMD并不沖突，使用矢量指令，配合這樣的方式，可以取得最快的性能。擴(kuò)展問題：能效提升，提升的只是能效嗎？LWLockAcquire：PG輕量級(jí)鎖一次最簡單的Select，最少調(diào)用它10到20次一次最簡單的DML，最少調(diào)用它40次左右。在鎖無法得到時(shí)，要將自己加入等待隊(duì)列，此時(shí)，有可能進(jìn)入自璇。自璇的目的不自璇，無法得到鎖，就要被設(shè)為Sleep狀態(tài)，讓出

CPU。自璇可以霸占CPU，避免換出CPU后，Cache被其他進(jìn)程污染。0Sess1Sess21Sess

1加鎖成功Sess

2檢查鎖值，非零，鎖已被其他進(jìn)程持有Sess

2循環(huán)重復(fù)檢查鎖值，直到鎖值為0（或循環(huán)一定次數(shù)），稱為自璇。輕量級(jí)鎖，其主體構(gòu)成十分簡單，幾條匯編指令，最主要也最耗時(shí)的，是原子的CAS指令（compareandswap，比較并交換）。在x86-64平臺(tái)上，就是帶有l(wèi)ock前綴的cmpxchgq指令，即：lock

cmpxchgq。執(zhí)行這條lock

cmpxchgq指令，需要多少個(gè)周期呢？紙上得來終覺淺，絕知此事必躬行，我使用下面的嵌入?yún)R編進(jìn)行測試：

asm

volatile

("lea%0,%%r8\n\t"http://內(nèi)存塊開始地址"mov$8,%%rdx\n\t""mov%1,%%r12\n\t"http://循環(huán)次數(shù)"LOOP1:\n\t""lockcmpxchgq%%rdx,(%%r8)\n\t""sub$1,%%r12\n\t""jneLOOP1\n\t"::"m"(*arr),"r"(loop_number_1):"rdx","r8""r12");在我3GH

CPU，skylake微架構(gòu)下測試，執(zhí)行一萬次循環(huán)（相當(dāng)于自璇1萬次），共需18萬周期，平均一次執(zhí)行，18周期（6納秒）。假設(shè)獲取鎖失敗時(shí)，自璇10000次后，如仍無法得到鎖，即進(jìn)入睡眠狀態(tài)，讓??CPU。那么，1秒鐘，共可以執(zhí)行多少次鎖的申請操作？

asm

volatile

("lea%0,%%r8\n\t"http://內(nèi)存塊開始地址"mov$8,%%rdx\n\t""mov%1,%%r12\n\t"http://循環(huán)次數(shù)"LOOP1:\n\t""lockcmpxchgq%%rdx,(%%r8)\n\t""sub$1,%%r12\n\t""jneLOOP1\n\t"::"m"(*arr),"r"(loop_number_1):"rdx","r8""r12");經(jīng)過計(jì)算：3*1024*1024*1024/(18.*10000)，17895，即1萬7千多次。即，一個(gè)CPU，1秒可以執(zhí)行1.7萬多次鎖的申請操作。如果有多個(gè)Core，這個(gè)數(shù)字還將翻倍。按照這個(gè)計(jì)算，數(shù)據(jù)庫其實(shí)即少會(huì)因?yàn)檩p量級(jí)鎖的“自璇”，而導(dǎo)致CPU被耗盡的情況。因此，對數(shù)據(jù)庫經(jīng)驗(yàn)有限的優(yōu)秀開發(fā)人員來說，自璇，的確是個(gè)好東西。但真的是這樣嗎？時(shí)間：大年初一上午10點(diǎn)到11點(diǎn)間現(xiàn)象：劇烈的輕量級(jí)鎖（Latch、Mutex）競爭，耗光CPU，大量警報(bào)，以短信形式發(fā)往甲方DBA手機(jī)。雖然最終，數(shù)據(jù)庫、主機(jī)，抗過這一波競爭高峰，沒有宕庫宕機(jī)。但由于時(shí)間點(diǎn)湊巧，情況原因未明，擔(dān)心進(jìn)一步嚴(yán)重，最終還是上報(bào)主任和更高一級(jí)領(lǐng)導(dǎo)，做好隨時(shí)宕庫、切換的準(zhǔn)備工作。原因調(diào)查：由于春節(jié)時(shí)期，數(shù)據(jù)庫壓力降低，Oracle的AI智能系統(tǒng)感知到這一變化，通知空間管理進(jìn)程（SMCO）進(jìn)行文件和內(nèi)存空間的清理。SMCO隨后按指示，在10點(diǎn)10分57秒，釋放了Shared

Buffer池中的部分冷對象。原因調(diào)查：約在10點(diǎn)25分前后，圖中SQL開始執(zhí)行，它包含一個(gè)Sequecn對象（序列），但此序列對象已經(jīng)被SMCO進(jìn)程清理??共享池。重新加載它到共享池，需要一系列的輕量級(jí)鎖（Latch、Mutex）。正好，這條SQL在那個(gè)時(shí)刻并發(fā)突然升高，多個(gè)進(jìn)程同時(shí)執(zhí)行同一SQL，又同時(shí)加載同一Sequence對象，同時(shí)申請同一批輕量級(jí)鎖，競爭難以避免的??現(xiàn)了。Latch/Mutex鎖的自璇，很快耗盡了CPU，海量的警報(bào)，發(fā)向DBA的手機(jī)，……前面PPT中做過計(jì)算，按每次鎖1萬次自璇計(jì)算，一個(gè)Core，一秒可以完成1.7萬次鎖申請。此數(shù)據(jù)庫，當(dāng)時(shí)的SQL并發(fā)執(zhí)行次數(shù)有多少？在問題時(shí)段，每秒中SQL執(zhí)行次數(shù)只有53次，而且，還不只一條SQL。為什么1秒中只執(zhí)行了53次SQL，卻因?yàn)樽澡i，導(dǎo)致CPU被耗盡呢？LWLockAcquire：PG輕量級(jí)鎖下面將視角切換到CPU。0Sess1Sess21Sess

2循環(huán)重復(fù)檢查鎖值，直到鎖值為0（或循環(huán)一定次數(shù)），稱為自璇。Sess3Sess4Sessn……從CPU角度觀察Core

0持有Lock當(dāng)Core

0釋放鎖時(shí)，修改鎖變量為0Core

0Core

1Core

2Core

3Core

4Core

5Core

6Core

7Core

8Core

9Core10Core11Core12Core13Core14Core151從CPU角度觀察Core

0持有Lock當(dāng)Core

0釋放鎖時(shí)，修改鎖變量為0但是另外15個(gè)Core不斷在讀此變量的值，Core

0要廣播一個(gè)Invalite消息給另外15個(gè)Core。之后，才能修改鎖變量為0Core

0Core

1Core

2Core

3Core

4Core

5Core

6Core

7Core

8Core

9Core10Core11Core12Core13Core14Core1510從CPU角度觀察Core

0持有Lock當(dāng)Core

0釋放鎖時(shí)，修改鎖變量為0但是另外15個(gè)Core不斷在讀此變量的值，Core

0要廣播一個(gè)Invalite消息給另外15個(gè)Core。之后，才能修改鎖變量為0另外15個(gè)核會(huì)搶著向Core0發(fā)一個(gè)WriteUpdate消息（即，把當(dāng)前值給我，我要修改它）Core

0Core

1Core

2Core

3Core

4Core

5Core

6Core

7Core

8Core

9Core10Core11Core12Core13Core14Core1510從CPU角度觀察Core

0持有Lock當(dāng)Core

0釋放鎖時(shí)，修改鎖變量為0但是另外15個(gè)Core不斷在讀此變量的值，Core

0要廣播一個(gè)Core

0Core

1Core

2Core

3Core

4Core

5Core

6Core

7Core

8Core

9Core10Core11Core12Core13Core14Core15101Inva一lit輪e消輪息消給息另外同1步5個(gè)，Co能re將。之i9后直，接才變能回修改鎖變量為0386。使熱點(diǎn)競爭造成的阻塞進(jìn)一另外步15加個(gè)劇核會(huì)。搶著向Core0發(fā)一個(gè)WriteUpdate消息（即，把當(dāng)前值給我，我要修改它）經(jīng)過CPU內(nèi)部的仲裁，Core

9搶到鎖變量的所有權(quán)，它要向其他

Core發(fā)送Write

Invalidate消息。然后修改鎖變量為1。大年初一驚