本文是 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 萬個元組進行匹配。既然有了這個速度，我們甚至不再為大多數表提供主鍵索引，取而代之的是全列掃描?，F代 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 個數據庫表?？蛻魧ο蟮淖兓梢园ㄣy行信息、送貨地址等。為了保持一致性，一次只能有一個事務更改該特定對象。另一個例子是應付賬款或應收賬款中未清項目的對賬。多個未清項目將在一次交易中標記為已支付。鎖沒有加在會計行項目表上，而是加在對象 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 構建一個組合系統的假設下，數據必須針對集合處理、快速插入、最大（讀?。┎l性和重組的低影響進行組織。這限制了行式存儲和列式存儲的壓縮程度。雖然在行式存儲中實現與列式存儲相同程度的壓縮是可能的（例如 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 數據庫做基準測試？