成人做爰黄AA片啪啪声,三级av小说,福利色导航,四虎偷拍在线综合,亚洲a,韩国三级片中文字幕,日本爽爽爽爽爽爽在线观看免,黄片国产

本篇文章解讀兩篇關(guān)于 OLTP 數(shù)據(jù)庫(kù)引擎性能優(yōu)化的論文，分別是發(fā)表于VLDB-2021的《CoroBase: coroutine-oriented main-memory database engine》和發(fā)表于VLDB-2024的《The Art of Latency Hiding in Modern Database Engines》。在此基礎(chǔ)上探討論文的系統(tǒng)設(shè)計(jì)與 TDSQL 計(jì)算引擎設(shè)計(jì)的異同，以及論文帶來(lái)的啟發(fā)。

● 論文一的研究對(duì)象是純內(nèi)存計(jì)算的 OLTP 引擎，作者通過(guò)引入 C++ 20 的 coroutine 特性將 thread-to-transaction 的執(zhí)行模型修改為兩級(jí) coroutine-to-transaction，在不需要內(nèi)部接口改動(dòng)的條件下實(shí)現(xiàn)了事務(wù)間的 batch 機(jī)制和基于協(xié)程的 prefetch，減少了后續(xù)計(jì)算的 cache miss，提升了事務(wù)的整體執(zhí)行性能。

● 論文二在論文一的基礎(chǔ)上，研究對(duì)象從純內(nèi)存計(jì)算的 OLTP 引擎擴(kuò)展為更通用的內(nèi)存計(jì)算和存儲(chǔ) IO 訪問(wèn)混合的 OLTP 引擎，更完整的討論了數(shù)據(jù)庫(kù)引擎可能在哪些環(huán)節(jié)產(chǎn)生性能問(wèn)題（重點(diǎn)關(guān)注端到端的吞吐和延遲）：包括 CPU 的 cache miss、存儲(chǔ) IO、操作系統(tǒng)調(diào)度、數(shù)據(jù)同步等等。論文沿用 coroutine-to-transaction 的執(zhí)行模型，通過(guò)控制線程數(shù)量、靈活的 coroutine 策略（可選擇性的協(xié)程嵌套、存儲(chǔ)感知的調(diào)度策略、流水線式的調(diào)度）在不同的場(chǎng)景實(shí)現(xiàn) latency hiding ，以達(dá)到系統(tǒng)整體吞吐的提升。

純內(nèi)存計(jì)算場(chǎng)景

OLTP引擎

論文一所討論的問(wèn)題非常明確，即在一個(gè)純內(nèi)存計(jì)算的 OLTP 場(chǎng)景下，需要提高事務(wù)間的并發(fā)能力，減少訪存的 cache miss。論文首先抽象了三種數(shù)據(jù)訪問(wèn)模型，分別是線性模型、Multi-Get 和論文的 coroutine 模型，三種模型如下圖所示。圖示中 T1 和 T2 代表兩個(gè)事務(wù)（各自運(yùn)行在獨(dú)立協(xié)程），虛線方塊代表等待數(shù)據(jù)從內(nèi)存加載到 cpu cache，實(shí)線方塊代表在 CPU 內(nèi)計(jì)算。顯而易見(jiàn)，線性模型事務(wù)間無(wú)法并發(fā)計(jì)算，CPU 利用率最低；Multi-Get 模型需要調(diào)整數(shù)據(jù)獲取接口，通過(guò) batch 的方式可以實(shí)現(xiàn)一定程度的事務(wù)間并發(fā)；coroutine 模型則是通過(guò) prefetch 和 suspend/resume 的機(jī)制，當(dāng)協(xié)程 T1 要通過(guò)指針訪問(wèn)數(shù)據(jù)時(shí)，它可以向 CPU 發(fā)起 prefetch 指令讓 CPU 把這塊數(shù)據(jù)從內(nèi)存加載到 cache 中，因?yàn)榧虞d數(shù)據(jù)需要時(shí)間，在這個(gè)協(xié)程發(fā)完 prefetch 指令后將當(dāng)前協(xié)程掛起，不再占用 CPU，讓 CPU 繼續(xù)執(zhí)行其他數(shù)據(jù)已經(jīng)在 cache 中的協(xié)程的計(jì)算任務(wù)，這樣數(shù)據(jù)加載和計(jì)算完全并行起來(lái)，cache miss 減少，達(dá)到整體執(zhí)行性能的提升。

