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

：40~50%在計算，50%~60%

STALLVLDB論文《DBMSs

On

A

Modern

Processor:Where

DoesTime

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

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

：40~50%在計算，50%~60%

STALL不斷進化的微架構(gòu)標量CPU超標量Uop

Cache/ROB/RS/LB/SB

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

Range

Scan為例，

B*Tree

的葉子節(jié)點是一個雙向鏈表，Range

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

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

CPU時間在

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

IT行業(yè)至今，將近30年了，CPU早已今非昔比，鏈表遍歷，還是那個鏈表遍歷。能充分發(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)也要改，原來里面只有一個next指針。現(xiàn)在要有多個。更改之后，性能至少提升1倍，STALL甚至可以減少至0。123456789123456789123456789123456789

……987654321987654321987654321987654321

……123456789123456789123456789123456789

……987654321987654321987654321987654321

……123456789123456789123456789123456789

……987654321987654321987654321987654321

……123456789123456789123456789123456789

……987654321987654321987654321987654321

……123456789123456789123456789123456789

……987654321987654321987654321987654321

……123456789123456789123456789123456789

……987654321987654321987654321987654321

……123456789123456789123456789123456789

……987654321987654321987654321987654321

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

……987654321987654321987654321987654321

……123456789123456789123456789123456789

……987654321987654321987654321987654321

……123456789123456789123456789123456789

……987654321987654321987654321987654321

……123456789123456789123456789123456789

……987654321987654321987654321987654321

……123456789123456789123456789123456789

……987654321987654321987654321987654321

……123456789123456789123456789123456789

……987654321987654321987654321987654321

……123456789123456789123456789123456789

……987654321987654321987654321987654321

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

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

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

1加鎖成功Sess

2檢查鎖值，非零，鎖已被其他進程持有Sess

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

cmpxchgq。執(zhí)行這條lock

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

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)（相當于自璇1萬次），共需18萬周期，平均一次執(zhí)行，18周期（6納秒）。假設獲取鎖失敗時，自璇10000次后，如仍無法得到鎖，即進入睡眠狀態(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)過計算：3*1024*1024*1024/(18.*10000)，17895，即1萬7千多次。即，一個CPU，1秒可以執(zhí)行1.7萬多次鎖的申請操作。如果有多個Core，這個數(shù)字還將翻倍。按照這個計算，數(shù)據(jù)庫其實即少會因為輕量級鎖的“自璇”，而導致CPU被耗盡的情況。因此，對數(shù)據(jù)庫經(jīng)驗有限的優(yōu)秀開發(fā)人員來說，自璇，的確是個好東西。但真的是這樣嗎？時間：大年初一上午10點到11點間現(xiàn)象：劇烈的輕量級鎖（Latch、Mutex）競爭，耗光CPU，大量警報，以短信形式發(fā)往甲方DBA手機。雖然最終，數(shù)據(jù)庫、主機，抗過這一波競爭高峰，沒有宕庫宕機。但由于時間點湊巧，情況原因未明，擔心進一步嚴重，最終還是上報主任和更高一級領導，做好隨時宕庫、切換的準備工作。原因調(diào)查：由于春節(jié)時期，數(shù)據(jù)庫壓力降低，Oracle的AI智能系統(tǒng)感知到這一變化，通知空間管理進程（SMCO）進行文件和內(nèi)存空間的清理。SMCO隨后按指示，在10點10分57秒，釋放了Shared

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

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

0持有Lock當Core

0釋放鎖時，修改鎖變量為0Core

0Core

1Core

2Core

3Core

4Core

5Core

6Core

7Core

8Core

9Core10Core11Core12Core13Core14Core151從CPU角度觀察Core

0持有Lock當Core

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

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

0Core

1Core

2Core

3Core

4Core

5Core

6Core

7Core

8Core

9Core10Core11Core12Core13Core14Core1510從CPU角度觀察Core

0持有Lock當Core

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

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

0Core

1Core

2Core

3Core

4Core

5Core

6Core

7Core

8Core

9Core10Core11Core12Core13Core14Core1510從CPU角度觀察Core

0持有Lock當Core

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

0要廣播一個Core

0Core

1Core

2Core

3Core

4Core

5Core

6Core

7Core

8Core

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

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

Core發(fā)送Write

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