本文是?StoneDB 學(xué)術(shù)分享會(huì)專欄的第五篇，我們來分享一下 HTAP 學(xué)術(shù)界上比較經(jīng)典的一篇論文《A Common Database Approach for OLTP and OLAP Using an In-Memory Column DataBase》。
為什么說這篇論文經(jīng)典呢，因?yàn)檫@篇論文來自國際著名廠商，號(hào)稱歐洲最大的軟件公司 SAP（思愛普，截止發(fā)稿市值為 1283.17 億美元）的創(chuàng)始人 Hasso Plattner（哈索·普拉特納）教授，該文作為 Keynote 在 2009 年的數(shù)據(jù)庫國際頂會(huì) SIGMOD 上正式發(fā)布，可以說，這篇把 Michael Stonebraker 都?xì)獾阶兡樀恼撐囊唤?jīng)發(fā)表，就此掀開了 HTAP 數(shù)據(jù)庫的歷史序幕，也催生了后來都能和 Oracle 搶大筆生意的數(shù)據(jù)庫 SAP HANA。
HANA，全稱是?High Performance Analytic?Appliance，是第一個(gè)全面支持?ACID 的事務(wù)型列式存儲(chǔ)（Colunm-Store）數(shù)據(jù)庫（不要覺得很簡單哦，列式數(shù)據(jù)庫做到這樣很難的，StoneDB的研發(fā)們都深知其中的坑有多深:D），也是第一個(gè)做 HTAP 的內(nèi)存型（In-Memory）數(shù)據(jù)庫。接下來，就讓我們來一起學(xué)習(xí)一下這篇經(jīng)典論文吧。

翻譯｜王學(xué)姣

編輯｜宇亭

審校｜李浩、宇亭

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

作者：Hasso Plattner

一、簡介

二十多年以來，關(guān)系型數(shù)據(jù)庫系統(tǒng)一直是商業(yè)應(yīng)用的支柱。我們曾許諾為企業(yè)提供涵蓋所有核心應(yīng)用的管理信息系統(tǒng)，包括財(cái)務(wù)、銷售、訂單履行、制造以及人力資源，從規(guī)劃到業(yè)務(wù)流程再到個(gè)性化分析。然而，我們并沒有實(shí)現(xiàn)這一目標(biāo)。當(dāng)業(yè)務(wù)需求變得越來越復(fù)雜，我們就越關(guān)注所謂的事務(wù)處理部分，并相應(yīng)地設(shè)計(jì)數(shù)據(jù)庫結(jié)構(gòu)。這類系統(tǒng)被稱為聯(lián)機(jī)事務(wù)處理系統(tǒng)（Online Transactional Processing，OLTP）。而出于靈活性和性能考慮，分析和財(cái)務(wù)規(guī)劃類應(yīng)用開始逐漸則開始更多地移到單獨(dú)的系統(tǒng)中。這類系統(tǒng)被稱為聯(lián)機(jī)分析處理系統(tǒng)（Online Analytical Processing，OLAP）。實(shí)際上，部分規(guī)劃流程甚至被轉(zhuǎn)移到了主要圍繞電子表格的專用軟件上。

OLTP 和 OLAP 這兩類系統(tǒng)都基于關(guān)系理論，只是使用了不同的技術(shù)手段[13]。在 OLTP 系統(tǒng)中，元組（tuple）按行組織，行存儲(chǔ)在塊（block）中，而塊存儲(chǔ)在磁盤上也同時(shí)緩存在數(shù)據(jù)庫服務(wù)器的主內(nèi)存（main memory）中。我們可以通過復(fù)雜的索引來實(shí)現(xiàn)快速訪問單個(gè)元組。但是，隨著請求的元組數(shù)量的增加，訪問速度將會(huì)變得越來越慢。相比之下，OLAP 系統(tǒng)中的數(shù)據(jù)以 Star Schema 組織。在這種結(jié)構(gòu)下，可以借助字典實(shí)現(xiàn)對屬性（列）的壓縮。

在將屬性轉(zhuǎn)換為整數(shù)后，處理速度得到了提升。最近一段時(shí)間，用列式存儲(chǔ)數(shù)據(jù)庫來處理分析查詢變得流行起來。在列式存儲(chǔ)中實(shí)現(xiàn)的數(shù)據(jù)庫級的字典壓縮和只讀取處理查詢所必需的列顯著地加快了查詢處理。

在我看來，數(shù)據(jù)倉庫的引入是一種妥協(xié)。在使用數(shù)據(jù)倉庫獲得靈活性和速度的同時(shí)，必須付出額外的成本用于提取和加載數(shù)據(jù)以及控制冗余。許多年來，這種討論似乎已經(jīng)結(jié)束，企業(yè)數(shù)據(jù)被拆分成 OLTP 和 OLAP 兩部分[9]。OLTP 是 OLAP 的必要先決條件，但是公司想要了解自身的業(yè)務(wù)，并得出如何為公司制定正確的路線，在何時(shí)需要改變路線的結(jié)論，則必須依靠 OLAP。當(dāng)計(jì)劃數(shù)據(jù)和實(shí)際數(shù)據(jù)匹配時(shí)，業(yè)務(wù)就會(huì)變得透明，并且可以作為決策制定的依據(jù)。雖然集中式倉庫也能集成各種來源的數(shù)據(jù)，但是市場仍然希望能有這么一個(gè)系統(tǒng)可以同時(shí)提供 OLTP 和 OLAP 能力，從而使得 OLTP 和 OLAP 能為用戶提供更大的價(jià)值。

