事務分析(Translytic)僅僅是換了個名字的OLTP嗎?

VoltDB_China發表於2019-02-19

最近,Forrester開始關注事務分析(translytics)和事務分析資料庫(Translytical Database)。所謂事務分析資料庫,就是“事務發生的瞬間即可提供分析”的資料庫。這是營銷炒作?還是真有其事?

傳統的OLTP資料庫處理大量火燒眉毛的快速事務,但實際上並沒做多少。一個OLTP資料庫應用程式通常涉及:

  • “共享有限資源”——
    正被評估、分配或使用著的有價值的物件。有時,多個事務將嘗試使用相同的“共享有限資源”。在傳統的RDBMS中,這是透過行級鎖定來處理的。

  • 大量類似的ACID交易。

  • 低延遲,通常在單位數毫秒範圍內。

術語“Translytics”(事務分析)是指具有附加功能的OLTP- 因此OLTP是Translytics的子集,它增加了

  • “計數”- 事務分析資料庫需要準確保持由任意事務組不斷更改的執行總計。“現在這個郵編區域內有多少輛汽車?”就是一個例子。
  • “聚合”與獲取傳入事務流並生成新資料有關,這些資料可跨多個事務合併多個資料。您的家庭DSL連線每小時使用多少頻寬就是聚合的一個示例,因為我們將每天不可預測的輸入記錄轉換為日均24個輸出記錄。在某些用例中,我們可以靠猜矇混過關,在其他用例中,我們可能被法律要求必須具有100%的準確性。
  • “Telling”是向下遊系統傳送資料的過程。在某些時候,世界上其他地方需要知道你正在做的OLTP內容,但外界如何知道要看些什麼?通常會看到花費大量時間和精力來輪詢OLTP系統以檢視已發生變化的情況。


現在能肯定這一切都很容易嗎?如果是每秒少量交易的小規模,這不是問題。但隨著工作量的增加,這將變成一個重要的計算問題。

傳統的RDBMS產品無法處理重要的事務分析工作負載。

當您在舊版RDBMS中發出查詢時,它會嘗試根據您執行查詢時的資料的樣子給出答案。對於快速執行的查詢,這不是一個因素,但是查詢保持執行的時間越長,伺服器就越難以“記住”查詢發出時所有行的樣子,因為它們可能從查詢釋出的那一刻起已經反覆更改。

為一個查詢執行此操作是可管理的,但是當為了“計數”和“聚合”而每秒發出數百個這樣的查詢時,開銷就變得完全無法管理。

NoSQL產品無法實時準確地進行聚合和計數

NoSQL產品更難以發現“計數”和“聚合”,因為它們的ACID實現通常僅限於單個記錄或鍵/值對。這使得很難以任何精度計算或聚合多個“事物”。“Telling”也可能非常困難,因為有些產品(例如Cassandra)不喜歡您需要發出的範圍查詢,以獲取記錄塊以供給下游系統。

VoltDB的架構非常適合事務分析(Translytics)

VoltDB非常擅長傳統的OLTP工作負載,客戶工作負載通常超過100KTPS,有時甚至超過這個數量。但它也具有對Translytics非常有用的功能:

物化觀點

VoltDB的物化檢視與傳統的RDBMS中的工作方式不同。在傳統的RDBMS中,檢視是偽裝成表的SQL查詢。

當您查詢“檢視”時,您會發出基礎查詢,可能還有一些基於WHERE子句的其他複雜情況。雖然“檢視”的實現不會減慢插入速度,但是讀取它可能非常昂貴,導致我們上面討論過的“計數”,“聚合”和“Telling (告訴)”問題。

在VoltDB中,物化檢視實際上是一個真實的表,每次更新它所基於的基礎表時都會更新。事實證明,在VoltDB中執行此操作的增量成本很小- 執行時間增加了幾個百分點。但是當您從VoltDB物化檢視中“選擇”時,您可以簡單地讀取所需的答案,而無需發出觸及基礎表中數千個易失行的昂貴的讀取一致性查詢。

匯出流

OLTP系統的一個典型問題是告訴其他連線系統在聚合級別上發生了什麼。如果我們在某個時刻跟蹤預付費電話的使用情況,我們需要報告撥打電話的次數,費用等等。正如我們上面提到的,這不易擴充套件。

VoltDB具有“匯出流”的概念。它就像一張桌子,只是這張桌子只允許你"插入"。當您插入一行時,它會被放置在一個“至少一次”佇列中,該佇列連線到任何有效的外部目標,無論是HDFS,Kafka,HTTP還是您自己實現的目標。

INSERT(插入)具有其他語句所做的所有ACID語義,因此INSERT既可以作為事務的一部分發生,也可以根本不發生。

匯出流因為它們存在於分割槽級別而具有縮放性,因此如果您有12個分割槽和2個匯出流,則總共將有24個匯出流。

記錄到達目的地的速度在很大程度上取決於您匯出的平臺- 例如,如果您寫入HDFS,與寫入資料庫伺服器上的CSV檔案相比,記錄將顯示更長時間。

匯出流也可以與物化檢視結合使用,因此您可以在保留有用的狀態摘要的同時向下遊寫入資訊,例如上次檢視客戶時。

從開發人員的角度來看,匯出流允許將任意訊息傳送到具有高效能,最小麻煩和ACID語義的下游系統。它還允許我們執行Translytics工作負載的關鍵“Telling”部分,因為如果您無法告訴任何人,那麼實時進行聚合計算毫無意義。

結論

“Translytics”不僅僅是OLTP的一個奇特名稱。它將OLTP系統的傳統和易於理解的功能與現代要求相結合,實時生成聚合和總計資料,從而滿足業務需求。傳統的RDBMS和NoSQL產品都很難很好地實現這一目標,而VoltDB具有重要的架構優勢。歡迎大家下載並檢視。


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69903219/viewspace-2636346/,如需轉載,請註明出處,否則將追究法律責任。

相關文章