在這篇論文之前，已經(jīng)有不少利用協(xié)程的 software prefetch 機(jī)制，提升CPU利用率和事務(wù)的執(zhí)行性能的研究，包括論文《Improving Hash Join Performance through Prefetching》提出的group prefetching和pipelined prefetching，論文《Asynchronous Memory Access Chaining》提出的AMAC。已有的研究成果存在兩個(gè)問(wèn)題：一是沒(méi)有研究 prefetch 機(jī)制對(duì)整個(gè)數(shù)據(jù)庫(kù)引擎端到端的性能影響；二是需要對(duì)數(shù)據(jù)存取接口進(jìn)行修改，會(huì)引入編碼復(fù)雜度和兼容性問(wèn)題。這篇論文則是通過(guò)引入 C++ 20 的 coroutine 機(jī)制，解決了這兩個(gè)問(wèn)題。針對(duì)問(wèn)題二，論文提出了兩級(jí)協(xié)程模型（two-level coroutine-to-transaction），其本質(zhì)是平衡了在事務(wù)執(zhí)行引擎內(nèi)各模塊復(fù)雜函數(shù)調(diào)用的嵌套和修改執(zhí)行引擎、拍平調(diào)用嵌套所引入的編碼復(fù)雜度和減少協(xié)程切換提升性能。簡(jiǎn)而言之，因?yàn)樾枰诩虞d數(shù)據(jù)的代碼處引入 CPU 的 prefetch 和協(xié)程的 suspend，數(shù)據(jù)庫(kù)執(zhí)行引擎內(nèi)可能有復(fù)雜的模塊抽象和調(diào)用依賴，形成復(fù)雜的協(xié)程嵌套。如果把這種嵌套完全拍扁為線性的 prefetch 和 suspend，會(huì)讓問(wèn)題二從 multi-get 接口的改寫(xiě)問(wèn)題轉(zhuǎn)變成函數(shù)調(diào)用層級(jí)拍平問(wèn)題，并沒(méi)有解決編碼層面的復(fù)雜度。為了解決此問(wèn)題，論文提出的兩級(jí)協(xié)程模型，第一級(jí)協(xié)程作為事務(wù)執(zhí)行的調(diào)度函數(shù)，在協(xié)程內(nèi)管理事務(wù)處理的所有過(guò)程，調(diào)用其他函數(shù)或協(xié)程完成事務(wù)的最終執(zhí)行。第二級(jí)協(xié)程用來(lái)優(yōu)化某個(gè)步驟中所有可能發(fā)生 cache miss 的地方，所有需要改成 coroutine 的函數(shù)都通過(guò) inline 的方式將協(xié)程調(diào)用轉(zhuǎn)換為函數(shù)調(diào)用，在同一個(gè) coroutine 中執(zhí)行。這里需要注意，論文的設(shè)計(jì)并不意味著不需要代碼的改動(dòng)，適當(dāng)?shù)?flatten 是必須的，其優(yōu)點(diǎn)是保留了執(zhí)行引擎內(nèi)的函數(shù)模塊化。

對(duì)于端到端的性能影響，則體現(xiàn)在論文一的測(cè)試場(chǎng)景，論文里覆蓋了比較常見(jiàn)的數(shù)據(jù)庫(kù)性能測(cè)試場(chǎng)景，包括 YCSB、TPC-C、TPC-CR 和 TPC-CH，關(guān)注的性能指標(biāo)是在不同控制變量情況下系統(tǒng)端到端的吞吐和請(qǐng)求延遲。