在過去的 20 年里，摩爾定律使我們能夠讓企業(yè)系統(tǒng)同時(shí)在功能和容量上實(shí)現(xiàn)增長[16]。當(dāng)處理器時(shí)鐘速度在 2002 年達(dá)到 3 GHz 水平之后，進(jìn)一步的發(fā)展似乎變得遙不可及。然而，兩項(xiàng)技術(shù)突破打破了這一困局：主內(nèi)存實(shí)現(xiàn)了前所未有的增長；通過刀片計(jì)算和多核 CPU 實(shí)現(xiàn)的大規(guī)模并行處理[14]。雖然主內(nèi)存在緩存等場景中總是非常受歡迎且應(yīng)用服務(wù)器支持大量的 CPU，大規(guī)模并行處理卻并不是 OLTP 數(shù)據(jù)庫系統(tǒng)的理想應(yīng)用場景，OLTP 數(shù)據(jù)庫系統(tǒng)仍然運(yùn)行在對稱多處理（Symmetric Multi Processing，SMP）服務(wù)器上。這樣做是因?yàn)樵诓⑿惺聞?wù)中更新多個(gè)表時(shí)會(huì)造成被更新的數(shù)據(jù)存儲(chǔ)段（Data Storage Segment）臨時(shí)上鎖并且有可能引發(fā)死鎖。這就是為什么像 SAP 的 R/3 在一個(gè)線程中運(yùn)行所有更新事務(wù)，并且嚴(yán)重依賴行鎖和 SMP 機(jī)器上并行數(shù)據(jù)庫進(jìn)程之間的超快速通信的主要原因。這些缺點(diǎn)中的一部分可以通過更好的應(yīng)用設(shè)計(jì)來克服，并沒有對 OLTP 和 OLAP 的分離形成挑戰(zhàn)。

根據(jù) SAP 和 HPI 對行存關(guān)系型內(nèi)存數(shù)據(jù)庫進(jìn)行的早期測試結(jié)果，也無法得出行存內(nèi)存數(shù)據(jù)庫比擁有同等緩存內(nèi)存的領(lǐng)先 RDBMS 有明顯優(yōu)勢的結(jié)論。基于上述背景，我們產(chǎn)生了另外一種想法來研究列存數(shù)據(jù)庫用于 OLTP 的優(yōu)勢。列式存儲(chǔ)已經(jīng)在 OLAP 領(lǐng)域成功使用了多年。在主內(nèi)存變得充裕后，實(shí)現(xiàn)了爆發(fā)性增長[20，5]。

我們從兩年半前便在 HPI 開始分析在內(nèi)存型列存數(shù)據(jù)庫上執(zhí)行 OLTP 操作是否可行。這也成為了許多學(xué)士、碩士和博士項(xiàng)目的主題。在接下來的內(nèi)容中，我想討論一下我們的發(fā)現(xiàn)。一些部分會(huì)對當(dāng)前的普遍觀點(diǎn)發(fā)起挑戰(zhàn)，其他部分在討論未來發(fā)展的選擇。

二、列式存儲(chǔ)最適合現(xiàn)代 CPU

具有多核架構(gòu)的現(xiàn)代 CPU 提供了巨大的計(jì)算能力。下一代刀片服務(wù)器（編者注：刀片服務(wù)器是指在標(biāo)準(zhǔn)高度的機(jī)架式機(jī)箱內(nèi)可插裝多個(gè)卡式的服務(wù)器單元，是一種實(shí)現(xiàn)HAHD(High Availability High Density，高可用高密度)的低成本服務(wù)器平臺(tái)，為特殊應(yīng)用行業(yè)和高密度計(jì)算環(huán)境專門設(shè)計(jì)。刀片服務(wù)器就像“刀片”一樣，每一塊“刀片”實(shí)際上就是一塊系統(tǒng)主板。）單個(gè)刀片將擁有 8 個(gè) 16 核 CPU。這意味著單個(gè)刀片可以提供 128 個(gè)計(jì)算單元，近 500 GB 的主內(nèi)存。為了優(yōu)化這些計(jì)算設(shè)備的使用，我們必須了解內(nèi)存層次結(jié)構(gòu)（memory hierarchy）、緩存大小以及如何在一個(gè)程序中實(shí)現(xiàn)并行處理[6]。我們首先討論下內(nèi)存。企業(yè)應(yīng)用在很大程度上受限于內(nèi)存，這意味著程序執(zhí)行時(shí)長與讀寫操作所訪問的內(nèi)存量或移動(dòng)的內(nèi)存量的變化成比例變化。

例如，我們比較了 SAP 的會(huì)計(jì)文檔行項(xiàng)目表的全表掃描以便計(jì)算所有元組的總值。該表有 160 個(gè)屬性。我們對其中一家德國啤酒廠 5 年的會(huì)計(jì)數(shù)據(jù)進(jìn)行了實(shí)驗(yàn)，這個(gè)表中的元組數(shù)量為 3400 萬。在底層行存數(shù)據(jù)庫中，該表每 100 萬個(gè)元組的空間占用量大約為 1 GB。

