數(shù)據(jù)庫運(yùn)行很慢的原因分析

本篇內(nèi)容介紹了“數(shù)據(jù)庫運(yùn)行很慢的原因分析”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

當(dāng)你發(fā)現(xiàn)數(shù)據(jù)庫查詢特別慢的時(shí)候，并且從硬件配置、SQL優(yōu)化和索引等方面都找不出原因，那你可能需要從數(shù)據(jù)庫的計(jì)算引擎本身的性能找下原因。

數(shù)據(jù)庫的計(jì)算引擎性能有多重要？我們可以拿汽車做個(gè)簡單類比。服務(wù)器硬件配置是基礎(chǔ)設(shè)施，相當(dāng)于汽車行駛的道路，高速公路和山村土路的行駛效果肯定是不一樣的；SQL的查詢優(yōu)化相當(dāng)于駕駛水平；而數(shù)據(jù)庫計(jì)算引擎就相當(dāng)于汽車發(fā)動(dòng)機(jī)，既是數(shù)據(jù)庫性能的源動(dòng)力，也是各家廠商最核心的技術(shù)壁壘。

那么，我們就從數(shù)據(jù)庫計(jì)算引擎的實(shí)現(xiàn)技術(shù)探究下如何提高數(shù)據(jù)庫性能。下圖是從客戶端發(fā)出一條SQL語句到結(jié)果返回給客戶端的簡化流程。

如果把數(shù)據(jù)庫內(nèi)核看成一個(gè)組織，那么優(yōu)化器就位于組織的最上層，作為組織的首腦發(fā)號(hào)施令；執(zhí)行器位于組織的中間，嚴(yán)格執(zhí)行優(yōu)化器下發(fā)的計(jì)劃，從存儲(chǔ)空間中讀取數(shù)據(jù)進(jìn)行加工處理，最終返回給客戶端。

優(yōu)化器

如何形象的理解優(yōu)化器？以查詢“知乎點(diǎn)贊過萬的回答”為例，用戶通過SQL告訴數(shù)據(jù)庫“給我找出點(diǎn)贊過萬的回答”，優(yōu)化器把用戶的需求轉(zhuǎn)換為“如何找到點(diǎn)贊過萬的回答”的策略和方法，即查詢計(jì)劃。

同一種SQL會(huì)有成千上萬種不同的執(zhí)行計(jì)劃，而好的執(zhí)行計(jì)劃和差的執(zhí)行計(jì)劃在運(yùn)行性能上會(huì)有天壤之別。

如何從成千上萬種查詢計(jì)劃中選出最優(yōu)的？早期數(shù)據(jù)庫的查詢優(yōu)化器通常采用啟發(fā)式規(guī)則進(jìn)行優(yōu)化RBP（Rule Based Optimization），這種優(yōu)化方式不夠準(zhǔn)確，往往難以獲得最優(yōu)的執(zhí)行計(jì)劃，而基于代價(jià)的優(yōu)化CBO (Cost Based Optimization)則能夠針對(duì)大多數(shù)場景高效篩選出性能最好的執(zhí)行計(jì)劃。

因此，我們見到的高性能數(shù)據(jù)庫引擎往往使用基于代價(jià)的優(yōu)化器。

執(zhí)行器

執(zhí)行器是數(shù)據(jù)庫內(nèi)核最重要的部件之一。提升執(zhí)行器的性能，會(huì)很大程度上提升數(shù)據(jù)庫性能，因此各大數(shù)據(jù)庫廠商都紛紛投入很多精力到執(zhí)行器技術(shù)的研發(fā)中。

提升執(zhí)行器性能的手段主要有兩種技術(shù)路線，一種是向量計(jì)算（vectorized execution），另外一種是代碼生成（code generation）。目前主流的數(shù)據(jù)庫廠商會(huì)使用其中一種執(zhí)行器優(yōu)化技術(shù)，例如Snowflake使用的是向量計(jì)算，Impala使用的是代碼生成, Spark兩種都有使用，OushuDB使用了向量計(jì)算外加SIMD優(yōu)化技術(shù)。而一些傳統(tǒng)的數(shù)據(jù)庫還未實(shí)現(xiàn)其中任何一種性能技術(shù)。

聰明的你可能要問了，哪種技術(shù)路線更勝一籌？關(guān)于這個(gè)問題，不少研究和論文給出了答案：兩種技術(shù)側(cè)重點(diǎn)不同但都可以提升性能，不同的語句也會(huì)有不同程度的性能提升，向量計(jì)算更適合并行處理數(shù)據(jù)SIMD。所以，想要在并行計(jì)算的基礎(chǔ)上進(jìn)一步提升數(shù)據(jù)庫引擎性能，就可以結(jié)合并行處理數(shù)據(jù)充分利用CPU硬件指令（比如SIMD）。

SIMD

SIMD(single instruction multi-data), 即單指令多數(shù)據(jù)流，以同步的方式在同一時(shí)間內(nèi)執(zhí)行同一條指令。相比單指令單數(shù)據(jù)流（SISD），單指令多數(shù)據(jù)流一次性獲得所有操作數(shù)進(jìn)而加快了運(yùn)算，特別是數(shù)據(jù)密集型運(yùn)算。

如上圖所示，使用標(biāo)量運(yùn)算一次只能執(zhí)行一對(duì)數(shù)據(jù)的乘法操作，而采用SIMD乘法指令則可以一次同時(shí)執(zhí)行四對(duì)數(shù)據(jù)的乘法操作。作為向量體系結(jié)構(gòu)的一種，SIMD使用一條向量指令開啟一組數(shù)據(jù)操作，其中數(shù)據(jù)的加載、存儲(chǔ)以及數(shù)據(jù)計(jì)算以流水線的形式進(jìn)行。

通過在國際標(biāo)準(zhǔn)數(shù)據(jù)集TPCH上的測試，我們發(fā)現(xiàn)OushuDB 4.x的速度比最新版本的SparkSQL 3.x快大約一個(gè)數(shù)量級(jí)。

基于以上的分析，如果從提升數(shù)據(jù)庫性能的角度，我們可以采用基于代價(jià)的優(yōu)化+向量計(jì)算+ SIMD的技術(shù)路徑，作為提升數(shù)據(jù)庫性能的首選方法。

“數(shù)據(jù)庫運(yùn)行很慢的原因分析”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！