內(nèi)存計(jì)算和存儲(chǔ)IO

混合場(chǎng)景

在現(xiàn)代數(shù)據(jù)庫(kù)的使用場(chǎng)景下，適用于純內(nèi)存計(jì)算的數(shù)據(jù)規(guī)模非常具有局限性，很多時(shí)候數(shù)據(jù)庫(kù)引擎需要同時(shí)處理可以常駐內(nèi)存的數(shù)據(jù)和常駐在存儲(chǔ)介質(zhì)的數(shù)據(jù)。論文二在論文一的基礎(chǔ)上，進(jìn)一步討論了內(nèi)存計(jì)算和存儲(chǔ) IO 混合使用的場(chǎng)景。該篇論文將延遲優(yōu)化分為了幾個(gè)細(xì)分的方向，包括內(nèi)存訪問(wèn)和存儲(chǔ)IO 延遲；操作系統(tǒng)過(guò)載和調(diào)度延遲；以及同步機(jī)制引入的延遲。每一種延遲場(chǎng)景論文給出了如下的解釋?zhuān)?/span>

● 指針數(shù)據(jù)訪問(wèn)：一個(gè)具體的例子是 B+ 樹(shù)使用指針訪問(wèn)數(shù)據(jù)，從根節(jié)點(diǎn)到葉子結(jié)點(diǎn)的訪問(wèn)是一種隨機(jī)內(nèi)存訪問(wèn)，并不利于硬件的預(yù)取和分支預(yù)測(cè)；另一個(gè)例子是多版本數(shù)據(jù)鏈表的隨機(jī)訪問(wèn)，也是緩存不友好的。

● 同步機(jī)制：論文中指對(duì)同一個(gè)內(nèi)存地址訪問(wèn)的并發(fā)保護(hù)機(jī)制，比如使用 spinlock 或者 mutex 等。鎖競(jìng)爭(zhēng)可能會(huì)引入過(guò)多的 CPU 消耗。

● 存儲(chǔ) IO：顯而易見(jiàn)訪問(wèn)存儲(chǔ)的數(shù)據(jù)延遲遠(yuǎn)大于訪問(wèn)內(nèi)存數(shù)據(jù)。另一方面，盡管有一些系統(tǒng)引入專(zhuān)用 IO 線程，比如在 MySQL 內(nèi)有異步 IO，對(duì)于存儲(chǔ)數(shù)據(jù)的預(yù)取仍然是難以判斷的；同時(shí)專(zhuān)用 IO 引入了線程間通信，這部分通信有可能引入過(guò)度的資源消耗并產(chǎn)生新的延遲。

● 資源過(guò)載和操作系統(tǒng)調(diào)用：當(dāng)創(chuàng)建的操作系統(tǒng)線程過(guò)多時(shí)，操作系統(tǒng)線程切換的 CPU 消耗可能會(huì)引入性能問(wèn)題。另一方面一些后臺(tái)專(zhuān)用線程也會(huì)和事務(wù)工作線程爭(zhēng)用 CPU。

● 其他：論文里提到一些其他的產(chǎn)生延遲的原因，比如邏輯時(shí)鐘競(jìng)爭(zhēng)，分布式系統(tǒng)下的網(wǎng)絡(luò)延遲等等。

在給出多種延遲來(lái)源后，論文二限定了所解決問(wèn)題的場(chǎng)景為單節(jié)點(diǎn)，適配雙路或四路 CPU 架構(gòu)進(jìn)行過(guò)內(nèi)存優(yōu)化的數(shù)據(jù)庫(kù)服務(wù)。分布式架構(gòu)的數(shù)據(jù)庫(kù)和更大規(guī)模 CPU 插槽和核數(shù)的場(chǎng)景不在這篇論文的討論范疇內(nèi)。論文二在論文一實(shí)驗(yàn)項(xiàng)目 Corobase 的基礎(chǔ)上，進(jìn)一步實(shí)現(xiàn)了項(xiàng)目 MosaicDB。MosaicDB 確保系統(tǒng)內(nèi)線程和操作系統(tǒng)核心數(shù)嚴(yán)格相等，每個(gè)線程對(duì)應(yīng)于一個(gè) worker，在工作線程內(nèi)使用 coroutine-to-transaction 模式處理事務(wù)。整個(gè)系統(tǒng)的工作架構(gòu)如下圖所示：