因此，該表的大小為 35 GB。而在列存數(shù)據(jù)庫中，該表所占用的存儲(chǔ)空間僅為 8 GB，因?yàn)榱惺酱鎯?chǔ)可以對列進(jìn)行更高效的壓縮。如果我們考慮到在實(shí)際應(yīng)用中，一個(gè) SQL 語句中通常只用得到一個(gè)表中的 1/10 的屬性（見圖 1），這意味著對于列式存儲(chǔ)來說，最多只需要讀取 800 MB 的數(shù)據(jù)就可以生成最終的查詢結(jié)果[1]。圖 2（僅為示意圖）顯示，在面向集合（Set）的針對列的操作處理上，使用水平壓縮的行式存儲(chǔ)完全無法與列式存儲(chǔ)匹敵。即使有合適的索引，行式存儲(chǔ)需要訪問的數(shù)據(jù)量也要比列式存儲(chǔ)高出幾個(gè)數(shù)量級。

圖 1：查詢和 Schema 示例

圖 2：列式存儲(chǔ)和行式存儲(chǔ)中的數(shù)據(jù)訪問

根據(jù)我們對有客戶數(shù)據(jù)的真實(shí)系統(tǒng)的分析，企業(yè)計(jì)算中的大多數(shù)應(yīng)用實(shí)際上是以集合為單位的處理而不是單個(gè)元組訪問的。因此，將數(shù)據(jù)放在列式存儲(chǔ)中的好處非常明顯。除此之外，我們可以基于行（row level）使用壓縮的整數(shù)格式執(zhí)行大多數(shù)計(jì)算。我們在這里看到，與在應(yīng)用級別對非壓縮數(shù)據(jù)格式執(zhí)行的相同計(jì)算相比，性能提高了 100 到 1000 倍。應(yīng)用層必須在本地 SQL 語句中使用最少的預(yù)測，并避免在子例程中使用更通用的 SQL 語句來支撐對內(nèi)存訪問的減少。
除了這些好處，并行處理的引入也功不可沒。根據(jù) Hennessy 的說法，創(chuàng)建并行處理程序的難點(diǎn)在于如何將一個(gè)程序分解成大小相等的片段并通過少量同步對這些片段進(jìn)行并行處理[12]。而單列或者多列掃描恰恰就是我們所尋求的解決方案。這種掃描操作可以輕易地被等分為多個(gè)部分并分配給多個(gè)內(nèi)核。OLAP 引擎的標(biāo)準(zhǔn)操作和計(jì)算到期日、貨幣兌換、給定日期間隔的工作日等常規(guī)應(yīng)用邏輯，例如，可以由存儲(chǔ)過程對壓縮列的整數(shù)值進(jìn)行操作來處理。
元組之間完全彼此獨(dú)立，所以元組級的所有計(jì)算都將自動(dòng)并行處理。并且系統(tǒng)會(huì)對每一個(gè)符合條件的元組同步執(zhí)行第一層級的聚合。核心進(jìn)程之間的同步是最小的。沿著給定的層次結(jié)構(gòu)（Hierarchy）進(jìn)行的進(jìn)一步聚合則是數(shù)據(jù)積累的第二步。這同樣適用于按屬性排序或按時(shí)間排序。
即使只有少數(shù)元組匹配選擇謂詞，也沒有必要引入索引，因?yàn)閽呙璧乃俣确浅？?，尤其是在多核并行處理活躍的情況下。在當(dāng)前的 CPU 上，預(yù)計(jì)每毫秒可以處理 1 MB 數(shù)據(jù)，而在 16 核 CPU 上每毫秒并行處理的數(shù)據(jù)量可超過 10 MB。據(jù)此我們可以判斷，尋找壓縮在 4 個(gè)字節(jié)中的某單個(gè)維度，我們可以在 1 毫秒內(nèi)掃描 250 萬個(gè)元組進(jìn)行匹配。既然有了這個(gè)速度，我們甚至不再為大多數(shù)表提供主鍵索引，取而代之的是全列掃描。現(xiàn)代 CPU 可以使用所有關(guān)系代數(shù)，而不會(huì)有性能上的缺點(diǎn)。列式存儲(chǔ)非常適合現(xiàn)代 CPU。值得注意的是，現(xiàn)在每個(gè)屬性都代表一個(gè)潛在的索引。對于應(yīng)用而言，則不再受限于預(yù)定義的導(dǎo)航路徑進(jìn)行數(shù)據(jù)選擇了。將大部分計(jì)算委托給數(shù)據(jù)庫層減輕了應(yīng)用層的計(jì)算壓力，使應(yīng)用層工作更加聚焦。這有利于開發(fā)出更高質(zhì)量的程序，并為持續(xù)開發(fā)提供了更優(yōu)的生命周期。硬盤僅存儲(chǔ)用于快速恢復(fù)的事務(wù)日志和快照。事實(shí)上，磁盤和磁帶一樣，早已成為明日黃花[11]。

三、我們的主張：列式存儲(chǔ)適合于更新密集型應(yīng)用

