?譯者 | 李睿

審校 | 孫淑娟

本文將討論數(shù)據(jù)庫管理系統(tǒng)（DBMS）中的SpeedUp和ScaleUp，這是數(shù)據(jù)庫并行處理中用于調(diào)整數(shù)據(jù)庫的兩個(gè)基本概念。

一、SpeedUp

由于數(shù)據(jù)庫的規(guī)模穩(wěn)步增長(zhǎng)，承載數(shù)百GB數(shù)據(jù)的數(shù)據(jù)倉庫現(xiàn)在相對(duì)較小。甚至數(shù)TB的數(shù)據(jù)可以存儲(chǔ)在一些數(shù)據(jù)庫中，這些數(shù)據(jù)庫稱為超大數(shù)據(jù)庫(VLDB)。

為了獲取商業(yè)智能和支持決策，這些數(shù)據(jù)倉庫要接受復(fù)雜的查詢。這樣的查詢需要很長(zhǎng)時(shí)間來處理?？梢酝ㄟ^同時(shí)運(yùn)行這些查詢來縮短總體時(shí)間，同時(shí)仍然提供必要的處理時(shí)間。

使用一個(gè)核心處理器（CPU）的運(yùn)行時(shí)間與使用幾個(gè)核心處理器的運(yùn)行時(shí)間之比稱為SpeedUp。

可以采用下面的公式來計(jì)算。它估計(jì)了使用多個(gè)處理器而不是一個(gè)處理器所獲得的性能優(yōu)勢(shì)：

Speedup =Time1/Timen

Time1是使用一個(gè)處理器完成一項(xiàng)任務(wù)所需的時(shí)間，而Timen是使用m個(gè)處理器完成同一項(xiàng)工作所需的時(shí)間。

1.Speedup曲線

在理想的情況下，并行處理的Speedup應(yīng)該與每個(gè)給定操作所使用的處理器數(shù)量相對(duì)應(yīng)。

或者，45度直線是Speedup曲線的最佳形狀。

因?yàn)樘幚砥鞑⑿猩婕暗揭恍╅_銷，所以很少能得到SpeedUp曲線?？梢垣@得的Speedup受到應(yīng)用程序固有的并行性的顯著影響。

有些任務(wù)的組成部分可以很容易地并行處理。例如，可以并發(fā)地連接兩個(gè)巨大的表。

然而，有些任務(wù)是不能分離的。其中一個(gè)實(shí)例是無分區(qū)索引掃描。如果應(yīng)用程序幾乎沒有或根本沒有固有的并行性，那么Speedup將是最小的或根本不存在的。

效率是用Speedup除以處理器總數(shù)來計(jì)算的。在這個(gè)示例中有四個(gè)處理器，Speedup也是四個(gè)。因此，其效率為100%，這是一個(gè)理想的情況。

2.示例

CPU執(zhí)行一個(gè)進(jìn)程需要3分鐘。

通過將一個(gè)進(jìn)程劃分為更小的任務(wù)，CPU需要1分鐘來執(zhí)行它。

SpeedUp的類型：

• Linear SpeedUp
• Sub-Linear SpeedUp

3.線性SpeedUp

如果SpeedUp是N，那么SpeedUp是線性的。換句話說，小系統(tǒng)的運(yùn)行時(shí)間是大系統(tǒng)的運(yùn)行時(shí)間的N倍(N是資源的數(shù)量，例如CPU)。

例如，如果一臺(tái)機(jī)器在10秒內(nèi)完成一項(xiàng)任務(wù)，但10臺(tái)并行工作的機(jī)器在1秒內(nèi)完成同一項(xiàng)任務(wù)，則SpeedUp為(10/1)=10(參見上面的等式)，這等于N，即更大系統(tǒng)的大小。10倍強(qiáng)大的機(jī)制允許SpeedUp。

4.Sub-Linear SpeedUp

如果SpeedUp小于N，它就是次線性的(這在大多數(shù)并行系統(tǒng)中是常見的)。

更深刻的討論：如果SpeedUp是N或線性的，這意味著性能與預(yù)期一致。

如果SpeedUp小于N，則可能出現(xiàn)兩種情況：

· 情況1：當(dāng)“SpeedUp值”大于N時(shí)，則系統(tǒng)性能優(yōu)于預(yù)期。在這種情況下，SpeedUp值將小于1。

· 情況2：如果SpeedUp N是次線性的，在這種情況下，其分母(巨大的系統(tǒng)運(yùn)行時(shí)間)超過了單個(gè)機(jī)器的運(yùn)行時(shí)間。

在這種情況下，該值的范圍在0到1之間，需要設(shè)置一個(gè)閾值，以便任何低于該閾值的值都將阻止并行處理的發(fā)生。

在這樣的系統(tǒng)中，在處理器之間重新分配工作負(fù)載需要特別小心。

二、加快數(shù)據(jù)庫速度的幾種技術(shù)

現(xiàn)在了解一些SpeedUp數(shù)據(jù)庫的技術(shù)。

