日本在线免费AⅤ视频_欧美一级网站在线播放_久久久久久免费一区二区三区_国产在线网址

各位同行朋友，本篇是本系列的最后一篇，也是最舒服的一篇，因為講內(nèi)容是自動優(yōu)化，也就是不需要DBA主動干預，數(shù)據(jù)庫會沒事就給自己做優(yōu)化！是不是有種躺贏的感覺？讓本人給大家匯報數(shù)據(jù)庫到底是怎么實現(xiàn)自動優(yōu)化的？

柏睿數(shù)據(jù)內(nèi)存分布式數(shù)據(jù)庫RapidsDB的自動優(yōu)化體現(xiàn)在2個階段：

數(shù)據(jù)入庫過程

入庫過程的自動優(yōu)化解決2個常見的OLAP型MPP數(shù)據(jù)庫問題，傳統(tǒng)的數(shù)控則需要外部手段或者手工執(zhí)行命令來實現(xiàn)相同的優(yōu)化效果：

1、自動優(yōu)化小批量寫入（比如單行插入）過程，解決高頻小數(shù)據(jù)量寫入的性能低下問題；

2、自動優(yōu)化數(shù)據(jù)入庫前排序入庫過程，解決因新數(shù)據(jù)無序?qū)懭氘a(chǎn)生的查詢性能不高問題。

RapidsDB實現(xiàn)的方式如下：

跟其他友商分布式數(shù)據(jù)庫的列存儲實現(xiàn)不同，RapidsDB將新寫入的數(shù)據(jù)先將它們以跳表的方式臨時存儲在內(nèi)存中。這個操作由數(shù)據(jù)庫后臺自動處理的，這些以行存方式的跳過列表數(shù)據(jù)，可以對讀取可見。

具體一點，向列存表插入數(shù)據(jù)時，數(shù)據(jù)會先寫入臨時的行存跳表或創(chuàng)建新的列存儲支持行段。至于是臨時表還是新建行段，數(shù)據(jù)庫引擎需要由根據(jù)插入數(shù)據(jù)量大小和列存儲索引的當前狀態(tài)的自動觸發(fā)確定的。每個數(shù)據(jù)分區(qū)16 MB，是 INSERT 或 LOAD DATA 寫入數(shù)據(jù)優(yōu)化的默認閾值。當超過這個閾值時，當前外部寫入的數(shù)據(jù)就會在內(nèi)存經(jīng)過排序后，直接寫入新建的行段，反之則臨時存放在行存跳表中，經(jīng)過超時或者新來數(shù)據(jù)達到閾值后，寫入列存行段中。

經(jīng)過上述操作，數(shù)據(jù)入庫過程的自動優(yōu)化完成。

數(shù)據(jù)入庫后

入庫過程后的自動優(yōu)化，就是為了解決傳統(tǒng)分布式數(shù)據(jù)庫甚至Hadoop平臺也非常常見的：在用戶使用一段時間后，發(fā)現(xiàn)如果沒有對數(shù)據(jù)庫的存儲進行人工定時維護，則會引起性能大幅下降的問題，RapidsDB的3個自動優(yōu)化手段，就是解決核心的3個性能影響因素：

1、無論做增刪改操作，數(shù)據(jù)庫都會自動對相關(guān)的列存行段中的數(shù)據(jù)自動重新排序，保證最佳的查詢性能；

2、當列存行段內(nèi)重新排序完成后，其外的行段組會重新做排序組織，進一步使數(shù)據(jù)有序，二次優(yōu)化性能；

3、經(jīng)過上述2點的優(yōu)化，有序數(shù)據(jù)使壓縮率得到提升，數(shù)據(jù)文件也得到合并，數(shù)據(jù)文件個數(shù)同時也會減少。IO讀寫性能可以在整個使用過程中，一直保存在極高的狀態(tài)中。

基本實現(xiàn)手段如下：

我們都知道如果表中的行在所有行段中都是全局排序的，那么列式表的性能最好。實際上，在連續(xù)寫入的情況下，維持這樣的順序是極難的。

RapidsDB使用了一種高級的算法，允許它在新增或更新數(shù)據(jù)時盡可能保持有序。這個過程被稱為background merger，并且為使行段的數(shù)據(jù)順序能夠得到持續(xù)優(yōu)化，則該過程會一直在后臺自動運行。

當background merger在運行過程中，在庫內(nèi)數(shù)據(jù)被增刪改等改變時，它會停止到當前任務(wù)并且重新開始。鑒于每次只處理一小塊行段數(shù)據(jù)，所以被停止的任務(wù)影響的只是少量的數(shù)據(jù)。只有在大量的更新工作負載下，重新排序處理效率才會顯著減慢，這是因為另一個機制pessimistic merger會鎖定當前正在處理的行段。用戶也可以通過運行命令OPTIMIZE TABLE手動觸發(fā)pessimistic merger。我們將在下面解釋如何決定是否有必要進行該指令，并如何運行它。