具體解釋一下工作線程內(nèi)的處理流程：

step-1：工作線程每次接收一批事務(wù)請(qǐng)求。

step-2：對(duì)每個(gè)事務(wù)創(chuàng)建相應(yīng)的協(xié)程處理，根據(jù)數(shù)據(jù)訪問(wèn)的不同情況進(jìn)行選擇：如果需要訪問(wèn)存儲(chǔ)數(shù)據(jù)，suspend 當(dāng)前協(xié)程，跳轉(zhuǎn)到步驟3；如果是訪問(wèn)內(nèi)存中數(shù)據(jù)，使用 prefetch 指令后 suspend 等待數(shù)據(jù)加載到 cpu cache。而具體的數(shù)據(jù)訪問(wèn)是通過(guò)指針->索引->查詢數(shù)組（多版本鏈）的訪問(wèn)模式。

step-3：通過(guò)異步 IO 獲取數(shù)據(jù)。

step-4 & step-5：協(xié)程 suspend 后交還 CPU 給調(diào)度器。

step-6：調(diào)度器創(chuàng)建協(xié)程處理其他事務(wù)，或者恢復(fù)某一個(gè)已經(jīng) suspend 的事務(wù)。

在以上系統(tǒng)架構(gòu)的基礎(chǔ)上，論文二提出了如下的優(yōu)化點(diǎn)：

1. Coroutine 嵌套的優(yōu)化：保留論文一內(nèi)存熱數(shù)據(jù)訪問(wèn)的二級(jí) coroutine-to-transaction 模式，對(duì)涉及存儲(chǔ)訪問(wèn)的函數(shù)保留嵌套協(xié)程。論文給出選擇該種策略的兩點(diǎn)理由：1）如果對(duì)存儲(chǔ)訪問(wèn)函數(shù)也解嵌套，會(huì)引入復(fù)雜代碼，也不利于代碼指令緩存（這個(gè)理由我覺(jué)得不夠充分，論文并沒(méi)有解釋的清楚為什么拍平內(nèi)存訪問(wèn)函數(shù)沒(méi)有這個(gè)問(wèn)題）；2）相比于內(nèi)存延遲，存儲(chǔ)訪問(wèn)延遲的數(shù)量級(jí)更高，在進(jìn)行 IO 請(qǐng)求時(shí)需要盡可能減少協(xié)程切換到 IO 等待協(xié)程的頻率（我覺(jué)得這一點(diǎn)是更主要的原因，也更合理）。

2. 存儲(chǔ)感知的調(diào)度策略：該策略是策略1的延續(xù)，因?yàn)樾枰獧z查異步 IO 是否結(jié)束以接收數(shù)據(jù)在 CPU 計(jì)算處理，如果頻繁的協(xié)程切換檢查，檢查時(shí)異步 IO 又沒(méi)有結(jié)束返回，會(huì)造成 CPU 的浪費(fèi)。所以論文解耦了 IO 狀態(tài)檢查和事務(wù)執(zhí)行的邏輯，為每一個(gè)等待異步 IO 結(jié)束的事務(wù)申請(qǐng)一個(gè)可追蹤的對(duì)象，這些對(duì)象放在一起統(tǒng)一做 IO 狀態(tài)的檢查。這樣就可以保證只在協(xié)程內(nèi)異步 IO 結(jié)束才會(huì)切換回該協(xié)程。

