哪篇論文宣佈了 HTAP 資料庫的誕生? | StoneDB學術分享會#5

語言: CN / TW / HK

本文是 StoneDB 學術分享會專欄的第五篇,我們來分享一下 HTAP 學術界上比較經典的一篇論文《A Common Database Approach for OLTP and OLAP Using an In-Memory Column DataBase》。
為什麼說這篇論文經典呢,因為這篇論文來自國際著名廠商,號稱歐洲最大的軟體公司 SAP(思愛普,截止發稿市值為 1283.17 億美元)的創始人 Hasso Plattner(哈索·普拉特納)教授,該文作為 Keynote 在 2009 年的資料庫國際頂會 SIGMOD 上正式釋出,可以說,這篇把 Michael Stonebraker 都氣到變臉的論文一經發表,就此掀開了 HTAP 資料庫的歷史序幕,也催生了後來都能和 Oracle 搶大筆生意的資料庫 SAP HANA。
HANA,全稱是 High Performance Analytic Appliance,是第一個全面支援 ACID 的事務型列式儲存(Colunm-Store)資料庫( 不要覺得很簡單哦,列式資料庫做到這樣很難的,StoneDB的研發們都深知其中的坑有多深:D ),也是第一個做 HTAP 的記憶體型(In-Memory)資料庫。接下來,就讓我們來一起學習一下這篇經典論文吧。

 

 

 

翻譯|王學姣

編輯|宇亭

審校|李浩、宇亭


A Common Database Approach for OLTP and OLAP Using In-Memory Column Database

作者:Hasso Plattner

 

 

一、簡介

二十多年以來,關係型資料庫系統一直是商業應用的支柱。我們曾許諾為企業提供涵蓋所有核心應用的管理資訊系統,包括財務、銷售、訂單履行、製造以及人力資源,從規劃到業務流程再到個性化分析。然而,我們並沒有實現這一目標。當業務需求變得越來越複雜,我們就越關注所謂的事務處理部分,並相應地設計資料庫結構。這類系統被稱為 聯機事務處理系統 (Online Transactional Processing,OLTP)。而出於靈活性和效能考慮,分析和財務規劃類應用開始逐漸則開始更多地移到單獨的系統中。這類系統被稱為 聯機分析處理系統 (Online Analytical Processing,OLAP)。實際上,部分規劃流程甚至被轉移到了主要圍繞電子表格的專用軟體上。

 

OLTP 和 OLAP 這兩類系統都基於關係理論,只是使用了不同的技術手段[13]。在 OLTP 系統中,元組(tuple)按行組織,行儲存在塊(block)中,而塊儲存在磁碟上也同時快取在資料庫伺服器的主記憶體(main memory)中。我們可以通過複雜的索引來實現快速訪問單個元組。但是,隨著請求的元組數量的增加,訪問速度將會變得越來越慢。相比之下,OLAP 系統中的資料以 Star Schema 組織。在這種結構下,可以藉助字典實現對屬性(列)的壓縮。

 

 

在將屬性轉換為整數後,處理速度得到了提升。最近一段時間,用列式儲存資料庫來處理分析查詢變得流行起來。在列式儲存中實現的資料庫級的字典壓縮和只讀取處理查詢所必需的列顯著地加快了查詢處理。

 

在我看來,資料倉庫的引入是一種妥協。在使用資料倉庫獲得靈活性和速度的同時,必須付出額外的成本用於提取和載入資料以及控制冗餘。許多年來,這種討論似乎已經結束,企業資料被拆分成 OLTP 和 OLAP 兩部分[9]。OLTP 是 OLAP 的必要先決條件,但是公司想要了解自身的業務,並得出如何為公司制定正確的路線,在何時需要改變路線的結論,則必須依靠 OLAP。當計劃資料和實際資料匹配時,業務就會變得透明,並且可以作為決策制定的依據。雖然集中式倉庫也能整合各種來源的資料,但是市場仍然希望能有這麼一個系統可以同時提供 OLTP 和 OLAP 能力,從而使得 OLTP 和 OLAP 能為使用者提供更大的價值。