1.索引

通過保留有效的搜索數(shù)據(jù)結(jié)構(gòu)，索引使數(shù)據(jù)庫能夠更快地定位相關(guān)行(例如B-Tree)。

每個(gè)表都必須執(zhí)行此操作。可能很少添加索引，因?yàn)樗枰罅康挠?jì)算并需要生產(chǎn)系統(tǒng)。

使用SQL(MySQL,PostgreSQL)，創(chuàng)建索引很簡(jiǎn)單：

SQL
1 CREATE INDEX random index name
2 ON your table name
3(col1, col2);

通過添加索引，可以更快地搜索數(shù)據(jù)庫。但是，UPDATE、INSERT和DELETE命令需要較長(zhǎng)時(shí)間執(zhí)行，除非WHERE子句需要較長(zhǎng)時(shí)間。

2.查詢?cè)鰪?qiáng)

數(shù)據(jù)庫用戶對(duì)每個(gè)查詢進(jìn)行查詢優(yōu)化。編寫查詢的方法有很多種，其中一些方法可能比其他方法更有效。

n+1問題和使用循環(huán)提交多個(gè)請(qǐng)求(而不是僅提交一個(gè)請(qǐng)求)來獲得數(shù)據(jù)屬于查詢優(yōu)化主題的一個(gè)稍微不同的子類別。

3.業(yè)務(wù)和分區(qū)的更改

隨著企業(yè)規(guī)模的擴(kuò)張，希望給客戶留下深刻印象。試圖包含客戶要求的任何微小的新特性。這可能導(dǎo)致特性蠕變。

根據(jù)UNIX的理念，這在很久以前就是一個(gè)問題：相比之下，將在線服務(wù)數(shù)據(jù)劃分為用戶組可能是可以接受的。也許把它們劃分成不同的區(qū)域更有意義?這就是在Secure Code Warrior和AWS所觀察到的。

可以將其分為“私人客戶端”、“小型企業(yè)客戶端”和“大型企業(yè)客戶端”。也許應(yīng)用程序的一部分可以作為自己的服務(wù)使用單獨(dú)的數(shù)據(jù)庫。

4.復(fù)制

如果讀取是一個(gè)問題，而少量的更新時(shí)間延遲不是主要問題，那么復(fù)制是一個(gè)簡(jiǎn)單的解決方案。在復(fù)制過程中，將不斷地將數(shù)據(jù)庫復(fù)制到另一個(gè)系統(tǒng)。它充當(dāng)故障轉(zhuǎn)移機(jī)制并由SpeedUp讀取。

一個(gè)主服務(wù)器和多個(gè)復(fù)制服務(wù)器是預(yù)期的配置，這些服務(wù)器以前以不同的名稱命名。數(shù)據(jù)更新由主服務(wù)器處理，而不是復(fù)制服務(wù)器，復(fù)制服務(wù)器只是鏡像主服務(wù)器。其他拓?fù)湟泊嬖?，例如環(huán)形或星形配置。

5.水平分區(qū)

如果表非常大，可以將一些行存儲(chǔ)在一臺(tái)機(jī)器上，將其他行存儲(chǔ)在另一臺(tái)機(jī)器上。水平分區(qū)是將數(shù)據(jù)劃分為行的概念。

6.垂直分區(qū)

可以使用列而不是行將大型數(shù)據(jù)庫拆分為更小的部分。人們可能對(duì)此感到擔(dān)心，因?yàn)樗麄兯赖氖?，將?shù)據(jù)庫規(guī)范化是一件好事。

在討論數(shù)據(jù)庫架構(gòu)的各個(gè)階段時(shí)，記住這一點(diǎn)至關(guān)重要。邏輯設(shè)計(jì)涉及到許多的常規(guī)數(shù)據(jù)庫類型?，F(xiàn)在關(guān)注的是物理設(shè)計(jì)。

也許不是所有應(yīng)用程序組件都需要一行的所有列。因此，把它們分開也許是可以接受的。因此，行分割是垂直分區(qū)的另一個(gè)名稱。

需要記住的一點(diǎn)是，垂直擴(kuò)展與垂直分區(qū)無關(guān)！

如果不涉及隱私或法律問題，垂直分區(qū)可能是有利的。

盡管將其與其他數(shù)據(jù)結(jié)合在一起合乎邏輯，但應(yīng)用程序的大部分并不需要它，甚至更好的是，可以將其隱藏在一個(gè)私有微服務(wù)后面，并將其存儲(chǔ)在一個(gè)全新的數(shù)據(jù)庫中。

7.分片：分區(qū)的下一步

已經(jīng)有兩種不同的方法來對(duì)數(shù)據(jù)進(jìn)行分組。為了幫助數(shù)據(jù)庫更快地處理頻繁查詢，在同一個(gè)系統(tǒng)上劃分?jǐn)?shù)據(jù)可能已經(jīng)很有意義了。

