本文是 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：未來的管理會議