很多人認(rèn)為列式存儲(chǔ)處理更新操作的成本很高[8]。雖然將所有數(shù)據(jù)放在主內(nèi)存中可以極大地提高列式存儲(chǔ)的更新性能，我們?nèi)匀槐仨毧紤]屬性字典的潛在擴(kuò)展性，這可能會(huì)導(dǎo)致壓縮需要重新計(jì)算，從而對整個(gè)列造成影響。因此，我們對金融系統(tǒng)中的更新進(jìn)行了更為詳盡的分析（如圖 3 所示）。

圖 3：金融系統(tǒng)的 Schema （現(xiàn)狀）

3.1 SAP 數(shù)據(jù)庫表設(shè)計(jì)的歷史

乍一看，這么大量的物化視圖和物化聚合（Materialized Aggregate）可能令人吃驚。但是這種冗余對于在可接受響應(yīng)時(shí)間內(nèi)顯示行項(xiàng)目和賬戶總數(shù)是非常必要的。實(shí)現(xiàn)這種冗余會(huì)引入更多的插入和有問題的冗余數(shù)據(jù)更新（使用數(shù)據(jù)庫觸發(fā)器或過程代碼造成的）。不過這些代價(jià)都是必要的。在系統(tǒng)的 OLAP 部分，由客戶定義的 Cube 組合允許以合理的響應(yīng)時(shí)間進(jìn)行靈活的報(bào)告，但增加了復(fù)雜性和額外的系統(tǒng)管理開銷。

3.2 客戶數(shù)據(jù)分析

在分析 4 個(gè)不同的 SAP 客戶的變更日志時(shí)，我們發(fā)現(xiàn)更新主要可以分為以下三種：

• 聚合更新（Aggregate Update）：屬性被視作物化視圖一部分的累積值（每個(gè)會(huì)計(jì)行項(xiàng)目在 1 到 5 之間）。

• 狀態(tài)更新（Status Update）：狀態(tài)變量的二進(jìn)制變化，通常帶有時(shí)間戳。

• 值更新（Value Update）：屬性的值通過替換而改變。

3.2.1 聚合更新

大多數(shù)聚合更新發(fā)生在那些應(yīng)用于遵循編碼快結(jié)構(gòu)的總記錄的金融應(yīng)用中。編碼塊包含賬號(hào)、法律組織、年份等信息。這些總記錄基本上是日志條目的物化視圖，以便在請求聚合時(shí)加速響應(yīng)。由于引入基于列式存儲(chǔ)的數(shù)據(jù)倉庫[18]（例如，SAP Business Warehouse Explorer）后，多維 Cube 的匯總不在符合當(dāng)下需求，因此我們分析了是否可以通過算法創(chuàng)建聚合，并始終保持動(dòng)態(tài)。請求的聚合實(shí)例越多，列式存儲(chǔ)的相對性能就越好（見圖 4）。聚合的創(chuàng)建與全列掃描相對應(yīng)，因此響應(yīng)集（Response Set）中的聚合數(shù)量對響應(yīng)時(shí)間幾乎沒有影響。在行式存儲(chǔ)中，響應(yīng)時(shí)間隨著讀取的聚合數(shù)量線性增加。

圖 4：即時(shí)聚合 VS 物化視圖讀取

3.2.2 ?狀態(tài)更新

狀態(tài)變量（如未支付、已支付）通常使用一組預(yù)定義的值，因此在執(zhí)行就地更新時(shí)不會(huì)產(chǎn)生問題，因?yàn)樽兞康幕鶖?shù)不會(huì)改變。建議不要對狀態(tài)字段進(jìn)行列的序列壓縮。如果應(yīng)用更傾向于自動(dòng)記錄狀態(tài)變化，我們也可以對這些變化使用僅插入（Insert-Only）的方法，這一點(diǎn)我們將在 3.2.2 節(jié)中進(jìn)行討論。如果狀態(tài)變量只有兩個(gè)值，那么最好的選擇是一個(gè)空值（Null Value）和一個(gè)時(shí)間戳。即使針對基于時(shí)間的查詢，就地更新也是完全透明的。

3.2.3 ?值更新

由于在大多數(shù)情況下，企業(yè)應(yīng)用中的屬性更改都必須記錄到日志中，所以 Insert-Only 看起來是個(gè)恰當(dāng)?shù)姆绞健?/span>圖 5 顯示，在很長一段時(shí)間內(nèi)，一個(gè)金融系統(tǒng)中平均只有 5% 的元組發(fā)生了實(shí)際變化。增量管理器的額外負(fù)載和主內(nèi)存的額外消耗是可以接受的。增量管理器是用于處理更新和插入的列式存儲(chǔ)數(shù)據(jù)庫中的寫優(yōu)化存儲(chǔ)。數(shù)據(jù)只插入到增量存儲(chǔ)中。增量存儲(chǔ)中的字典不會(huì)被排序，而是保持插入的順序。使用 Insert-Only，我們還可以捕獲變更歷史，包括變更的時(shí)間和來源。

圖 5：會(huì)計(jì)更新頻率