但是，如果數(shù)據(jù)庫使用當(dāng)前機(jī)器上的所有CPU或內(nèi)存，那么使用不同的機(jī)器是明智的。 單個(gè)邏輯數(shù)據(jù)集被分片并分布在不同的設(shè)備上。

正如人們所料，這有很多問題，所以應(yīng)該只將其作為最后的手段。例如，2010年10月，一個(gè)分片問題導(dǎo)致Foursquare無法使用長(zhǎng)達(dá)11個(gè)小時(shí)。

第一個(gè)問題是，應(yīng)用程序必須知道哪個(gè)分片擁有所需的數(shù)據(jù)。因此，應(yīng)用程序邏輯可能處處受到影響。

8.數(shù)據(jù)庫集群

集群這個(gè)概念似乎通過使用復(fù)制作為掩蓋技術(shù)來掩蓋分片的問題。

三、Scaleup

通過添加更多的處理器和磁盤，Scaleup是應(yīng)用程序在工作負(fù)載大小或事務(wù)量增長(zhǎng)時(shí)保持響應(yīng)時(shí)間的能力。從可擴(kuò)展性的角度經(jīng)常討論Scaleup。

數(shù)據(jù)庫應(yīng)用程序中的擴(kuò)展可以是基于批處理或基于事務(wù)的。批處理擴(kuò)展可以支持更大的批處理作業(yè)，而不犧牲響應(yīng)時(shí)間。在不犧牲響應(yīng)時(shí)間的情況下，事務(wù)擴(kuò)展可以支持更多的事務(wù)。

在這兩個(gè)場(chǎng)景中都添加了更多的處理器來維持響應(yīng)時(shí)間。例如，一個(gè)四個(gè)處理器系統(tǒng)可以提供與單一處理器系統(tǒng)相同的響應(yīng)時(shí)間，即支持四個(gè)處理器系統(tǒng)每分鐘處理400個(gè)事務(wù)，而單處理器系統(tǒng)則支持每分鐘處理100個(gè)事務(wù)。

1.理想的Scaleup曲線

該圖將理想狀態(tài)表示為曲線或平坦的直線。事實(shí)上，即使添加更多的處理器，最終反應(yīng)時(shí)間也會(huì)隨著事物量的增加而增加。

擴(kuò)展能力取決于在保持恒定響應(yīng)時(shí)間的情況下可以增加多少處理能力。下面的公式用于確定Scaleup：

Scaleup=Volumem/Volume1

Volume1是使用一個(gè)處理器在同一時(shí)間段內(nèi)執(zhí)行的事務(wù)量，而Volumem是使用m個(gè)處理器執(zhí)行的事務(wù)量。對(duì)于前面的例子:

Scaleup=400/100。

Scaleup=4，

使用4個(gè)處理器，可以實(shí)現(xiàn)4倍的擴(kuò)展。

2.Scaleup的類型

• Liner Scaling up
• Sub-linear Scaleup

3.Linear Scaleup

如果資源的增長(zhǎng)與問題的嚴(yán)重程度成正比，那么Scaleup是線性的(這是非常罕見的)。上面的等式表明，Scaleup=1，如果解決一個(gè)小系統(tǒng)小問題所花的時(shí)間等于解決一個(gè)大系統(tǒng)大問題所花的時(shí)間，則Scaleup是線性的。

4.Sub-Linear Scaleup

如果具有巨大問題的大型系統(tǒng)的運(yùn)行時(shí)間比具有較小問題的小型系統(tǒng)的運(yùn)行時(shí)間長(zhǎng)，則擴(kuò)展是次線性的。

相關(guān)的其他討論包括：如果Scaleup是一個(gè)或線性的，則系統(tǒng)會(huì)完美地執(zhí)行。

如果Scaleup是次線性的且值在0到1之間，那么在選擇并行執(zhí)行的計(jì)劃時(shí)必須格外小心。例如，如果解決一個(gè)小問題所需的時(shí)間是5秒，而解決一個(gè)大問題所需的時(shí)間也是5秒。

這清楚地展示了線性。因此，5/5=1。對(duì)于不同的分母值，特別是較低的值(超出限制是無法想象的)，系統(tǒng)的性能令人滿意。

但是，Scaleup下降到1以下，這就需要特別注意，以便為分母的較高值(如6、7、8等)進(jìn)行更好的任務(wù)再分配。

四、SpeedUp和Scaleup的區(qū)別

SpeedUp和Scaleup的顯著區(qū)別在于，SpeedUp是通過保持固定的問題大小來計(jì)算的，而Scaleup是通過增加問題大小或事務(wù)量來確定的。

在保持恒定的響應(yīng)時(shí)間的情況下，通過添加額外的處理器可以在多大程度上增強(qiáng)事務(wù)量，這是衡量擴(kuò)Scaleup的方法。

希望這篇關(guān)于Scaleup和SpeedUp的文章能幫助人們學(xué)習(xí)這些基本知識(shí)。

原文鏈接：https://dzone.com/articles/what-are-speedup-and-scaleup-in-dbms