物化檢視如何快速完成資料聚合操作？

SQL在過去十年逐漸走向沒落，如今春風吹又生，SQL正在復甦。隨著應用程式變得越來越複雜，資料驅動的應用場景越來越多，人們慢慢意識到需要一種資料處理語言。而SQL作為一種用於處理結構化資料的機制，它的有效性大家有目共睹。

在此篇文章中，我們將討論VoltDB如何實現物化檢視，以及為什麼VoltDB的物化檢視非常迅速。

01 物化檢視和普通檢視有什麼區別？

一般而言，這裡會有兩種檢視：普通檢視和物化檢視。VoltDB只使用物化檢視，因此我們傾向於將它們簡稱為“檢視”。
“普通”檢視是假裝是資料表的SELECT查詢語句。在大多數情況下，檢視是隻讀的，這點很重要，因為涉及多個表的SELECT查詢語句可能會非常複雜，而物化檢視意味著該複雜邏輯只需要執行一次，然後就可以在應用程式中多次反覆使用。
物化檢視就像“普通”檢視，不過它快取了結果。

02 為什麼早期的“普通”檢視存在各種問題？

起初普通檢視很流行，但隨著時間的流逝逐漸走下神壇。大多數人想要的檢視包含諸如GROUP BY和SUM（）之類的功能，這意味著該檢視每次訪問時都必須遍歷大量資料。
因此，如果我有一個檢視計算了“每個客戶的銷售額”，並且想知道客戶“x”的銷售額，那麼當訪問該檢視時，需要計算所有客戶的銷售額，然後過濾出客戶為”x”的那一行。
這顯然會很慢，因此一些資料庫開發商試圖透過使用巧妙的查詢最佳化器來解決此問題，這些最佳化器需要將檢視的SQL與要執行的查詢合併，人們開始懷疑檢視的麻煩超過了它們帶來的價值。

03 為什麼物化檢視做起來不容易？

由於使用者希望使用GROUP BY和SUM（）做為檢視，但是“普通”檢視很慢，因此明顯的解決方法是快取檢視的SELECT語句的結果，這就是例項化檢視的來源。
但是，在老的RDBMS中，普通檢視到物化檢視，帶來了問題是基礎表上的UPDATE和INSERT效能卻很差。
為什麼？我們想象一下，有一個3億行的表，該表跟蹤某人駕駛的汽車的顏色。在該表中插入一行相對容易，因為我們每個人只有一行，因此不太可能發生衝突。但是，如果我們向GROUP BY ‘car_color’新增物化檢視，我們突然發現我們的插入內容無法完成，直到它們排隊將物化檢視中的行更新為’紅色’，'藍色’或任何其他的什麼顏色，之後才可以完成資料的插入。
這種開銷在單節點系統中是不好的，而在叢集環境中則更是災難性的，因為“藍色”的行可能在不同的伺服器上，讓問題從單行插入變成了分散式環境下的複雜的兩階段提交事務。

04 為什麼VoltDB的物化檢視的效能表現很好？

VoltDB是一個真正快速的OLTP系統，我們希望它同時可以完成物化檢視中的聚合計算。想要理解這一點，需要您更深入地瞭解VoltDB的體系結構，但是對於本篇文章而言，您需要了解的是：
VoltDB按CPU核心水平劃分資料，併為每個CPU核心有一個專用執行緒，該執行緒按順序處理所有請求。當我們嘗試更新例項化檢視總計時，這避免了分散式的競爭操作。

VoltDB中的物化檢視是隨著事務發生而自動更新的表。

在處理每個請求時，VoltDB識別對其物化檢視的本地節點部分做出必要更改。如果該檢視稱為SALES_BY_CUSTOMER，則每個分割槽將具有其自己的子集，並且當 “SALES”表發生更新時，資料行插入SALES表的同時也會更新物化檢視。

更新每個事務的物化檢視聽起來應該很慢，但實際上每個檢視將每個事務的SQL速度降低僅僅在1-5％。

如果更新表“X”且其檢視為“Y”，則對“X”和“Y”的更改是屬於同一個事務。VoltDB中的物化檢視無需重新計算，並始終反映當前最新的資料狀態。

因此，在VoltDB中讀取例項化檢視的成本幾乎與讀取表的成本相同：<1毫秒。

如你所見，物化檢視的實現並不是一件容易的事，但是如果能做好，它們可以提供對聚合資料的真正即時可視性，上層應用開發工作將變得輕鬆很多。
現在讓我們進入VoltDB的物化檢視應用場景。

4.1 物化檢視：在實時資料流中的聚合場景

一種常見的模式是使用例項化檢視按秒聚合高速事件流，然後使用SQL查詢按分鐘，小時或其他單位進一步聚合。這樣可以快速聚合不同粒度級別的時間序列資料。
這是從VoltDB下載工具包中包含的時間window應用程式中的示例，該應用程式根據使用者指定的時間範圍計算平均值：

CREATE TABLE timedata