3. 流水線調(diào)度策略：該策略在策略2上擴(kuò)展，因?yàn)椴呗?按批次處理一組事務(wù)，不同事務(wù)處理時(shí)間不一定相同，當(dāng)快的事務(wù)處理結(jié)束后，慢事務(wù)可能還在等待 IO 結(jié)束，會(huì)出現(xiàn) CPU 空轉(zhuǎn)情況。于是論文中引入了多隊(duì)列的策略，分別是內(nèi)存密集型隊(duì)列和存儲(chǔ)密集型隊(duì)列，兩個(gè)隊(duì)列內(nèi)的事務(wù)可以根據(jù)情況進(jìn)行轉(zhuǎn)換，轉(zhuǎn)換有一個(gè)緩沖區(qū)，用于控制兩個(gè)隊(duì)列的大小，保證不出現(xiàn)饑餓或者隊(duì)列滿的情況。

4. 工作線程內(nèi)的事務(wù)日志和提交：論文認(rèn)為許多數(shù)據(jù)庫(kù)系統(tǒng)中后臺(tái)獨(dú)立的事務(wù)日志線程和異步提交線程會(huì)引入數(shù)據(jù)同步的延遲，為了解決該問(wèn)題 MosaicDB 選擇將事務(wù)日志和異步提交全部集成在工作線程，所以每一個(gè)工作線程能獨(dú)立處理事務(wù)的所有邏輯。

TDSQL計(jì)算引擎對(duì)比

和論文啟發(fā)

兩篇論文讀下來(lái)有不少啟發(fā)，雖然 MosaicDB 的架構(gòu)和目前的 TDSQL 計(jì)算引擎有不少區(qū)別，但是也有一些相似之處，這里簡(jiǎn)單做一些對(duì)比，看看有哪些可以借鑒之處。首先對(duì) TDSQL 計(jì)算引擎做一下背景介紹。

1、TDSQL 計(jì)算引擎介紹

分布式TDSQL MySQL是一種支持存算分離、自動(dòng)水平拆分、Shared Nothing 架構(gòu)的分布式數(shù)據(jù)庫(kù)。整體架構(gòu)分為數(shù)據(jù)節(jié)點(diǎn)和計(jì)算節(jié)點(diǎn)，數(shù)據(jù)節(jié)點(diǎn)由騰訊自研的 TXSQL 負(fù)責(zé)底層數(shù)據(jù)管理相關(guān)功能；計(jì)算節(jié)點(diǎn)在協(xié)議層和功能方面兼容 MySQL 8.0，計(jì)算節(jié)點(diǎn)支持多讀多寫(xiě)、無(wú)狀態(tài)水平擴(kuò)展，在查詢下推優(yōu)化、并行查詢、分布式事務(wù)管理、元數(shù)據(jù)管理等模塊進(jìn)行了大量深度優(yōu)化來(lái)保證讀寫(xiě)性能。

2、有棧協(xié)程和無(wú)棧協(xié)程

新一代 TDSQL 計(jì)算引擎通過(guò)引入 bthread，將原有計(jì)算引擎的線程模型升級(jí)為協(xié)程模型，但 bthread 本質(zhì)是一個(gè)有棧協(xié)程池，它是一個(gè) M:N 的協(xié)程模型，這意味著協(xié)程可以在線程間遷移。論文二特別強(qiáng)調(diào)使用協(xié)程提升性能的關(guān)鍵因素在于協(xié)程切換的開(kāi)銷(xiāo)必須小于 CPU L3 cache miss。相對(duì)而言，C++ 20 coroutine 的無(wú)棧協(xié)程將上下文保存在堆內(nèi)存的 coroutine frame 中，切換開(kāi)銷(xiāo)非常小。所以在 TDSQL 計(jì)算引擎中是否可以通過(guò)引入 prefetching 的技術(shù)提升性能，需要更深入的研究和測(cè)試。另外一點(diǎn)，在工業(yè)界代碼中已經(jīng)有利用 C++ 20 coroutine 和 prefetch 提升執(zhí)行引擎性能的案例，比如 StarRocks 的 pr：《[Feature] improve hash join performance by coroutine-based interleaving》。有趣的是，他們的測(cè)試結(jié)果顯示并不是所有的場(chǎng)景適合使用 coroutine interleaving，如果強(qiáng)制打開(kāi) coroutine interleaving，TPCH/TPCDS 的測(cè)試 SQL 性能反而下降，StarRocks 給出的分析結(jié)果是這些 SQL 中的 join hash table 不夠大，另外有些相同 key 的數(shù)據(jù)聚集在一起，沒(méi)有出現(xiàn)太多 cache miss，協(xié)程切換帶來(lái)的開(kāi)銷(xiāo)反而大于從 interleaving 獲得的收益。