盡管事實(shí)上典型的企業(yè)系統(tǒng)并不是真正的更新密集型，但是通過使用 Insert-Only 和不維護(hù)總數(shù)，我們甚至可以減少這些更新。因?yàn)楦伦兩倭耍枣i問題也減少了，并且表可以更容易地通過 Shared-Nothing 方法在獨(dú)立的計(jì)算單元（刀片）之間實(shí)現(xiàn)水平分布（分區(qū)）[19]。基本上消除了更新之后，我們現(xiàn)在只需要考慮插入和讀取。下一節(jié)將討論如何區(qū)分元組的最新表示和舊版本，以及如何維護(hù)讀取和更新之間的并發(fā)性。

根據(jù)對金融系統(tǒng)的這些推薦修改，主要表格的數(shù)量將從 18 個(gè)以上降至 2 個(gè)（不包括變更歷史、指數(shù)和 OLAP Cube），如圖 6 所示。我們只在表格中保留會(huì)計(jì)文檔——標(biāo)題和行項(xiàng)目。在文件上執(zhí)行的 Insert-Only 方法和計(jì)算算法會(huì)替換所有索引、物化視圖和更改歷史。

圖 6：簡化后的金融系統(tǒng)（目標(biāo)）

四、?Insert-Only 的后果

Insert-Only 會(huì)對應(yīng)用和數(shù)據(jù)庫級別的加鎖處理方式產(chǎn)生影響。

4.1 應(yīng)用級鎖

許多業(yè)務(wù)事務(wù)同時(shí)處理幾個(gè)關(guān)系表和一個(gè)表的多個(gè)元組。應(yīng)用程序在對象中“思考”，對象是建立在關(guān)系模型之上的一層。盡管我們可以用我們獨(dú)有的數(shù)據(jù)庫鎖處理大多數(shù)并發(fā)情況，但我們必須在對象（應(yīng)用）層級引入一個(gè)共享鎖（Shared Lock）。例如，應(yīng)用對象 customer 轉(zhuǎn)換成多達(dá) 15 個(gè)數(shù)據(jù)庫表?？蛻魧ο蟮淖兓梢园ㄣy行信息、送貨地址等。為了保持一致性，一次只能有一個(gè)事務(wù)更改該特定對象。另一個(gè)例子是應(yīng)付賬款或應(yīng)收賬款中未清項(xiàng)目的對賬。多個(gè)未清項(xiàng)目將在一次交易中標(biāo)記為已支付。鎖沒有加在會(huì)計(jì)行項(xiàng)目表上，而是加在對象 creditor 或 debitor 上。這些應(yīng)用級鎖是使用內(nèi)存中的數(shù)據(jù)結(jié)構(gòu)實(shí)現(xiàn)的。

4.2 數(shù)據(jù)庫鎖

利用 Insert-Only，除了二進(jìn)制狀態(tài)變量之外，可以消除應(yīng)用對元組的更新。在數(shù)據(jù)庫中擁有同一個(gè)元組的多個(gè)版本需要將較舊的版本標(biāo)記為不再有效。每個(gè)插入的元組都帶有它的創(chuàng)建時(shí)間戳，如果該元組更新了，還會(huì)帶有更新的時(shí)間戳。只有元組的最新版本沒有更新時(shí)間戳，因此很容易識(shí)別出來。這個(gè)概念的好處是，可以通過使用關(guān)于查詢的基準(zhǔn)日期的兩個(gè)時(shí)間戳來重建元組的任何狀態(tài)。這種方法在1987年時(shí)已經(jīng)被 POSTGRES 采用[21]，稱為“時(shí)間旅行”。擴(kuò)展 SQL 必須支持基準(zhǔn)日期參數(shù)，通過該參數(shù)可以識(shí)別元組的有效版本。

在同一個(gè)表中攜帶元組的所有舊版本具有顯著的應(yīng)用優(yōu)勢，尤其是在檢索舊版本數(shù)據(jù)是常見操作的規(guī)劃應(yīng)用中[7]。除此之外，它完全消除了單獨(dú)創(chuàng)建變更日志的必要性。其帶來的額外存儲(chǔ)容量要求可以忽略不計(jì)。

時(shí)間戳屬性不參與任何壓縮算法，因此在更新時(shí)不會(huì)導(dǎo)致列的任何重組。因?yàn)槎鄠€(gè)查詢可能與插入和更新同時(shí)發(fā)生，所以必須非常小心地避免在表、列或字典級別的過多鎖定。

現(xiàn)在我們來看看插入。插入的數(shù)據(jù)被添加至表中恰當(dāng)?shù)姆謪^(qū)中的增量存儲(chǔ)內(nèi)。查詢開始時(shí)的時(shí)間戳定義了哪些元組是有效的（只有時(shí)間戳更早的元組）。萬一插入操作正在進(jìn)行中，新查詢的開始時(shí)間戳將會(huì)被設(shè)置為插入事務(wù)的時(shí)間戳減1，并且正在進(jìn)行的插入將再次被忽略。此過程相當(dāng)于通過時(shí)間戳實(shí)現(xiàn)的快照隔離[15，3]。

在當(dāng)前的研究系統(tǒng)中，我們觀察到當(dāng)多個(gè)查詢同時(shí)運(yùn)行時(shí)，每次插入的時(shí)間都會(huì)顯著增加。我們認(rèn)為這是一個(gè)實(shí)現(xiàn)問題，因?yàn)樵谶^去，只讀應(yīng)用的設(shè)計(jì)目標(biāo)是實(shí)現(xiàn)壓縮最大化。因?yàn)椴迦氡蛔鳛樵隽看鎯?chǔ)的追加實(shí)現(xiàn)，從而不需要排他鎖。如果一個(gè)事務(wù)包括多個(gè)插入，則適用和插入/更新相同的邏輯。所有并發(fā)運(yùn)行的查詢將通過時(shí)間戳比較看到一致的快照。

