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

最近，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具有重要的架構優勢。歡迎大家下載並檢視。