3、后臺(tái)線程的影響

TDSQL 作為一個(gè)分布式數(shù)據(jù)庫(kù)，不可避免使用了很多獨(dú)立的后臺(tái)線程，比如 DDL 異步水位更新、后臺(tái)元數(shù)據(jù)變更訂閱、同步 system variable 的定時(shí)器、分布式死鎖檢測(cè)等等，這點(diǎn)和 MosaicDB 還是有很大區(qū)別的。TDSQL 的后臺(tái)工作線程對(duì)系統(tǒng)的性能有哪些影響，是否會(huì)引起系統(tǒng)性能的抖動(dòng)等問(wèn)題，有待后續(xù)更深入的研究。

Buffer pool 和 hot-cold 架構(gòu)

Buffer pool 是 TXSQL中使用的存儲(chǔ)訪存和內(nèi)存管理策略，需要讀取或?qū)懭氲臄?shù)據(jù)，都會(huì)經(jīng)過(guò) buffer pool 的頁(yè)；而 hot-cold 架構(gòu)則是另一種完全不同的數(shù)據(jù)庫(kù)管理策略，它將熱數(shù)據(jù)和冷數(shù)據(jù)分別存儲(chǔ)在不同存儲(chǔ)介質(zhì)中，熱數(shù)據(jù)直接通過(guò)主內(nèi)存讀寫(xiě)，而冷數(shù)據(jù)的讀寫(xiě)則是直接訪問(wèn)第二級(jí)存儲(chǔ)介質(zhì)，比如磁盤(pán)。事實(shí)上在 TDSQL 的架構(gòu)中，可以看作 buffer pool 和 hot-cold 共存，在存儲(chǔ)層面，底層的 TXSQL 使用的是 buffer pool 策略；在計(jì)算層面，TDSQL計(jì)算引擎使用的Parallel Query或者Remote Handler通過(guò)網(wǎng)絡(luò)訪問(wèn)TXSQL層數(shù)據(jù)，可以看作 hot-cold 架構(gòu)的 secondary storage。這個(gè)點(diǎn)也很有趣，后續(xù)有更多時(shí)間，會(huì)對(duì)比 TDSQL/TXSQL 里的 IO 訪問(wèn)策略與 MosaicDB 有哪些異同。

論文缺少了哪些討論

1、延遲的穩(wěn)定性和可預(yù)測(cè)性

正如論文《 A Top-Down Approach to Achieving Performance Predictability in Database Systems》所說(shuō)，很多關(guān)于數(shù)據(jù)庫(kù)的性能測(cè)試只關(guān)注吞吐和平均延遲，而忽略了延遲的穩(wěn)定性和可預(yù)測(cè)性。類(lèi)似的 TPCC 的測(cè)試標(biāo)準(zhǔn)要求了 8小時(shí)壓力測(cè)試內(nèi) tpmc 的波動(dòng)率不能大于 2%，DynamoDB 在 USENIX-2022 的論文《Amazon DynamoDB: A Scalable, Predictably Performant, and Fully Managed NoSQL Database Service | USENIX 》重點(diǎn)強(qiáng)調(diào)了系統(tǒng)在不同數(shù)據(jù)規(guī)模下可以保證延遲的可預(yù)測(cè)性。延遲穩(wěn)定性和可預(yù)測(cè)性對(duì)于延遲敏感型應(yīng)用或者存在關(guān)鍵數(shù)據(jù)請(qǐng)求路徑的應(yīng)用非常重要。論文二使用的工作線程獨(dú)立、CPU 核數(shù)和工作線程 1:1 綁定，多隊(duì)列調(diào)度等策略，從理論上說(shuō)都有利于保證事務(wù)處理延遲穩(wěn)定性，但是論文里并沒(méi)有對(duì)這一點(diǎn)進(jìn)行描述或測(cè)試，算是一個(gè)小遺憾。