未來的研究將會(huì)特別關(guān)注并發(fā)性和鎖問題。作為一般規(guī)則，數(shù)據(jù)庫系統(tǒng)應(yīng)該以最大速度執(zhí)行每個(gè)任務(wù)，即使會(huì)占用所有資源（例如 CPU 核）以避免潛在的沖突和管理開銷的增加。

與之前的插入一樣，后續(xù)所有的針對改變后的元組的插入都帶有一個(gè)全局唯一的用戶標(biāo)識(shí)符。與時(shí)間戳一起，提供了完整的更改歷史。

擁有表中元組的完整歷史意味著開發(fā)事實(shí)隨著時(shí)間演變（Evolution of Facts Over Time）的表示。一個(gè)例子是與外部事件相關(guān)的一個(gè)季度內(nèi)每天的銷售預(yù)測的演變，從而可以更好地了解趨勢并改進(jìn)推斷（圖 7）。盡管應(yīng)用對滑塊的每次增量移動(dòng)都要進(jìn)行全表掃描（見虛線），用戶體驗(yàn)類似于在 Microsoft Word 中使用滾動(dòng)條。

五、就內(nèi)存消耗而言，列式存儲(chǔ)優(yōu)于行式存儲(chǔ)

在為 OLTP 和 OLAP 構(gòu)建一個(gè)組合系統(tǒng)的假設(shè)下，數(shù)據(jù)必須針對集合處理、快速插入、最大（讀?。┎l(fā)性和重組的低影響進(jìn)行組織。這限制了行式存儲(chǔ)和列式存儲(chǔ)的壓縮程度。雖然在行式存儲(chǔ)中實(shí)現(xiàn)與列式存儲(chǔ)相同程度的壓縮是可能的（例如 IBM 的 Blink 引擎[17]），但是要將行式存儲(chǔ)和列式存儲(chǔ)作比較的戶啊，必須要在滿足上述要求（尤其是快速插入）的情況下進(jìn)行才客觀，這就將只讀行式存儲(chǔ)排除在討論之外了。

在列式存儲(chǔ)中，通過屬性值的轉(zhuǎn)換和完全消除只有空值的列進(jìn)行壓縮是非常高效的，但在本研究系統(tǒng)中可以通過將值解釋為：所有字符空白，所有字符零，以及小數(shù)點(diǎn)零作為空值來改進(jìn)。應(yīng)用考慮默認(rèn)值，不能正確處理空值。通過在進(jìn)入數(shù)據(jù)庫的過程中自動(dòng)將默認(rèn)值轉(zhuǎn)換為空值，并在輸出的過程中轉(zhuǎn)換回默認(rèn)值。

當(dāng)我們比較列式存儲(chǔ)和行式存儲(chǔ)中的表對內(nèi)存的要求，二者的壓縮比存在著明顯差異。對現(xiàn)有客戶數(shù)據(jù)的各種分析顯示，在磁盤上，列式存儲(chǔ)的典型壓縮率為 20%，而寫優(yōu)化的行式存儲(chǔ)的壓縮率為 2%。為了進(jìn)一步得出內(nèi)存消耗估計(jì)，我們使用了有利于列式存儲(chǔ)的壓縮使用因子 10。正如在另一章中所討論的，列式存儲(chǔ)允許我們消除所有物化視圖（聚合），并且在需要的時(shí)候可以根據(jù)算法計(jì)算出來。與這些聚合相關(guān)的存儲(chǔ)要求隨應(yīng)用的不同而變化。通常在 OLAP 系統(tǒng)中用于物化匯總的多維 Cube 隨著個(gè)體維度的基數(shù)而增長。因此，基于消除冗余聚合的有利于列式存儲(chǔ)的因子 2 是一個(gè)保守估計(jì)值。

將基于時(shí)間和租戶使用表的水平分區(qū)。為了將不同質(zhì)量的和處理器速度用于特定維度，劃分為多個(gè)維度的選項(xiàng)非常有用。在討論內(nèi)存消耗時(shí)，將表分為每年的當(dāng)前數(shù)據(jù)和歷史數(shù)據(jù)的選項(xiàng)非常有意思。對客戶數(shù)據(jù)的分析表明，通常?5-10 年的歷史數(shù)據(jù)（不允許更改）會(huì)保存在運(yùn)營數(shù)據(jù)庫中。