在過去的 20 年裡,摩爾定律使我們能夠讓企業系統同時在功能和容量上實現增長[16]。當處理器時鐘速度在 2002 年達到 3 GHz 水平之後,進一步的發展似乎變得遙不可及。然而,兩項技術突破打破了這一困局:主記憶體實現了前所未有的增長;通過刀片計算和多核 CPU 實現的大規模並行處理[14]。雖然主記憶體在快取等場景中總是非常受歡迎且應用伺服器支援大量的 CPU,大規模並行處理卻並不是 OLTP 資料庫系統的理想應用場景,OLTP 資料庫系統仍然執行在對稱多處理(Symmetric Multi Processing,SMP)伺服器上。這樣做是因為在並行事務中更新多個表時會造成被更新的資料儲存段(Data Storage Segment)臨時上鎖並且有可能引發死鎖。這就是為什麼像 SAP 的 R/3 在一個執行緒中執行所有更新事務,並且嚴重依賴行鎖和 SMP 機器上並行資料庫程序之間的超快速通訊的主要原因。這些缺點中的一部分可以通過更好的應用設計來克服,並沒有對 OLTP 和 OLAP 的分離形成挑戰。

 

根據 SAP 和 HPI 對行存關係型記憶體資料庫進行的早期測試結果,也無法得出行存記憶體資料庫比擁有同等快取記憶體的領先 RDBMS 有明顯優勢的結論。基於上述背景,我們產生了另外一種想法來研究列存資料庫用於 OLTP 的優勢。列式儲存已經在 OLAP 領域成功使用了多年。在主記憶體變得充裕後,實現了爆發性增長[20,5]。

我們從兩年半前便在 HPI 開始分析在記憶體型列存資料庫上執行 OLTP 操作是否可行。這也成為了許多學士、碩士和博士專案的主題。在接下來的內容中,我想討論一下我們的發現。一些部分會對當前的普遍觀點發起挑戰,其他部分在討論未來發展的選擇。

二、列式儲存最適合現代 CPU