2、吞吐和延遲的相互影響

在 ICDE-2018 的論文《Benchmarking Distributed Stream Data Processing Systems》中提出了數(shù)據(jù)處理系統(tǒng)中 sustainable performance 的概念，所謂的 unsustainable，是指一個(gè)數(shù)據(jù)處理系統(tǒng)，當(dāng)請(qǐng)求量超過(guò)其處理能力上限時(shí)，會(huì)觸發(fā)系統(tǒng)內(nèi)部的反壓機(jī)制，導(dǎo)致整體的性能下降或者不再能提供更高的處理能力。觸發(fā)系統(tǒng)內(nèi)部反壓機(jī)制是 sustainable 和 unsustainable 臨界狀態(tài)的一個(gè)標(biāo)志，通常進(jìn)入 unsustainable 狀態(tài)后系統(tǒng)的平均處理延遲會(huì)急劇上升，如下圖所示。MosaicDB 的一些特性，比如工作線程和操作系統(tǒng) CPU 核心數(shù) 1:1 綁定、多隊(duì)列調(diào)度策略，理論上有助于應(yīng)對(duì)系統(tǒng)進(jìn)入 unsustainable 狀態(tài)后維持性能，譬如通過(guò)請(qǐng)求排隊(duì)，對(duì)可服務(wù)范圍的請(qǐng)求提供足夠的計(jì)算資源并保證處理延遲；而使一個(gè) OLTP 數(shù)據(jù)庫(kù)引擎進(jìn)入 unsustainable 狀態(tài)的最直接方法就是不斷增加客戶端數(shù)量和客戶端的并發(fā)請(qǐng)求，在這種場(chǎng)景下度量數(shù)據(jù)庫(kù)引擎端到端的吞吐和延遲，也是系統(tǒng)性能特征的一部分。這些在論文中也并沒(méi)有涉及。

總結(jié)

兩篇論文強(qiáng)調(diào)是現(xiàn)代 OLTP 引擎端到端的整體性能優(yōu)化，論文在使用場(chǎng)景、測(cè)試方法和性能要求方面能夠反映出現(xiàn)代、端到端數(shù)據(jù)庫(kù)的真實(shí)需求。其具體優(yōu)化策略和系統(tǒng)設(shè)計(jì)也很值得借鑒，在實(shí)驗(yàn)驗(yàn)證的環(huán)節(jié)也有綜合考慮到影響數(shù)據(jù)庫(kù)數(shù)據(jù)庫(kù)引擎性能的多維度因素。

兩篇論文出自同一個(gè)實(shí)驗(yàn)室的研究，論文二還有我司同事的共同合作，很期待這個(gè)實(shí)驗(yàn)室能在已有研究基礎(chǔ)上進(jìn)一步探索，譬如將他們的系統(tǒng)擴(kuò)展為分布式數(shù)據(jù)庫(kù)場(chǎng)景，一定會(huì)有更大的挑戰(zhàn)。如果后邊有時(shí)間，我們也會(huì)深入地探索 MosaicDB 中的優(yōu)化方向能否應(yīng)用于 TDSQL 計(jì)算引擎之中。

﹀

-- 更多精彩 --

搶鮮體驗(yàn)！騰訊云PostgreSQL國(guó)內(nèi)首支持PG 16

↓↓點(diǎn)擊閱讀原文，了解更多優(yōu)惠

【論文解讀】OLTP 數(shù)據(jù)庫(kù)引擎性能優(yōu)化

1、TDSQL 計(jì)算引擎介紹

2、有棧協(xié)程和無(wú)棧協(xié)程