(

uuid VARCHAR(36) NOT NULL,  val BIGINT NOT NULL, 

 update_ts TIMESTAMP NOT NULL 

); 

CREATE VIEW agg_by_second 

( 

 second_ts, 

 count_values, 

 sum_values 

) 

AS SELECT TRUNCATE(SECOND, update_ts), COUNT(*), SUM(val) 

 FROM timedata 

 GROUP BY TRUNCATE(SECOND, update_ts); 

— Find the average value over all tuples across all partitions for the last 

— N seconds, where N is a parameter the user supplies. 

CREATE PROCEDURE Average AS 

 SELECT SUM(sum_values) / SUM(count_values) 

 FROM agg_by_second 

 WHERE second_ts >= TO_TIMESTAMP(SECOND, SINCE_EPOCH(SECOND, NOW) – ?);

VoltDB SQL支援將時間戳轉換為SECOND，MINUTE，HOUR，DAY，DAYOFMONTH，DAYOFYEAR，MONTH，WEEK，WEEKOFYEAR，WEEKDAY和YEAR的功能，所有這些都可以與檢視定義和查詢混合並匹配。

4.2物化檢視：橫向擴充套件性場景

由於物化檢視的大小與VoltDB的其餘部分一樣，因此可以在快速傳入的寫入/更新工作負載中分配彙總計算的成本，並使快速讀取狀態彙總的成本非常低廉。
在上面的示例中，如果以15k / sec的速率插入元組並且有四個分割槽，那麼要計算最後十秒的平均值，VoltDB將需要掃描15萬行。使用例項化檢視時，它需要每秒掃描1行乘以分割槽數，即40行。以秒為單位預先彙總表的總和和計數具有巨大的優勢。

05 如何結合流式資料分析與單個事件決策？

由於物化檢視始終是最新的，在事務上是一致的並且可以透過標準SQL訪問，因此在執行事務時，可以輕鬆使用檢視中維護的聚合。
我們的選民示例是這樣做：該示例維護一個物化檢視，檢視是按電話號碼對傳入記錄進行分組，強制每個電話號碼投票限制的事務使用該檢視查詢傳入電話號碼註冊的先前呼叫。一個更復雜的示例可以使用上面討論的時間序列函式來強制執行每分鐘最大訪問量，以實現高速配額執行。
現在，讓我們使用表決器示例來展示在可伸縮攝取工作負載中分攤聚合成本的執行時優勢。該示例包括一個熱圖，該熱圖繪製了在每個州中哪個參賽者領導投票的圖表。當然，查詢該熱圖的資料需要按州計數選票。
使用例項化檢視，這可以在亞毫秒級的時間內完成（它需要為六個參賽者的每個分割槽讀取50行）。反之，如果沒有實體化檢視，則必須掃描所有投票，並且需要花費大量執行時間（並且需要讀取數百萬行）。
以下是一些具體數字，它表示顯示在最新的Intel Core i7 CPU上每個分割槽大約10GB資料（約1.3億行）的執行時間（沒有物化檢視，將掃描所有1.3億行，執行時間約為8秒）：

26> select state, count(*) from votes where state=’MA’ group by state; 

STATE C2 

—— ——– 

MA 3,839,860 

(Returned 1 rows in 8.13s) 

With the view execution time is sub-millisecond: 

31> select state, sum(num_votes) from v_votes_by_contestant_number_state where state 

= ‘MA’ group by state; 

STATE C2 

—— ——– 

MA 3,839,860 

(Returned 1 rows in 0.00s)

檢視的實現對資料攝取的工作量有一定的影響，但是即使使用物化檢視，資料庫每個核心每秒也可以處理超過4萬個請求。檢視開銷可以透過水平可伸縮性來補償—所需的工作可以跨核心和叢集中的伺服器擴充套件。這種權衡使得可以在高吞吐量的每個事件事務中使用實時聚合。
v_votes_by_contestant_number_state檢視顯示1個分割槽吞吐量：

Throughput 42252/s, Aborts/Failures 0/0 

Throughput 45407/s, Aborts/Failures 0/0 

Throughput 46352/s, Aborts/Failures 0/0 

Throughput 44341/s, Aborts/Failures 0/0

1個沒有v_votes_by_contestant_number_state_view的分割槽吞吐量：

Throughput 50525/s, Aborts/Failures 0/0

Throughput 52503/s, Aborts/Failures 0/0

Throughput 50961/s, Aborts/Failures 0/0

Throughput 51190/s, Aborts/Failures 0/0

06 總結

VoltDB是一個記憶體ACID向外擴充套件SQL資料庫。它每秒可以處理數萬至數百萬個事務，還能夠針對高速資料流進行實時SQL分析。
VoltDB實時分析功能的重要部分圍繞其物化檢視實現而構建。VoltDB的物化檢視支援實時彙總和摘要，並支援將實時分析與按事件決策結合在一起。

如果您對VoltDB的工業物聯網大資料低延遲方案、全生命週期的實時資料平臺管理等感興趣，歡迎私信，進入到我們的官方交流群。