RapidsDB使用sorted row segment group（排序行段組）的概念來描述參與排序的一組行段。即行段重新排序的過程，并且對于一個行段而言，其最小的行號不小于其之前的任何行段中最大的行號，則這些行段形成排序的行段組。這里所描述的一行比另一行小，是代表該行的CLUSTERED COLUMNSTORE鍵的列值比另一行的列值小。

如果數(shù)據(jù)有一個完美的全局順序，它將由一個排序的行段組組成。如果剛?cè)霂斓脑紨?shù)據(jù)是以完全隨機的順序排列的，那么它會包含與行段一樣多的排序行段組。background merger的任務(wù)邏輯就是重新組織行段之間的行，即盡量減少排序的行段組的數(shù)量。

以下面的例子直觀介紹：

要檢查特定表的已排序行段組的當前狀態(tài)，請在CLI環(huán)境中運行SHOW COLUMNAR MERGE STATUS FOR來查看：

讓我們仔細看結(jié)果的第一行，我們知道存儲在分區(qū)0上的表的切片具有3個有序的行段組，一個由741個行段組成，一個由16個行段組成，最后一個由1行段組成，共計758個行段。考慮這種有序的行段組對非常簡單查詢的影響：

根據(jù)排序行段組的定義，第一個排序的行段組最多包含一個包含user_group = 15的行的行段，除非user_group = 15位于兩個行段的邊界上，或者如果存在較大數(shù)據(jù)傾斜并且?guī)讉€行段僅由user_group = 15的行組成。類似的，第二排序行段組中最多一個行段包含相關(guān)行。這樣，總共758個行段中只有三個將被打開和具體化。雖然本例中的查詢非常簡單，但類似的推理同樣適用于復雜查詢中。

現(xiàn)在我們看一下分區(qū)2上有序的行段組。很明顯，它的優(yōu)化程度遠遠低于剩下的2個，類似上面所示的選擇查詢將會導致物化8個行段。如果啟用了background merger，并且沒有或者少量工作負載同時運行，那么這個分區(qū)將會在幾秒鐘內(nèi)得到優(yōu)化。然而，在數(shù)據(jù)庫執(zhí)行大量的增刪改任務(wù)時，background merger的處理性能會被影響。在這種情況下，不如通過手動觸發(fā)pessimistic merger，讓增刪改任務(wù)和后臺優(yōu)化任務(wù)前后腳獨立完成更合理：

如果當我們執(zhí)行OPTIMIZE TABLE時運行SHOW COLUMNAR MERGE STATUS，那么我們將會看見其作用：

新出現(xiàn)的一行代表分區(qū)3上正在進行一個手動合并，此時已經(jīng)完成了53.12%的工作任務(wù)。

當完成合并任務(wù)后，現(xiàn)在情況更好了：

請注意，在本例中，沒有任何分區(qū)被合并到單個有序的行段組中。其原因是，兩種不同的合并方式均采用一種高級算法，該算法被優(yōu)化為在并發(fā)寫入的情況下進行小的分批次工作，并將數(shù)據(jù)保持在幾個有序的行段組中，而不是試圖將所有數(shù)據(jù)合并到單個有序的行段組中。如果可以犧牲一些數(shù)據(jù)處理時間來獲得更高的查詢性能，則可以運行手動命令，將每個分區(qū)上的數(shù)據(jù)合并到一個有序的行段組中：

此時，任何選擇查詢將只具體化每一個分區(qū)的一個行段。

當向列式表中插入少量行時，使用內(nèi)存中行存儲支持的段來存儲行。當這個以行存儲為基礎(chǔ)的段被填滿時，后臺刷新程序background flusher會定期將這些行刷新到磁盤中。通過運行OPTIMIZE TABLEFLUSH，可以手動將受行存儲支持的段刷新到磁盤中。

至此，例子中數(shù)據(jù)表t的后臺自動排序完成了。整個過程中，數(shù)據(jù)庫無須用戶干預，僅通過自動優(yōu)化實現(xiàn)了高性能。

目前，RapidsDB已經(jīng)在國有某大行普惠金融項目應用中運行超過10個月，產(chǎn)品自動優(yōu)化證明了它的能力和價值。中間經(jīng)歷過幾次10TB級的數(shù)據(jù)加載，每天10GB級的數(shù)據(jù)新增和更新，以及定時的滾動式刪除。過程中，技術(shù)團隊無需對數(shù)據(jù)庫做任何優(yōu)化干預，相同場景的數(shù)據(jù)操作沒有任何性能下降的跡象！

免責聲明：市場有風險，選擇需謹慎！此文僅供參考，不作買賣依據(jù)。