?譯者 | 李睿

審校 | 孫淑娟

本文將討論數據庫管理系統（DBMS）中的SpeedUp和ScaleUp，這是數據庫并行處理中用于調整數據庫的兩個基本概念。

一、SpeedUp

由于數據庫的規模穩步增長，承載數百GB數據的數據倉庫現在相對較小。甚至數TB的數據可以存儲在一些數據庫中，這些數據庫稱為超大數據庫(VLDB)。

為了獲取商業智能和支持決策，這些數據倉庫要接受復雜的查詢。這樣的查詢需要很長時間來處理。可以通過同時運行這些查詢來縮短總體時間，同時仍然提供必要的處理時間。

使用一個核心處理器（CPU）的運行時間與使用幾個核心處理器的運行時間之比稱為SpeedUp。

可以采用下面的公式來計算。它估計了使用多個處理器而不是一個處理器所獲得的性能優勢：

Speedup =Time1/Timen

Time1是使用一個處理器完成一項任務所需的時間，而Timen是使用m個處理器完成同一項工作所需的時間。

1.Speedup曲線

在理想的情況下，并行處理的Speedup應該與每個給定操作所使用的處理器數量相對應。

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

因為處理器并行涉及到一些開銷，所以很少能得到SpeedUp曲線。可以獲得的Speedup受到應用程序固有的并行性的顯著影響。

有些任務的組成部分可以很容易地并行處理。例如，可以并發地連接兩個巨大的表。

然而，有些任務是不能分離的。其中一個實例是無分區索引掃描。如果應用程序幾乎沒有或根本沒有固有的并行性，那么Speedup將是最小的或根本不存在的。

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

2.示例

CPU執行一個進程需要3分鐘。

通過將一個進程劃分為更小的任務，CPU需要1分鐘來執行它。

SpeedUp的類型：

• Linear SpeedUp
• Sub-Linear SpeedUp

3.線性SpeedUp

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

例如，如果一臺機器在10秒內完成一項任務，但10臺并行工作的機器在1秒內完成同一項任務，則SpeedUp為(10/1)=10(參見上面的等式)，這等于N，即更大系統的大小。10倍強大的機制允許SpeedUp。

4.Sub-Linear SpeedUp

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

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

如果SpeedUp小于N，則可能出現兩種情況：

· 情況1：當“SpeedUp值”大于N時，則系統性能優于預期。在這種情況下，SpeedUp值將小于1。

· 情況2：如果SpeedUp N是次線性的，在這種情況下，其分母(巨大的系統運行時間)超過了單個機器的運行時間。

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

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

二、加快數據庫速度的幾種技術

現在了解一些SpeedUp數據庫的技術。

1.索引

通過保留有效的搜索數據結構，索引使數據庫能夠更快地定位相關行(例如B-Tree)。

每個表都必須執行此操作。可能很少添加索引，因為它需要大量的計算并需要生產系統。

使用SQL(MySQL,PostgreSQL)，創建索引很簡單：

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

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

2.查詢增強

數據庫用戶對每個查詢進行查詢優化。編寫查詢的方法有很多種，其中一些方法可能比其他方法更有效。

n+1問題和使用循環提交多個請求(而不是僅提交一個請求)來獲得數據屬于查詢優化主題的一個稍微不同的子類別。

3.業務和分區的更改

隨著企業規模的擴張，希望給客戶留下深刻印象。試圖包含客戶要求的任何微小的新特性。這可能導致特性蠕變。

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

可以將其分為“私人客戶端”、“小型企業客戶端”和“大型企業客戶端”。也許應用程序的一部分可以作為自己的服務使用單獨的數據庫。

4.復制

如果讀取是一個問題，而少量的更新時間延遲不是主要問題，那么復制是一個簡單的解決方案。在復制過程中，將不斷地將數據庫復制到另一個系統。它充當故障轉移機制并由SpeedUp讀取。

一個主服務器和多個復制服務器是預期的配置，這些服務器以前以不同的名稱命名。數據更新由主服務器處理，而不是復制服務器，復制服務器只是鏡像主服務器。其他拓撲也存在，例如環形或星形配置。

5.水平分區

如果表非常大，可以將一些行存儲在一臺機器上，將其他行存儲在另一臺機器上。水平分區是將數據劃分為行的概念。

6.垂直分區

可以使用列而不是行將大型數據庫拆分為更小的部分。人們可能對此感到擔心，因為他們所知道的是，將數據庫規范化是一件好事。

在討論數據庫架構的各個階段時，記住這一點至關重要。邏輯設計涉及到許多的常規數據庫類型。現在關注的是物理設計。

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

需要記住的一點是，垂直擴展與垂直分區無關！

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

盡管將其與其他數據結合在一起合乎邏輯，但應用程序的大部分并不需要它，甚至更好的是，可以將其隱藏在一個私有微服務后面，并將其存儲在一個全新的數據庫中。

7.分片：分區的下一步

已經有兩種不同的方法來對數據進行分組。為了幫助數據庫更快地處理頻繁查詢，在同一個系統上劃分數據可能已經很有意義了。

但是，如果數據庫使用當前機器上的所有CPU或內存，那么使用不同的機器是明智的。 單個邏輯數據集被分片并分布在不同的設備上。

正如人們所料，這有很多問題，所以應該只將其作為最后的手段。例如，2010年10月，一個分片問題導致Foursquare無法使用長達11個小時。

第一個問題是，應用程序必須知道哪個分片擁有所需的數據。因此，應用程序邏輯可能處處受到影響。

8.數據庫集群

集群這個概念似乎通過使用復制作為掩蓋技術來掩蓋分片的問題。

三、Scaleup

通過添加更多的處理器和磁盤，Scaleup是應用程序在工作負載大小或事務量增長時保持響應時間的能力。從可擴展性的角度經常討論Scaleup。

數據庫應用程序中的擴展可以是基于批處理或基于事務的。批處理擴展可以支持更大的批處理作業，而不犧牲響應時間。在不犧牲響應時間的情況下，事務擴展可以支持更多的事務。

在這兩個場景中都添加了更多的處理器來維持響應時間。例如，一個四個處理器系統可以提供與單一處理器系統相同的響應時間，即支持四個處理器系統每分鐘處理400個事務，而單處理器系統則支持每分鐘處理100個事務。

1.理想的Scaleup曲線

該圖將理想狀態表示為曲線或平坦的直線。事實上，即使添加更多的處理器，最終反應時間也會隨著事物量的增加而增加。

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

Scaleup=Volumem/Volume1

Volume1是使用一個處理器在同一時間段內執行的事務量，而Volumem是使用m個處理器執行的事務量。對于前面的例子:

Scaleup=400/100。

Scaleup=4，

使用4個處理器，可以實現4倍的擴展。

2.Scaleup的類型

• Liner Scaling up
• Sub-linear Scaleup

3.Linear Scaleup

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

4.Sub-Linear Scaleup

如果具有巨大問題的大型系統的運行時間比具有較小問題的小型系統的運行時間長，則擴展是次線性的。

相關的其他討論包括：如果Scaleup是一個或線性的，則系統會完美地執行。

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

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

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

四、SpeedUp和Scaleup的區別

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

在保持恒定的響應時間的情況下，通過添加額外的處理器可以在多大程度上增強事務量，這是衡量擴Scaleup的方法。

希望這篇關于Scaleup和SpeedUp的文章能幫助人們學習這些基本知識。

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