歷史數(shù)據(jù)可以保持可訪問性，不過需要存放在更便宜、更慢的存儲(chǔ)介質(zhì)上（閃存或磁盤）。當(dāng)前數(shù)據(jù)加上上一年完成的數(shù)據(jù)應(yīng)保存在刀片式服務(wù)器的 DRAM 內(nèi)存中，以便在企業(yè)系統(tǒng)中進(jìn)行典型的年度對比。對于按時(shí)間的分離，我們使用兩個(gè)時(shí)間戳，即創(chuàng)建時(shí)間和完成時(shí)間。完成時(shí)間由應(yīng)用邏輯控制，例如訂單處理完畢或發(fā)票支付完畢。完成日期決定了數(shù)據(jù)成為歷史數(shù)據(jù)的年份，這意味著不可能進(jìn)行進(jìn)一步的更改。關(guān)于主內(nèi)存需求，我們可以考慮有利于列式存儲(chǔ)的因子 5。公平地講，水平分區(qū)也可以在記錄存儲(chǔ)中實(shí)現(xiàn)。如果當(dāng)前和上一年分區(qū)的剩余表大小仍然很大，數(shù)據(jù)庫管理可能會(huì)進(jìn)行水平分區(qū)。忽略索引和維度字典的內(nèi)存需求，我們可以假設(shè)存儲(chǔ)容量減少了 10 x 2 x 5 倍（從磁盤到主內(nèi)存）。刀片服務(wù)器中使用的下一代主板會(huì)提供大約 500 GB 的主內(nèi)存，甚至更多。由于 100 個(gè)刀片的陣列已經(jīng)上市，OLTP 和 OLAP 容量高達(dá) 50 TB 的安裝可以轉(zhuǎn)換為 DRAM 上的純內(nèi)存系統(tǒng)。就存儲(chǔ)容量而言，這涵蓋了大多數(shù)客戶，例如 SAP 的業(yè)務(wù)套件客戶。

六、典型的數(shù)據(jù)輸入事務(wù)會(huì)發(fā)生什么？

數(shù)據(jù)輸入事務(wù)由三部分組成：用戶數(shù)據(jù)輸入、數(shù)據(jù)驗(yàn)證和數(shù)據(jù)庫更新。大多數(shù)數(shù)據(jù)驗(yàn)證保持不變。事實(shí)上，只有作為索引運(yùn)行的屬性才能幫助提高驗(yàn)證的質(zhì)量，例如檢查客戶、供應(yīng)商、零件條目是否重復(fù)或收到的發(fā)票是否重復(fù)。數(shù)據(jù)庫更新被減少到僅僅是一個(gè)插入操作。沒有索引（不管是一級還是二級）需要維護(hù)，且客戶訂單、股票變動(dòng)等日志條目不會(huì)產(chǎn)生聚合更新。因此，事務(wù)數(shù)據(jù)輸入的吞吐量將會(huì)提高。增量管理器處理新元組的初始插入。

增量存儲(chǔ)再次被組織為列式存儲(chǔ)。由于數(shù)據(jù)檢索和插入會(huì)相互影響，因此在實(shí)現(xiàn)時(shí)必須格外小心，以避免不必要的鎖定。對于分區(qū)表中的插入，尤其如此。為了減少插入對字典表的影響，并減少增量存儲(chǔ)和主存儲(chǔ)之間的合并操作的影響，增量存儲(chǔ)的兩層組織是目前正在研究的概念。因此，研究和開發(fā)的重點(diǎn)從最大限度地壓縮數(shù)據(jù)轉(zhuǎn)移到在其他同時(shí)運(yùn)行的查詢上以最小的影響進(jìn)行高速插入。

七、對應(yīng)用開發(fā)的影響

基于使用列式存儲(chǔ)的關(guān)系型數(shù)據(jù)庫的應(yīng)用應(yīng)該使用關(guān)系代數(shù)和擴(kuò)展的 SQL 特性，將盡可能多的邏輯委托給數(shù)據(jù)庫級和存儲(chǔ)過程。在重寫現(xiàn)有應(yīng)用時(shí)，我們希望減少 30% 以上的代碼量（在金融等更正式的應(yīng)用中，我們希望這一數(shù)字達(dá)到 40-50%）。使用列存儲(chǔ)的全索引特性，許多部分可以完全重構(gòu)。在理想情況下，應(yīng)用只需要為一個(gè)算法設(shè)置參數(shù)，而這個(gè)算法僅由擴(kuò)展 SQL（作為存儲(chǔ)過程）定義且在數(shù)據(jù)庫級別進(jìn)行執(zhí)行。然后，應(yīng)用對結(jié)果集進(jìn)行處理，產(chǎn)生輸出（屏幕、電子郵件、打印、電話等）。如前所述，建議嚴(yán)格使用最小投影。數(shù)據(jù)庫的高性能使得應(yīng)用級別的數(shù)據(jù)緩存非常流暢。

在多個(gè)維度（租戶、時(shí)間、主鍵范圍等）對表進(jìn)行分區(qū)表的支持有助于為更大的表實(shí)現(xiàn)最短的響應(yīng)時(shí)間。由于除了 100 字節(jié)的 Stub 之外，尚未填充的列不占用任何存儲(chǔ)空間，因此向現(xiàn)有表添加新列變得十分簡單。

為了驗(yàn)證我們的發(fā)現(xiàn)，一個(gè)研究團(tuán)隊(duì)開始基于 SAP 的按需系統(tǒng) ByDesign，為應(yīng)收賬款、應(yīng)付賬款、總賬和成本會(huì)計(jì)（包括規(guī)劃）建立下一代會(huì)計(jì)系統(tǒng)。所有用戶交互、配置等都相同，以便進(jìn)行完整的平行測試。