具有多核架構的現代 CPU 提供了巨大的計算能力。下一代刀鋒伺服器(編者注:刀鋒伺服器是指在標準高度的機架式機箱內可插裝多個卡式的伺服器單元,是一種實現HAHD(High Availability High Density,高可用高密度)的低成本伺服器平臺,為特殊應用行業和高密度計算環境專門設計。刀鋒伺服器就像“刀片”一樣,每一塊“刀片”實際上就是一塊系統主機板。單個刀片將擁有 8 個 16 核 CPU。這意味著單個刀片可以提供 128 個計算單元,近 500 GB 的主記憶體。為了優化這些計算裝置的使用,我們必須瞭解記憶體層次結構(memory hierarchy)、快取大小以及如何在一個程式中實現並行處理[6]。我們首先討論下記憶體。企業應用在很大程度上受限於記憶體,這意味著程式執行時長與讀寫操作所訪問的記憶體量或移動的記憶體量的變化成比例變化。

 

 

例如,我們比較了 SAP 的會計文件行專案表的全表掃描以便計算所有元組的總值。該表有 160 個屬性。我們對其中一家德國啤酒廠 5 年的會計資料進行了實驗,這個表中的元組數量為 3400 萬。在底層行存資料庫中,該表每 100 萬個元組的空間佔用量大約為 1 GB。

 

因此,該表的大小為 35 GB。而在列存資料庫中,該表所佔用的儲存空間僅為 8 GB,因為列式儲存可以對列進行更高效的壓縮。如果我們考慮到在實際應用中,一個 SQL 語句中通常只用得到一個表中的 1/10 的屬性(見圖 1),這意味著對於列式儲存來說,最多隻需要讀取 800 MB 的資料就可以生成最終的查詢結果[1]。圖 2(僅為示意圖)顯示,在面向集合(Set)的針對列的操作處理上,使用水平壓縮的行式儲存完全無法與列式儲存匹敵。即使有合適的索引,行式儲存需要訪問的資料量也要比列式儲存高出幾個數量級。

圖片

圖 1:查詢和 Schema 示例

圖片

圖 2:列式儲存和行式儲存中的資料訪問


根據我們對有客戶資料的真實系統的分析, 企業計算中的大多數應用實際上是以集合為單位的處理而不是單個元組訪問的。因此,將資料放在列式儲存中的好處非常明顯。 除此之外,我們可以基於行(row level)使用壓縮的整數格式執行大多數計算。我們在這裡看到,與在應用級別對非壓縮資料格式執行的相同計算相比,效能提高了 100 到 1000 倍。應用層必須在本地 SQL 語句中使用最少的預測,並避免在子例程中使用更通用的 SQL 語句來支撐對記憶體訪問的減少。


除了這些好處,並行處理的引入也功不可沒。根據 Hennessy 的說法,建立並行處理程式的難點在於如何將一個程式分解成大小相等的片段並通過少量同步對這些片段進行並行處理 [12] 。而單列或者多列掃描恰恰就是我們所尋求的解決方案。 這種掃描操作可以輕易地被等分為多個部分並分配給多個核心。 OLAP 引擎的標準操作和計算到期日、貨幣兌換、給定日期間隔的工作日等常規應用邏輯,例如, 可以由儲存過程對壓縮列的整數值進行操作來處理。


元組之間完全彼此獨立,所以元組級的所有計算都將自動並行處理。並且系統會對每一個符合條件的元組同步執行第一層級的聚合。核心程序之間的同步是最小的。沿著給定的層次結構(Hierarchy)進行的進一步聚合則是資料積累的第二步。這同樣適用於按屬性排序或按時間排序。


即使只有少數元組匹配選擇謂詞,也沒有必要引入索引,因為掃描的速度非常快,尤其是在多核並行處理活躍的情況下。 在當前的 CPU 上,預計每毫秒可以處理 1 MB 資料,而在 16 核 CPU 上每毫秒並行處理的資料量可超過 10 MB。據此我們可以判斷,尋找壓縮在 4 個位元組中的某單個維度,我們可以在 1 毫秒內掃描 250 萬個元組進行匹配。既然有了這個速度,我們甚至不再為大多數表提供主鍵索引,取而代之的是全列掃描。現代 CPU 可以使用所有關係代數,而不會有效能上的缺點。列式儲存非常適合現代 CPU。值得注意的是,現在每個屬性都代表一個潛在的索引。對於應用而言,則不再受限於預定義的導航路徑進行資料選擇了。將大部分計算委託給資料庫層減輕了應用層的計算壓力,使應用層工作更加聚焦。這有利於開發出更高質量的程式,併為持續開發提供了更優的生命週期。硬碟僅儲存用於快速恢復的事務日誌和快照。事實上,磁碟和磁帶一樣,早已成為明日黃花 [11]

 

 

三、我們的主張:列式儲存適合於更新密集型應用

很多人認為列式儲存處理更新操作的成本很高 [8] 。雖然將所有資料放在主記憶體中可以極大地提高列式儲存的更新效能,我們仍然必須考慮屬性字典的潛在擴充套件性,這可能會導致壓縮需要重新計算,從而對整個列造成影響。因此,我們對金融系統中的更新進行了更為詳盡的分析(如圖 3 所示)。

圖片

圖 3 :金融系統的 Schema (現狀)

 

3.1 SAP 資料庫表設計的歷史

乍一看,這麼大量的物化檢視和物化聚合(Materialized Aggregate)可能令人吃驚。但是這種冗餘對於在可接受響應時間內顯示行專案和賬戶總數是非常必要的。實現這種冗餘會引入更多的插入和有問題的冗餘資料更新(使用資料庫觸發器或過程程式碼造成的)。不過這些代價都是必要的。在系統的 OLAP 部分,由客戶定義的 Cube 組合允許以合理的響應時間進行靈活的報告,但增加了複雜性和額外的系統管理開銷。

 

3.2 客戶資料分析

在分析 4 個不同的 SAP 客戶的變更日誌時,我們發現更新主要可以分為以下三種:

 

    • 聚合更新(Aggregate Update) :屬性被視作物化檢視一部分的累積值(每個會計行專案在 1 到 5 之間)。
    • 狀態更新(Status Update) :狀態變數的二進位制變化,通常帶有時間戳。
    • 值更新(Value Update) :屬性的值通過替換而改變。

 

3.2.1 聚合更新

大多數聚合更新發生在那些應用於遵循編碼快結構的總記錄的金融應用中。編碼塊包含賬號、法律組織、年份等資訊。這些總記錄基本上是日誌條目的物化檢視,以便在請求聚合時加速響應。由於引入基於列式儲存的資料倉庫 [18] (例如,SAP Business Warehouse Explorer)後,多維 Cube 的彙總不在符合當下需求,因此我們分析了是否可以通過演算法建立聚合,並始終保持動態。請求的聚合例項越多,列式儲存的相對效能就越好(見圖 4)。聚合的建立與全列掃描相對應,因此響應集(Response Set)中的聚合數量對響應時間幾乎沒有影響。在行式儲存中,響應時間隨著讀取的聚合數量線性增加。

 

圖片

圖 4:即時聚合 VS 物化檢視讀取

 

3.2.2  狀態更新

狀態變數(如未支付、已支付)通常使用一組預定義的值,因此在執行就地更新時不會產生問題,因為變數的基數不會改變。建議不要對狀態欄位進行列的序列壓縮。如果應用更傾向於自動記錄狀態變化,我們也可以對這些變化使用僅插入(Insert-Only)的方法,這一點我們將在 3.2.2 節中進行討論。如果狀態變數只有兩個值,那麼最好的選擇是一個空值(Null Value)和一個時間戳。即使針對基於時間的查詢,就地更新也是完全透明的。

 

3.2.3  值更新

由於在大多數情況下,企業應用中的屬性更改都必須記錄到日誌中,所以 Insert-Only 看起來是個恰當的方式。 圖 5 顯示,在很長一段時間內,一個金融系統中平均只有 5% 的元組發生了實際變化。增量管理器的額外負載和主記憶體的額外消耗是可以接受的。增量管理器是用於處理更新和插入的列式儲存資料庫中的寫優化儲存。資料只插入到增量儲存中。增量儲存中的字典不會被排序,而是保持插入的順序。使用 Insert-Only,我們還可以捕獲變更歷史,包括變更的時間和來源。

 

圖片

圖 5:會計更新頻率

 

儘管事實上典型的企業系統並不是真正的更新密集型,但是通過使用 Insert-Only 和不維護總數,我們甚至可以減少這些更新。因為更新變少了,所以鎖問題也減少了,並且表可以更容易地通過 Shared-Nothing 方法在獨立的計算單元(刀片)之間實現水平分佈(分割槽)[19]。基本上消除了更新之後,我們現在只需要考慮插入和讀取。下一節將討論如何區分元組的最新表示和舊版本,以及如何維護讀取和更新之間的併發性。
 

根據對金融系統的這些推薦修改,主要表格的數量將從 18 個以上降至 2 個(不包括變更歷史、指數和 OLAP Cube),如圖 6 所示。我們只在表格中保留會計文件——標題和行專案。在檔案上執行的 Insert-Only 方法和計算演算法會替換所有索引、物化檢視和更改歷史。

 

圖片

圖 6:簡化後的金融系統(目標)

 

四、 Insert-Only 的後果


Insert-Only 會對應用和資料庫級別的加鎖處理方式產生影響。

 

4.1 應用級鎖

許多業務事務同時處理幾個關係表和一個表的多個元組。應用程式在物件中“思考”,物件是建立在關係模型之上的一層。儘管我們可以用我們獨有的資料庫鎖處理大多數併發情況,但我們必須在物件(應用)層級引入一個共享鎖(Shared Lock)。例如,應用物件 customer 轉換成多達 15 個數據庫表。客戶物件的變化可以包括銀行資訊、送貨地址等。為了保持一致性,一次只能有一個事務更改該特定物件。另一個例子是應付賬款或應收賬款中未清專案的對賬。多個未清專案將在一次交易中標記為已支付。鎖沒有加在會計行專案表上,而是加在物件 creditor 或 debitor 上。這些應用級鎖是使用記憶體中的資料結構實現的。

 

4.2 資料庫鎖

利用 Insert-Only,除了二進位制狀態變數之外,可以消除應用對元組的更新。在資料庫中擁有同一個元組的多個版本需要將較舊的版本標記為不再有效。每個插入的元組都帶有它的建立時間戳,如果該元組更新了,還會帶有更新的時間戳。只有元組的最新版本沒有更新時間戳,因此很容易識別出來。這個概念的好處是,可以通過使用關於查詢的基準日期的兩個時間戳來重建元組的任何狀態。這種方法在1987年時已經被 POSTGRES 採用[21],稱為“時間旅行”。擴充套件 SQL 必須支援基準日期引數,通過該引數可以識別元組的有效版本。

 

在同一個表中攜帶元組的所有舊版本具有顯著的應用優勢,尤其是在檢索舊版本資料是常見操作的規劃應用中[7]。除此之外,它完全消除了單獨建立變更日誌的必要性。其帶來的額外儲存容量要求可以忽略不計。

 

時間戳屬性不參與任何壓縮演算法,因此在更新時不會導致列的任何重組。因為多個查詢可能與插入和更新同時發生,所以必須非常小心地避免在表、列或字典級別的過多鎖定。

 

現在我們來看看插入。插入的資料被新增至表中恰當的分割槽中的增量儲存內。查詢開始時的時間戳定義了哪些元組是有效的(只有時間戳更早的元組)。萬一插入操作正在進行中,新查詢的開始時間戳將會被設定為插入事務的時間戳減1,並且正在進行的插入將再次被忽略。此過程相當於通過時間戳實現的快照隔離[15,3]

 

在當前的研究系統中,我們觀察到當多個查詢同時執行時,每次插入的時間都會顯著增加。我們認為這是一個實現問題,因為在過去,只讀應用的設計目標是實現壓縮最大化。因為插入被作為增量儲存的追加實現,從而不需要排他鎖。如果一個事務包括多個插入,則適用和插入/更新相同的邏輯。所有併發執行的查詢將通過時間戳比較看到一致的快照。

 

未來的研究將會特別關注併發性和鎖問題。作為一般規則,資料庫系統應該以最大速度執行每個任務,即使會佔用所有資源(例如 CPU 核)以避免潛在的衝突和管理開銷的增加。

 

與之前的插入一樣,後續所有的針對改變後的元組的插入都帶有一個全域性唯一的使用者識別符號。與時間戳一起,提供了完整的更改歷史。

 

擁有表中元組的完整歷史意味著開發事實隨著時間演變(Evolution of Facts Over Time)的表示。一個例子是與外部事件相關的一個季度內每天的銷售預測的演變,從而可以更好地瞭解趨勢並改進推斷(圖 7)。儘管應用對滑塊的每次增量移動都要進行全表掃描(見虛線),使用者體驗類似於在 Microsoft Word 中使用滾動條。

圖片

 

五、就記憶體消耗而言,列式儲存優於行式儲存

在為 OLTP 和 OLAP 構建一個組合系統的假設下,資料必須針對集合處理、快速插入、最大(讀取)併發性和重組的低影響進行組織。這限制了行式儲存和列式儲存的壓縮程度。雖然在行式儲存中實現與列式儲存相同程度的壓縮是可能的(例如 IBM 的 Blink 引擎[17]),但是要將行式儲存和列式儲存作比較的戶啊,必須要在滿足上述要求(尤其是快速插入)的情況下進行才客觀,這就將只讀行式儲存排除在討論之外了。

 

在列式儲存中,通過屬性值的轉換和完全消除只有空值的列進行壓縮是非常高效的,但在本研究系統中可以通過將值解釋為:所有字元空白,所有字元零,以及小數點零作為空值來改進。應用考慮預設值,不能正確處理空值。通過在進入資料庫的過程中自動將預設值轉換為空值,並在輸出的過程中轉換回預設值。

 

當我們比較列式儲存和行式儲存中的表對記憶體的要求,二者的壓縮比存在著明顯差異。對現有客戶資料的各種分析顯示,在磁碟上,列式儲存的典型壓縮率為 20%,而寫優化的行式儲存的壓縮率為 2%。為了進一步得出記憶體消耗估計,我們使用了有利於列式儲存的壓縮使用因子 10。正如在另一章中所討論的,列式儲存允許我們消除所有物化檢視(聚合),並且在需要的時候可以根據演算法計算出來。與這些聚合相關的儲存要求隨應用的不同而變化。通常在 OLAP 系統中用於物化彙總的多維 Cube 隨著個體維度的基數而增長。因此,基於消除冗餘聚合的有利於列式儲存的因子 2 是一個保守估計值。

 

將基於時間和租戶使用表的水平分割槽。為了將不同質量的和處理器速度用於特定維度,劃分為多個維度的選項非常有用。在討論記憶體消耗時,將表分為每年的當前資料和歷史資料的選項非常有意思。對客戶資料的分析表明,通常 5-10 年的歷史資料(不允許更改)會儲存在運營資料庫中。

 

歷史資料可以保持可訪問性,不過需要存放在更便宜、更慢的儲存介質上(快閃記憶體或磁碟)。當前資料加上上一年完成的資料應儲存在刀片式伺服器的 DRAM 記憶體中,以便在企業系統中進行典型的年度對比。對於按時間的分離,我們使用兩個時間戳,即建立時間和完成時間。完成時間由應用邏輯控制,例如訂單處理完畢或發票支付完畢。完成日期決定了資料成為歷史資料的年份,這意味著不可能進行進一步的更改。關於主記憶體需求,我們可以考慮有利於列式儲存的因子 5。公平地講,水平分割槽也可以在記錄儲存中實現。如果當前和上一年分割槽的剩餘表大小仍然很大,資料庫管理可能會進行水平分割槽。忽略索引和維度字典的記憶體需求,我們可以假設儲存容量減少了 10 x 2 x 5 倍(從磁碟到主記憶體)。刀鋒伺服器中使用的下一代主機板會提供大約 500 GB 的主記憶體,甚至更多。由於 100 個刀片的陣列已經上市,OLTP 和 OLAP 容量高達 50 TB 的安裝可以轉換為 DRAM 上的純記憶體系統。就儲存容量而言,這涵蓋了大多數客戶,例如 SAP 的業務套件客戶。

六、典型的資料輸入事務會發生什麼?

資料輸入事務由三部分組成:使用者資料輸入、資料驗證和資料庫更新。大多數資料驗證保持不變。事實上,只有作為索引執行的屬性才能幫助提高驗證的質量,例如檢查客戶、供應商、零件條目是否重複或收到的發票是否重複。資料庫更新被減少到僅僅是一個插入操作。沒有索引(不管是一級還是二級)需要維護,且客戶訂單、股票變動等日誌條目不會產生聚合更新。因此,事務資料輸入的吞吐量將會提高。增量管理器處理新元組的初始插入。

 

增量儲存再次被組織為列式儲存。由於資料檢索和插入會相互影響,因此在實現時必須格外小心,以避免不必要的鎖定。對於分割槽表中的插入,尤其如此。為了減少插入對字典表的影響,並減少增量儲存和主儲存之間的合併操作的影響,增量儲存的兩層組織是目前正在研究的概念。因此,研究和開發的重點從最大限度地壓縮資料轉移到在其他同時執行的查詢上以最小的影響進行高速插入。

 

七、對應用開發的影響

基於使用列式儲存的關係型資料庫的應用應該使用關係代數和擴充套件的 SQL 特性,將盡可能多的邏輯委託給資料庫級和儲存過程。在重寫現有應用時,我們希望減少 30% 以上的程式碼量(在金融等更正式的應用中,我們希望這一數字達到 40-50%)。使用列儲存的全索引特性,許多部分可以完全重構。在理想情況下,應用只需要為一個演算法設定引數,而這個演算法僅由擴充套件 SQL(作為儲存過程)定義且在資料庫級別進行執行。然後,應用對結果集進行處理,產生輸出(螢幕、電子郵件、列印、電話等)。如前所述,建議嚴格使用最小投影。資料庫的高效能使得應用級別的資料快取非常流暢。

 

在多個維度(租戶、時間、主鍵範圍等)對錶進行分割槽表的支援有助於為更大的表實現最短的響應時間。由於除了 100 位元組的 Stub 之外,尚未填充的列不佔用任何儲存空間,因此向現有表新增新列變得十分簡單。

 

為了驗證我們的發現,一個研究團隊開始基於 SAP 的按需系統 ByDesign,為應收賬款、應付賬款、總賬和成本會計(包括規劃)建立下一代會計系統。所有使用者互動、配置等都相同,以便進行完整的平行測試。

 

日記賬分錄表只有一個索引,即會計憑證號(加上行專案號)。沒有將日記帳分錄與帳戶(借方、貸方、G/L或成本中心等)聯絡起來的索引存在。唯一更新的屬性是:建立、失效和協調時間戳。所有其他更改都會導致插入已更改的條目,並使舊條目無效。

 

沒有實體化檢視形式的聚合,相反,它們將通過實時演算法建立。資料輸入速度提高了,因為只有兩個表(單據標題、單據行專案別名日記帳分錄)接收插入。事務的簡單性允許重新考慮前向恢復方法,而不是退出失敗的事務。

 

會計資料的每一種表示都可以定義為電子表格,識別賬戶、它們的層次結構(集合)、要計算的值(集合)。在翻譯成擴充套件 SQL 後,可以驗證語句的正確性,並且假設 SQL 處理器工作正常,不需要進一步測試。應用程式可以完全專注於使用者互動和資訊呈現。在第二階段,一個包括商業專家在內的研究專案將關注響應時間接近於零的全索引資料庫的潛力。

 

不僅消除了冗餘表,還消除了系統的 OLTP 和 OLAP 部分之間的更新過程或 ETL 過程形式的冗餘表維護。

 

八、SaaS 應用中的列式儲存

針對 SaaS(軟體即服務)應用中,列式儲存的在以下幾個方面有優勢:未使用的列僅由 Stub 表示。向表中引入新屬性意味著更新元資料併為列建立 Stub[2]。然後應用便可以使用這些屬性。對於正在進行的應用開發來說,這是一個重要的特性,且該特性不會對使用者造成任何干擾。與外部資料的連線在匯入到主機系統後儲存在列式儲存中,即使對於非常大的表(訪問的最小主存),這也是非常高效的。在這兩種情況下,響應時間將大大得到縮短。

 

現在,應用不僅可以確定查詢的基準日期,還可以監控單個元組內容(屬性)的發展(例如,客戶訂單的生命週期、人力資源或應付賬款中敏感資料的控制)。

 

九、後續研究

我們後續的研究方向集中在為 OLTP 和 OLAP 混合負載系統建立一個基準,該基準將基於真實的客戶系統和資料[4]、記憶體型列式儲存資料庫的多租戶以及圍繞增量合併過程的優化。

我們今後研究的重點方向為:

  • 災難恢復

  • TCO:當前版本的 SAP 按需會計系統與基於列式儲存的版本之間的總擁有成本(Total Cost of Ownership,TCO)比較,包括能耗

  • 非結構化資料模型的擴充套件

  • 基於生命週期的資料管理基於不同應用的語義,可以指定單個記錄是否支援再次修改,或是保持只讀模式從而允許不同的壓縮和分割槽策略。

  • 垂直分割槽:在企業應用中,單個表中的塊傾向於按照他們的訪問模式組合在一起。使用垂直分割槽方法可以在讀取這些組的內容時提高效能。


十、結論和展望

過去兩年半中獲得的經驗鼓勵我們為更大的公司企業系統(例如,每年多達 1 億次銷售活動)進行設想,其中所有的業務交易、查詢,包括無限聚合和基於時間的序列,都可以在幾秒鐘內得到結果(包括成本驚人的表示層,presentation layer)。我們預計列式儲存的發展將會對企業管理產生翻天覆地的影響,就像當初網際網路搜尋引擎顛覆了我們的生活一樣。圖 8 描繪了一個未來的管理會議,您想要的資訊,動動手指就能搞定[10]

 

圖片

 

圖 8:未來的管理會議

StoneDB開源地址:https://github.com/stoneatom/stonedb

深度乾貨!一篇Paper帶您讀懂 HTAP

解讀《Benchmarking Hybrid OLTP&OLAP Database Systems》

爆肝整理 5000字!HTAP 的關鍵技術有哪些?

如何給一個 HTAP 資料庫做基準測試?