日記賬分錄表只有一個(gè)索引，即會(huì)計(jì)憑證號(hào)（加上行項(xiàng)目號(hào)）。沒有將日記帳分錄與帳戶（借方、貸方、G/L或成本中心等）聯(lián)系起來的索引存在。唯一更新的屬性是：創(chuàng)建、失效和協(xié)調(diào)時(shí)間戳。所有其他更改都會(huì)導(dǎo)致插入已更改的條目，并使舊條目無效。

沒有實(shí)體化視圖形式的聚合，相反，它們將通過實(shí)時(shí)算法創(chuàng)建。數(shù)據(jù)輸入速度提高了，因?yàn)橹挥袃蓚€(gè)表（單據(jù)標(biāo)題、單據(jù)行項(xiàng)目別名日記帳分錄）接收插入。事務(wù)的簡單性允許重新考慮前向恢復(fù)方法，而不是退出失敗的事務(wù)。

會(huì)計(jì)數(shù)據(jù)的每一種表示都可以定義為電子表格，識(shí)別賬戶、它們的層次結(jié)構(gòu)（集合）、要計(jì)算的值（集合）。在翻譯成擴(kuò)展 SQL 后，可以驗(yàn)證語句的正確性，并且假設(shè) SQL 處理器工作正常，不需要進(jìn)一步測試。應(yīng)用程序可以完全專注于用戶交互和信息呈現(xiàn)。在第二階段，一個(gè)包括商業(yè)專家在內(nèi)的研究項(xiàng)目將關(guān)注響應(yīng)時(shí)間接近于零的全索引數(shù)據(jù)庫的潛力。

不僅消除了冗余表，還消除了系統(tǒng)的 OLTP 和 OLAP 部分之間的更新過程或 ETL 過程形式的冗余表維護(hù)。

八、SaaS 應(yīng)用中的列式存儲(chǔ)

針對?SaaS（軟件即服務(wù)）應(yīng)用中，列式存儲(chǔ)的在以下幾個(gè)方面有優(yōu)勢：未使用的列僅由 Stub 表示。向表中引入新屬性意味著更新元數(shù)據(jù)并為列創(chuàng)建 Stub[2]。然后應(yīng)用便可以使用這些屬性。對于正在進(jìn)行的應(yīng)用開發(fā)來說，這是一個(gè)重要的特性，且該特性不會(huì)對用戶造成任何干擾。與外部數(shù)據(jù)的連接在導(dǎo)入到主機(jī)系統(tǒng)后保存在列式存儲(chǔ)中，即使對于非常大的表（訪問的最小主存），這也是非常高效的。在這兩種情況下，響應(yīng)時(shí)間將大大得到縮短。

現(xiàn)在，應(yīng)用不僅可以確定查詢的基準(zhǔn)日期，還可以監(jiān)控單個(gè)元組內(nèi)容（屬性）的發(fā)展（例如，客戶訂單的生命周期、人力資源或應(yīng)付賬款中敏感數(shù)據(jù)的控制）。

九、后續(xù)研究

我們后續(xù)的研究方向集中在為 OLTP 和 OLAP 混合負(fù)載系統(tǒng)創(chuàng)建一個(gè)基準(zhǔn)，該基準(zhǔn)將基于真實(shí)的客戶系統(tǒng)和數(shù)據(jù)[4]、內(nèi)存型列式存儲(chǔ)數(shù)據(jù)庫的多租戶以及圍繞增量合并過程的優(yōu)化。

我們今后研究的重點(diǎn)方向?yàn)椋?/span>

• 災(zāi)難恢復(fù)

• TCO：當(dāng)前版本的 SAP 按需會(huì)計(jì)系統(tǒng)與基于列式存儲(chǔ)的版本之間的總擁有成本（Total Cost of Ownership，TCO）比較，包括能耗

• 非結(jié)構(gòu)化數(shù)據(jù)模型的擴(kuò)展

• 基于生命周期的數(shù)據(jù)管理：基于不同應(yīng)用的語義，可以指定單個(gè)記錄是否支持再次修改，或是保持只讀模式從而允許不同的壓縮和分區(qū)策略。

• 垂直分區(qū)：在企業(yè)應(yīng)用中，單個(gè)表中的塊傾向于按照他們的訪問模式組合在一起。使用垂直分區(qū)方法可以在讀取這些組的內(nèi)容時(shí)提高性能。

十、結(jié)論和展望

過去兩年半中獲得的經(jīng)驗(yàn)鼓勵(lì)我們?yōu)楦蟮墓酒髽I(yè)系統(tǒng)（例如，每年多達(dá) 1 億次銷售活動(dòng)）進(jìn)行設(shè)想，其中所有的業(yè)務(wù)交易、查詢，包括無限聚合和基于時(shí)間的序列，都可以在幾秒鐘內(nèi)得到結(jié)果（包括成本驚人的表示層，presentation layer）。我們預(yù)計(jì)列式存儲(chǔ)的發(fā)展將會(huì)對企業(yè)管理產(chǎn)生翻天覆地的影響，就像當(dāng)初互聯(lián)網(wǎng)搜索引擎顛覆了我們的生活一樣。圖 8 描繪了一個(gè)未來的管理會(huì)議，您想要的信息，動(dòng)動(dòng)手指就能搞定[10]。

圖 8：未來的管理會(huì)議