翻譯：王學(xué)姣?

審校：李浩、宇亭?

責編：宇亭設(shè)計：Yeekin

導(dǎo)語

本篇是StoneDB學(xué)術(shù)分享會專欄的第七篇，在上一期里，我們分享了 SAP 在 2012 年發(fā)表的《The SAP HANA Database – An Architecture Overview》論文，主要是介紹了?SAP HANA 列式存儲引擎的架構(gòu)設(shè)計，該列存引擎利用現(xiàn)代硬件（多 CPU 內(nèi)核、大容量主內(nèi)存和緩存），支持數(shù)據(jù)壓縮、數(shù)據(jù)庫內(nèi)核并行最大化，提供層次結(jié)構(gòu)（hierarchy）專用的數(shù)據(jù)結(jié)構(gòu)、用于特定領(lǐng)域的語言支持等企業(yè)應(yīng)用所需的數(shù)據(jù)庫擴展。

本期，我們將帶大家讀一讀這篇《Efficient Transaction Processing in SAP HANA Database – The End of a Column Store Myth》，瞧瞧，這個標題就起得很有火藥味，SAP 提出列式存儲引擎的時候，市面上敢用行列混存做 HTAP 數(shù)據(jù)庫的基本沒幾個，但是人家竟然敢直接跟你說，SAP HANA 數(shù)據(jù)庫，就是為了結(jié)束人們對列式存儲的偏見而生的，誰說列式存儲不能做事務(wù)型工作（OLTP）的？我們 SAP HANA 證明給你看~（當然了，現(xiàn)在列式存儲的數(shù)據(jù)庫其實已經(jīng)很多了，我們的 StoneDB 團隊自研的 Tianmu 引擎就是列式存儲引擎）

是不是還挺橫的？一眾數(shù)據(jù)庫界的大佬也坐不住了：你們 SAP 到底哪來的底氣？別急，今天就帶大家看看這篇經(jīng)典論文，揭開 SAP HANA 數(shù)據(jù)庫的神秘面紗。

摘要

SAP HANA 數(shù)據(jù)庫是 SAP 新推出的數(shù)據(jù)管理平臺的核心。SAP HANA 數(shù)據(jù)庫的總體目標是為事務(wù)型查詢和分析型查詢場景提供一個通用的、強大的系統(tǒng)，且在高度可擴展的執(zhí)行環(huán)境中為不同的查詢場景提供相同的數(shù)據(jù)表示。本文重點介紹了 SAP HANA 數(shù)據(jù)庫區(qū)別于傳統(tǒng)關(guān)系型數(shù)據(jù)庫引擎的主要特性。因此，在本文中，我們首先概述了 SAP HANA 的總體架構(gòu)和設(shè)計標準。其次，SAP HANA 挑戰(zhàn)了人們關(guān)于列存數(shù)據(jù)結(jié)構(gòu)的偏見，即列存儲數(shù)據(jù)結(jié)構(gòu)只在分析型工作負載中表現(xiàn)優(yōu)異，并不適合事務(wù)型工作負載。我們概述了如何通過管理記錄（record）生命周期來使用不同的格式存儲不同階段的同一記錄。除了提供概念的解讀外，我們還深入探討了如何在記錄的生命周期中對其進行高效同步，以及如何將數(shù)據(jù)庫條目從寫優(yōu)化的存儲格式轉(zhuǎn)移到讀優(yōu)化的存儲格式的一些細節(jié)。總之，本文旨在說明 SAP HANA 數(shù)據(jù)庫如何實現(xiàn)同時在分析型和事務(wù)型工作負載環(huán)境中進行高效工作。

簡介

現(xiàn)代商業(yè)應(yīng)用中的數(shù)據(jù)管理是當今軟件行業(yè)面臨的最具挑戰(zhàn)性的課題之一。現(xiàn)如今，數(shù)據(jù)不僅推動著業(yè)務(wù)發(fā)展，還為新業(yè)務(wù)理念或業(yè)務(wù)案例的發(fā)展提供了基礎(chǔ)。各種各樣的數(shù)據(jù)管理已經(jīng)成為企業(yè)的核心資產(chǎn)。此外，數(shù)據(jù)管理作為推動和發(fā)展當前業(yè)務(wù)的主要工具，已經(jīng)引起了高層管理者的極大關(guān)注。在系統(tǒng)方面，數(shù)據(jù)管理場景變得極其復(fù)雜，難以管理。一個高效、靈活、穩(wěn)健、低成本的數(shù)據(jù)管理層成為了大量應(yīng)用場景的核心，而這些應(yīng)用場景則是當今商業(yè)環(huán)境中不可或缺的部分。

起初，傳統(tǒng) ERP 系統(tǒng)被用為處理這些應(yīng)用場景的信息處理中樞。從數(shù)據(jù)庫系統(tǒng)的角度來看，ERP 系統(tǒng)的 OLTP 工作負載通常需要處理成千上萬的并發(fā)用戶和事務(wù)，而這些事務(wù)常常伴隨著高更新負載和選擇性極強的點查詢（point query）。另一方面，數(shù)據(jù)倉庫系統(tǒng)（對應(yīng)于 OLTP 系統(tǒng)）要么對基于大量數(shù)據(jù)進行聚合查詢，要么通過計算統(tǒng)計模型來分析存儲在數(shù)據(jù)庫中的內(nèi)容。然而，新應(yīng)用的出現(xiàn)，例如用于識別數(shù)據(jù)流或ETL/信息集成任務(wù)中的異常的實時分析，對數(shù)據(jù)管理層提出了新的需求和挑戰(zhàn)。這些需求和挑戰(zhàn)要求一個能夠處理現(xiàn)代業(yè)務(wù)應(yīng)用的數(shù)據(jù)管理層。

Stonebraker 等人為上述問題提供了一個答案。他們在 2007 年【13】提出了“The End of an Architectural Era (It's Time for a Complete Rewrite)”的觀點，表明傳統(tǒng)的數(shù)據(jù)庫管理系統(tǒng)不再能夠滿足變化多樣的市場需求。市場需要不同的數(shù)據(jù)庫管理系統(tǒng)用于解決不同的問題。從本質(zhì)上來說，此觀點證實了如下現(xiàn)狀：大型數(shù)據(jù)管理解決方案是一個包含各種系統(tǒng)的集合。這些系統(tǒng)適用于不同的應(yīng)用場景。例如，行存儲仍然主要應(yīng)用于 OLTP 領(lǐng)域。使用基于實體（entity-based）的交互模型能夠在記錄中維護邏輯實體和物理表示之間的 1:1 關(guān)系。按列組織的數(shù)據(jù)結(jié)構(gòu)在分析領(lǐng)域獲得了越來越多的關(guān)注。這種數(shù)據(jù)結(jié)構(gòu)可以避免查詢列的投影（projection），并可以提供更好的壓縮效率。鍵值存儲（key-value store）正在逐漸成為商業(yè)數(shù)據(jù)管理解決方案的一部分，用于處理海量數(shù)據(jù)以及為程序性的代碼提供并行執(zhí)行的平臺。此外，分布式文件系統(tǒng)提供了一種經(jīng)濟的存儲機制以及云彈性般靈活的并行度，使鍵值存儲成為了數(shù)據(jù)管理領(lǐng)域的“頭等公民”。行存儲、列存儲以及鍵值存儲完善了大型數(shù)據(jù)庫管理方案，使之能夠處理各種模式（schema）的數(shù)據(jù)和支持基于圖形的數(shù)據(jù)組織形式。由于模式是伴隨數(shù)據(jù)而出現(xiàn)的，系統(tǒng)通常會提供高效的方法來顯式地利用實體之間的模型化關(guān)系（modeled relationship），運行分析型圖算法（analytical graph algorithm），并展示弱實體的倉庫（repository）。在市場進行性能嘗試初期，專用系統(tǒng)（specialized system）可能被認為是明智之舉，但包含各種專用系統(tǒng)的大型數(shù)據(jù)庫解決方案需要解決各個系統(tǒng)之間的連接、數(shù)據(jù)復(fù)制和同步任務(wù)問題，以及在多個系統(tǒng)間編排查詢場景，使得此類解決方案變得及其復(fù)雜。此外，為這類解決方案進行環(huán)境配置和維護不僅操作復(fù)雜且極易出錯，而且總擁有成本（TCO）也十分高昂。

概括來講，我們對當前形勢進行了如下幾方面的觀察：

????使用角度：我們認為 SQL 不再是現(xiàn)代業(yè)務(wù)應(yīng)用唯一適用的交互模型。用戶要么被應(yīng)用層這個屏障完全隔開，要么希望直接與其數(shù)據(jù)庫進行交互。在第一種情況下，我們發(fā)現(xiàn)需要用緊耦合機制來實現(xiàn)對應(yīng)用層的最佳支持。在第二種情況下，我們發(fā)現(xiàn)需要針對特定領(lǐng)域使用具有內(nèi)置數(shù)據(jù)庫特性的腳本語言，如用于統(tǒng)計處理的 R（【4】）或用于 Hadoop 安裝的 Pig。我們還觀察到對特定領(lǐng)域和專有查詢語言的全面支持的需求，例如 SAP 提供的用于金融規(guī)劃場景的 FOX （【7】）。最后，我們還發(fā)現(xiàn)了一個巨大的市場需求：從編程的角度考慮并行性，市場需要直接使能用戶的機制。

????成本意識：我們觀察到一個很明確的需求，市場需要一個從硬件到安裝成本，再到運營和維護成本，為整個數(shù)據(jù)管理體系提供更低TCO 的解決方案，一個針對不同工作負載類型和使用模式（usage pattern）的融合解決方案。

????性能、性能、還是性能（【16】）：我們認為性能仍然是使用專用系統(tǒng)的主要原因。當前所面臨的挑戰(zhàn)是提供一個在任何時候都能夠根據(jù)需求靈活地應(yīng)用專門的運算符或數(shù)據(jù)結(jié)構(gòu)的解決方案。需要指出的是，不同的工作負載特征并不能完全證明包含各類專用系統(tǒng)的大型數(shù)據(jù)管理解決方案的合理性。我們過去處理業(yè)務(wù)應(yīng)用的經(jīng)驗讓我們成為了特定算子集合需求假設(shè)的支持者。我們對具有獨立生命周期和管理設(shè)置的單獨系統(tǒng)（individual system）存在偏見。我們的目標并不是提供一個單一的封閉系統(tǒng)，而是提供一個使用通用服務(wù)原語的、靈活的數(shù)據(jù)管理平臺。當前SAP HANA 數(shù)據(jù)庫的可用功能是 SAP HANA 設(shè)備的核心部分（【2】），可被視為這種工具包的一個具體體現(xiàn)。

貢獻和概述

本文旨在描述 SAP HANA 數(shù)據(jù)庫平臺的全貌，并深入解釋一些為處理事務(wù)型工作負載而做的工作細節(jié)。我們首先概述了 SAP HANA 的整體架構(gòu)和設(shè)計準則，強調(diào)了其與傳統(tǒng)關(guān)系數(shù)據(jù)庫管理系統(tǒng)的不同之處，尤其是SAP HANA 數(shù)據(jù)庫在典型業(yè)務(wù)應(yīng)用范圍內(nèi)的以下顯著特征：

????SAP HANA 數(shù)據(jù)庫包含一個多引擎查詢處理環(huán)境。該環(huán)境提供支持不同結(jié)構(gòu)化程度的數(shù)據(jù)的數(shù)據(jù)抽象，包括高度結(jié)構(gòu)化的關(guān)系型數(shù)據(jù)、到不規(guī)則的結(jié)構(gòu)化數(shù)據(jù)圖（irregularly structured data graphs）、再到非結(jié)構(gòu)化的文本數(shù)據(jù)。處理引擎的整個使用范圍基于一個公共表抽象，作為底層物理數(shù)據(jù)表示，從而保證互操作性以及允許不同類型之間的數(shù)據(jù)組合。

????SAP HANA 數(shù)據(jù)庫支持在數(shù)據(jù)庫引擎中直接表示特定于應(yīng)用的業(yè)務(wù)對象（如 OLAP cube）和邏輯（特定領(lǐng)域的函數(shù)庫）。這允許通過底層數(shù)據(jù)管理平臺實現(xiàn)應(yīng)用語義（application semantics）交換，從而提高查詢效率，減少單個應(yīng)用到數(shù)據(jù)庫的往返次數(shù)以及數(shù)據(jù)庫和應(yīng)用之間傳輸?shù)臄?shù)據(jù)量。

????SAP HANA 數(shù)據(jù)庫針對數(shù)據(jù)管理層和應(yīng)用層之間的通信進行了性能優(yōu)化。例如，SAP HANA 數(shù)據(jù)庫原生支持 SAP 應(yīng)用服務(wù)器的數(shù)據(jù)類型。此外，還計劃將新的應(yīng)用服務(wù)器技術(shù)直接集成到 SAP HANA 數(shù)據(jù)庫集群的基礎(chǔ)架構(gòu)中，以支持應(yīng)用邏輯和數(shù)據(jù)庫管理功能的交叉執(zhí)行。

????SAP HANA 數(shù)據(jù)庫通過利用實現(xiàn)高度優(yōu)化的面向列的數(shù)據(jù)表示，支持在同一物理數(shù)據(jù)庫上對事務(wù)性和分析性工作負載進行高效處理。該功能的實現(xiàn)依賴于復(fù)雜的多步驟記錄生命周期管理（multi-step record lifecycle management）。

前三個特征我們已經(jīng)在【2】中進行了探討，最后一個特征將在本文的第二部分進行討論。此處我們概述了與統(tǒng)一表結(jié)構(gòu)（unified table structure）和傳播機制相關(guān)的一些細節(jié)，以便通過可控的生命周期管理流程在系統(tǒng)內(nèi)移動記錄（record）。具體來講，我們首先使用不同數(shù)據(jù)結(jié)構(gòu)來保存處于生命周期中不同階段的數(shù)據(jù)。然后我們重點關(guān)注如何高效地實現(xiàn)不同數(shù)據(jù)結(jié)構(gòu)之間的傳播步驟，從而能夠?qū)?shù)據(jù)從寫優(yōu)化存儲中移動到主內(nèi)存結(jié)構(gòu)（main memory structure）中。寫優(yōu)化存儲非常適合處理插入、更新和刪除操作，而主內(nèi)存結(jié)構(gòu)中的數(shù)據(jù)是高度壓縮的數(shù)據(jù)，適合處理 OLAP 查詢。順便一提，SAP HANA 數(shù)據(jù)庫還提供了運行 SAP ERP 系統(tǒng)等企業(yè)關(guān)鍵型應(yīng)用所需的技術(shù)。例如，SAP HANA 數(shù)據(jù)庫展示了 SAP HANA 集群中各個節(jié)點的容錯能力，即如果一個節(jié)點出現(xiàn)故障，其他節(jié)點會自動接管負載。在這種情況下，查詢處理既不會被阻塞也不會停止，而是由分布式查詢執(zhí)行框架以一種對用戶透明的方式重新進行路由。SAP HANA 數(shù)據(jù)庫也支持備份和恢復(fù)等功能。從事務(wù)行為來看，SAP HANA 數(shù)據(jù)庫使用多版本并發(fā)控制（multi-version concurrency control, MVCC）來實現(xiàn)不同級別的事務(wù)隔離。SAP HANA 數(shù)據(jù)庫支持事務(wù)級和語句級快照隔離。不夠由于篇幅限制，我們不會就該點進行展開說明。

SAP HANA 數(shù)據(jù)庫的分層架構(gòu)

如【2】中所述，SAP HANA 產(chǎn)品已經(jīng)上市，由一個帶有不同組件的設(shè)備模型組成，可為數(shù)據(jù)分析場景提供現(xiàn)成的解決方案。這是SAP HANA 邁出的第一步，旨在在數(shù)據(jù)集市場景中讓客戶接受并習(xí)慣以列為導(dǎo)向、以主內(nèi)存為中心的 SAP HANA 數(shù)據(jù)庫的全新理念。截至目前，SAP 正在為 SAP Business Warehouse 產(chǎn)品提供原生支持，以顯著加快查詢和轉(zhuǎn)換場景，同時允許完全跳過單個物料化步驟。為了提供這種能力，SAP HANA 擁有數(shù)據(jù)加載和轉(zhuǎn)換工具以及建模工作室，以創(chuàng)建和維護進出 SAP HANA 的復(fù)雜數(shù)據(jù)流。SAP HANA 數(shù)據(jù)庫是SAP HANA 產(chǎn)品的核心組件，負責高效和靈活的數(shù)據(jù)存儲和數(shù)據(jù)查詢場景（【11，12】）。

SAP HANA 數(shù)據(jù)庫本身遵循嚴格的分層架構(gòu)，如圖 2 所示。與傳統(tǒng)系統(tǒng)類似，SAP HANA 數(shù)據(jù)庫區(qū)分數(shù)據(jù)庫請求的編譯時（compile time）和運行時（runtime）。此圖并未包含 SAP HANA 數(shù)據(jù)庫的所有組件，例如交易管理器（transaction manager）、授權(quán)管理器（authorization manager）、元數(shù)據(jù)管理器（metadata manager）等均未體現(xiàn)。

除了純粹的數(shù)據(jù)處理性能之外，我們還發(fā)現(xiàn)應(yīng)用層和數(shù)據(jù)管理層之間缺乏恰當?shù)鸟詈蠙C制。這是當前最先進系統(tǒng)的主要缺陷之一。這成為了驅(qū)動我們將 SAP HANA 數(shù)據(jù)庫設(shè)計為可針對不同查詢語言進行擴展的平臺的一個主要因素。如圖 2 所示，不同查詢語言可以通過普通連接和會話管理層進入系統(tǒng)，實現(xiàn)同外部的交流。在第一步中，查詢字符串被翻譯成優(yōu)化之后的內(nèi)部表示（類似于抽象語法樹），這對于每一種領(lǐng)域特定（domain-specific）的語言而言都是本地實現(xiàn)的。第二步，查詢表達式被映射到一個“計算圖（calculation graph）”，從而構(gòu)成了邏輯查詢處理框架（logical query processing framework）的核心。

2.1 計算圖模型

“計算圖模型”遵循經(jīng)典數(shù)據(jù)流圖（data flow graph）的原則。源節(jié)點（source node）是持久表結(jié)構(gòu)或其他計算圖的結(jié)果表示。內(nèi)部節(jié)點（inner node）表示消耗一個或多個傳入數(shù)據(jù)流并產(chǎn)生任意數(shù)量的傳出數(shù)據(jù)流的邏輯運算符。此外，計算圖操作符集可以分成兩組操作符類型。

一方面，計算圖模型定義了一組內(nèi)置運算符（intrinsic operator），包括聚合（aggregation）、投影（projection）、連接（join）、聯(lián)合（union）等。SQL 可以完全映射到這類操作符。另一方面，計算圖模型提供了實現(xiàn)核心業(yè)務(wù)算法（例如貨幣轉(zhuǎn)換和日歷功能）的操作符。此外，計算圖模型支持以下類型的運算符：

????動態(tài) SQL 節(jié)點（dynamic SQL node）：計算圖模型運算符可以對傳入的數(shù)據(jù)流執(zhí)行完整的 SQL 語句。該語句可以是參數(shù)，并且在計算圖運行時被編譯和執(zhí)行，從而產(chǎn)生了一種“嵌套計算”模型的形式。????

????自定義節(jié)點（custom node）：出于性能原因，可以使用自定義節(jié)點在 C++ 中實現(xiàn)特定領(lǐng)域的運算符。例如，使用 SAP 專有語言 Fox【6】的規(guī)劃場景可以利用特殊的“分解（disaggregate）”運算符來原生支持財務(wù)規(guī)劃情況【7】。另一個例子是通過專有的 WIPE graph 語言在數(shù)據(jù)圖中進行圖遍歷和分析優(yōu)化。?

???R 節(jié)點（R node）：R 節(jié)點（【4】）可用于將傳入的數(shù)據(jù)集轉(zhuǎn)發(fā)到 R 執(zhí)行環(huán)境。作為參數(shù)給出的 R 腳本將在 SAP HANA 數(shù)據(jù)庫之外執(zhí)行，并將結(jié)果移回到計算圖中進行進一步處理。

????L 節(jié)點（L node）：語言 L 代表 SAP HANA 數(shù)據(jù)庫的內(nèi)部運行時語言。語言 L 被設(shè)計成 C 語言的安全子集。通常情況下，終端用戶或應(yīng)用設(shè)計者不能直接訪問。語言 L 是所有的不能直接映射到數(shù)據(jù)流圖的領(lǐng)域?qū)Ｓ谜Z言的結(jié)構(gòu)（constructs）的合集。換言之，語言L 即各種命令式控制邏輯。

除了一組功能操作符之外，計算圖模型還提供了“拆分（split）”和“組合（combine）”的運算符，以動態(tài)定義和重新分配數(shù)據(jù)流分區(qū)，作為支持應(yīng)用定義（application-defined）的數(shù)據(jù)并行化的基礎(chǔ)構(gòu)造。各領(lǐng)域?qū)Ｓ谜Z言的編譯器都試圖優(yōu)化從查詢腳本到計算圖的映射。對于 SQL，映射的基礎(chǔ)是有明確定義的、查詢表達式的邏輯表示。在一般情況下，映射可以使用啟發(fā)式或者基于代價的策略，這取決于輸入數(shù)據(jù)的預(yù)估大小等因素。例如，編譯器可能會決定將循環(huán)展開成常規(guī)數(shù)據(jù)流圖，或者為特定表達式生成 L 代碼【6】。在常規(guī) SQL 的情況下，這是迄今為止最大和最復(fù)雜的部分，取自 SAP P*Time1 系統(tǒng)（【1】），內(nèi)部表示直接映射到關(guān)系運算符以捕獲SQL 語句的意圖。

圖 3 描繪了一個計算圖模型示例。計算圖模型可以通過特定領(lǐng)域語言的編譯器間接創(chuàng)建，也可以使用 SAP HANA Studio進行可視化建模，并在 SAP HANA 數(shù)據(jù)庫的應(yīng)用級內(nèi)容倉庫中注冊為計算視圖（calculation view）。這一過程背后的總體思想是定制復(fù)雜業(yè)務(wù)邏輯場景的特定段（segment），這些段可以在多個數(shù)據(jù)庫場景中進行微調(diào)和重用，與實際的查詢語言無關(guān)。換言之，計算圖模型可以以虛擬表的形式在任何領(lǐng)域特定語言堆棧中被消費。計算圖模型的集合也稱為 SAP HANA content，并擁有獨立的產(chǎn)品生命周期流程。圖3 所示的計算模型概述了 SAP HANA 數(shù)據(jù)庫與標準關(guān)系型數(shù)據(jù)庫系統(tǒng)在常規(guī)查詢計劃方面的差異。例如，從應(yīng)用的角度來看，一個操作符的結(jié)果可能會有多個消費者（consumer）需要優(yōu)化共享的公共子表達式。其次，標記為“script”的節(jié)點包含了來自計算模型設(shè)計器或由特定領(lǐng)域查詢編譯器生成的命令性語言片段。最后，節(jié)點“conv”顯示了使用內(nèi)置業(yè)務(wù)函數(shù)來執(zhí)行特定應(yīng)用的轉(zhuǎn)換例程，例如貨幣轉(zhuǎn)換或單位轉(zhuǎn)換。

2.2 計算圖的編譯和執(zhí)行

一旦用戶定義的查詢表達式或查詢腳本被映射到計算圖模型中的數(shù)據(jù)流圖，優(yōu)化器就會運行經(jīng)典的基于規(guī)則或代價的優(yōu)化步驟，將邏輯計劃重構(gòu)并轉(zhuǎn)換為物理計劃，然后由分布式執(zhí)行框架執(zhí)行。執(zhí)行框架繼承自之前的 SAP 產(chǎn)品 SAP BWA（業(yè)務(wù)倉庫加速器）和SAP Enterprise Search，用于處理實際數(shù)據(jù)流和物理操作符的分布式執(zhí)行。在優(yōu)化過程中，邏輯數(shù)據(jù)流圖的片段被映射到“引擎層”提供的物理運算符。引擎層本身由一組不同的物理操作符組成。這些物理操作符有著一些局部優(yōu)化邏輯，從而使全局計劃的片段能夠適應(yīng)實際物理操作符的特性。值得說道的是，SAP HANA 數(shù)據(jù)庫提供了以下一套運算符：

????關(guān)系運算符：關(guān)系運算符用于典型的關(guān)系查詢圖處理。如第3.1小節(jié)所述，關(guān)系運算符擁有不同的特征，例如，equi-join（【5】）等運算符直接利用統(tǒng)一表（unified table）的現(xiàn)有字典。????

????OLAP 運算符：OLAP 運算符針對具有事實表和維度表的星形連接（star-join）方案進行了優(yōu)化。一旦優(yōu)化器識別出這種類型的場景，與之對應(yīng)的查詢計劃片段到 OLAP 運算符的映射就會被枚舉為具有相應(yīng)代價估計的可行物理計劃（【8】）。???

????L 運行時間：內(nèi)部語言的運行時反映了用于執(zhí)行在指定計算圖的L節(jié)點中的表示L代碼的構(gòu)造塊（building code）。使用“拆分（split）和組合（combine）”運算符對時，可以在預(yù)定義的分區(qū)上并行調(diào)用L運行時。???

????文本運算符：文本搜索分析操作符集包括 SAP Enterprise Search 產(chǎn)品中可用的功能集，以提供從相似性度量到實體解析能力的綜合文本分析特性（【14】）。????

????圖形運算符：圖形運算符最終為基于圖形的算法提供支持，以實現(xiàn)復(fù)雜的資源規(guī)劃場景或社會網(wǎng)絡(luò)分析任務(wù)。由于數(shù)據(jù)流圖不僅分布在多個服務(wù)器實例（通常運行在不同物理節(jié)點上）之間，還分布在不同類型的運算符上，因此 SAP HANA 提供了一個工具箱，用于保證最佳的數(shù)據(jù)傳輸和交換格式。盡管所有計算符都需要實施標準的數(shù)據(jù)傳輸協(xié)議，但不同“集合”內(nèi)外的個別運算符可能擁有高度專業(yè)化的通信協(xié)議。例如，關(guān)系運算符和 OLAP 運算符以高度壓縮的專有格式進行數(shù)據(jù)交換。此外，R 節(jié)點提供了一個到 R內(nèi)部數(shù)據(jù)幀格式的映射。

除了“橫向”交流之外，不同物理運算符直接可以通過一個通用接口接入到統(tǒng)一表層（unified table layer）。SAP HANA 數(shù)據(jù)庫提供了一個抽象的表格視圖，允許不同的計算符通過多種方法進行訪問。這一點我們將在下一部分進行詳細介紹。該通用表格結(jié)構(gòu)實現(xiàn)了數(shù)據(jù)實體的完整生命周期，其主要構(gòu)成部分為行存儲和列存儲的組合，用于捕獲最近的數(shù)據(jù)修改效果。由于 SAP HANA 數(shù)據(jù)庫中的表可以標記為“歷史（historic）”，因此表層（table layer）實現(xiàn)了用于捕獲活躍實體（active entity）的過去值的歷史表（history table），并提供了訪問時間旅行查詢（time travel query）的方式。

最后，SAP HANA 的持久層（persistence layer）保證了系統(tǒng)的可恢復(fù)性。即使在主內(nèi)存中的數(shù)據(jù)庫狀態(tài)丟失的情況下，系統(tǒng)也依然能夠?qū)崿F(xiàn)快速恢復(fù)。虛擬文件（virtual file）是持久層的基礎(chǔ)。虛擬文件對可視化頁面的可配置大小進行了限制。采用 SAP MaxDB 系統(tǒng)的概念，持久層依靠頻繁產(chǎn)生的保存點（savepoint）以非常低的資源開銷提供一致快照。更多相關(guān)細節(jié)，將在下一部分介紹。

2.3 總結(jié)

與傳統(tǒng)數(shù)據(jù)庫系統(tǒng)相比，SAP HANA 數(shù)據(jù)庫旨在利用平臺的靈活性來支持多種（專有）領(lǐng)域特定的語言。靈活的數(shù)據(jù)流模型（計算圖模型）提供了概念上的系統(tǒng)核心：一方面，查詢表達式或查詢腳本被映射到模型實例。另一方面，所有不同物理運算符都使用相同的表層接口（table layer interface），對單個記錄實施完整的生命周期管理。日志和數(shù)據(jù)區(qū)被用于在持久存儲中維護主內(nèi)存數(shù)據(jù)庫的事務(wù)一致性副本。

數(shù)據(jù)庫記錄的生命周期管理

如圖 4 所示，統(tǒng)一表結(jié)構(gòu)（unified table structure）允許所有適用的物理運算符進行數(shù)據(jù)訪問。統(tǒng)一表結(jié)構(gòu)的內(nèi)在實質(zhì)是系統(tǒng)為數(shù)據(jù)庫記錄提供了生命周期管理。在我們看來，統(tǒng)一表技術(shù)是系統(tǒng)能夠高性能地同時處理基于掃描的聚合查詢和極具選擇性的點查詢的關(guān)鍵。這成為 SAP HANA 區(qū)別于傳統(tǒng)（行存）數(shù)據(jù)庫的一個關(guān)鍵差異點。在就地更新（update-in-place）風(fēng)格的數(shù)據(jù)庫系統(tǒng)中，記錄從概念層面來看，在其整個生命周期中保持在同一位置，而 SAP HANA 通過物理表示的不同階段對記錄實現(xiàn)了概念上的傳播。雖然是作為一個一般概念設(shè)計的，如圖 4 所示，在一個常規(guī)表中，記錄根據(jù)生命周期被劃分為以下三個階段：

????L1-delta：L1-delta（L1-增量）結(jié)構(gòu)接受所有數(shù)據(jù)傳入請求，并以寫優(yōu)化的方式存儲這些請求，即 L1-delta 保留記錄的邏輯行格式。該數(shù)據(jù)結(jié)構(gòu)針對快速插入和刪除、字段更新和記錄投影進行了優(yōu)化。此外，L1-delta 結(jié)構(gòu)不會對數(shù)據(jù)進行壓縮。根據(jù)經(jīng)驗，單個節(jié)點數(shù)據(jù)庫實例中，L1-delta 結(jié)構(gòu)可以存儲10,000到100,000行數(shù)據(jù)。這一容量因數(shù)據(jù)庫實例的工作負載特征和可用內(nèi)存大小而異。

????L2-delta：L2-delta（L2-增量）結(jié)構(gòu)代表了記錄在生命周期中的第二個階段，以列存格式組織數(shù)據(jù)。與L1-delta 相比，L2-delta 采用字典編碼來優(yōu)化內(nèi)存利用。然而，出于性能考慮，字典是未排序的，需要使用二級索引結(jié)構(gòu)來實現(xiàn)對點查詢訪問模式（access pattern）的最佳支持，例如快速執(zhí)行唯一約束檢查。L2-delta 非常適合存儲量超過1000萬行的場景。

????Main store：最后，main store（主存儲）表示采用各種不同壓縮方案的最高壓縮率的核心數(shù)據(jù)格式。默認情況下，一列中的所有值都通過排序字典中的位置來表示，并以位打包（bit-packing）的方式存儲，以便實現(xiàn)各個值的密集打包（【15】）。雖然字典總是使用各種前綴編碼方案進行壓縮，不同壓縮技術(shù)的組合——從簡單的游程編碼方案到更復(fù)雜的壓縮技術(shù)——也被應(yīng)用于進一步減少占用的主內(nèi)存（【9，10】）。由于 SAP HANA 數(shù)據(jù)庫最初是為復(fù)雜且高容量加載場景的 OLAP 密集型用例而設(shè)計的，因此該系統(tǒng)針對高效批量插入提供了特殊處理，這使得此類操作會繞過 L1-delta 直接進入 L2-delta。與輸入位置無關(guān)，任何輸入記錄的行 ID（RowId）都在行（row）輸入系統(tǒng)時生成。并且，該行的日志在該行第一次出現(xiàn)時生成，無論是在適合常規(guī)更新/插入/刪除操作的 L1-delta 中，還是在適合大容量裝載操作的 L2-delta 中。

3.1 統(tǒng)一表訪問

不同數(shù)據(jù)結(jié)構(gòu)共享一組通用數(shù)據(jù)類型。統(tǒng)一表訪問通過一個帶有行迭代器和列迭代器的公共抽象接口實現(xiàn)。兩個迭代器都可以是基于字典（dictionary-based）的迭代器。此外，在遵循經(jīng)典的 ONC 協(xié)議【3】,支持流水線操作，并盡可能減少中間結(jié)果的內(nèi)存需求的基礎(chǔ)上，一些物理計算符可以逐記錄或者以矢量化的方式（即逐塊）拉取記錄。其他物理計算符采用“materialize all”策略，以避免查詢執(zhí)行期間的計算符切換所產(chǎn)生的成本。優(yōu)化器根據(jù)邏輯計算圖模型來決定如何對不同種類的計算符進行混合使用，即被采用的不同類型的物理運算符將會被無縫集成到最終的查詢執(zhí)行計劃中。

對于使用排序字典的操作符，統(tǒng)一表訪問接口還通過全局排序字典公開表內(nèi)容。在 L1-delta 結(jié)構(gòu)的字典完成計算和 L2-delta 結(jié)構(gòu)的字典完成排序后，兩種 delta 結(jié)構(gòu)的字典會被立刻合并至 main store 的字典中。為了實現(xiàn)唯一性約束的有效性驗證，統(tǒng)一表為兩種 delta 和 main store 提供了反向索引（inverted index）。

記錄的生命周期采用的組織方式將單個記錄在系統(tǒng)中進行異步傳播，而不干擾當前正在事務(wù)控制范圍內(nèi)（transactional sphere of control）運行的數(shù)據(jù)庫操作的組織方式。當前的 SAP HANA 數(shù)據(jù)庫系統(tǒng)提供兩次轉(zhuǎn)換，我們稱之為“合并步驟（merge step）”：

L1-to-L2-delta Merge：從 L1-delta 到 L2-delta 的轉(zhuǎn)換意味著數(shù)據(jù)從按行組織變成了按列組織。L1-delta 中的行被拆分成它們對應(yīng)的列值，然后被逐列插入到 L2-delta 中。在接收端，系統(tǒng)會執(zhí)行一次 lookup 來識別出字典結(jié)構(gòu)中可能丟失的值，并且可以選擇在字典的末尾插入新條目以避免在字典中進行任何重大的重構(gòu)操作。在第二步中，使用字典編碼（append-only 結(jié)構(gòu)）將相應(yīng)的列值添加到值向量中。這兩個步驟可以并行執(zhí)行，因為要移動的元組的數(shù)量是已知的，使得能夠在實際插入它們之前在新字典中保留編碼。在第三步中，從 L1-delta 中移除已經(jīng)傳播的條目（propagated entry）。所有運行中的操作要么看到的是完整的 L1-delta 和舊的 end-of-delta 邊界，要么看到具有 L2-delta 擴展版本的 L1-delta 結(jié)構(gòu)的截斷版本（truncated version）。從設(shè)計角度來看，從 L1-delta 到 L2-delta 的轉(zhuǎn)換本質(zhì)上是增量式的，即記錄的轉(zhuǎn)換對目標結(jié)構(gòu)的數(shù)據(jù)重組沒有任何影響。

L2-delta-to-main Merge：一個新的 main store 是基于 L2-delta 和現(xiàn)有的 main store 產(chǎn)生的。雖然 L1-to-L2-delta Merge 對運行事務(wù)的影響很小，但 L2-delta-to-main Merge 是資源密集型任務(wù)，必須在物理級別上仔細安排并進行高度優(yōu)化。一旦L2-delta-to-main Merge 開始，當前的L2-delta 就會被關(guān)閉用于執(zhí)行更新操作。與此同時，系統(tǒng)會創(chuàng)建一個新的、空的 L2-delta 結(jié)構(gòu)用來作為 L1-to-L2-delta Merge 的目的端。如果 L2-delta-to-main Merge 失敗，系統(tǒng)仍然使用新的 L2-delta 用于L1-to-L2-delta Merge，并繼續(xù)嘗試使用舊版本的 L2-delta 和現(xiàn)有的main 進行合并。第 4 章將詳述核心算法以及不同的優(yōu)化技術(shù)，例如 4.2 小節(jié)會介紹按列合并（column-wise merge），4.3 小節(jié)會介紹部分合并（partial merge）。
上述兩個合并步驟都不會對持久存儲產(chǎn)生直接影響，并且獨立于重啟或備份日志重放。

3.2 ?持續(xù)性映射

雖然 SAP HANA 數(shù)據(jù)庫是一個以內(nèi)存為中心的數(shù)據(jù)庫系統(tǒng)，但其全面的 ACID 支持保證了持久性、原子性，以及系統(tǒng)在定期關(guān)閉或系統(tǒng)故障后能夠重啟恢復(fù)。SAP HANA 數(shù)據(jù)庫考慮了多種持久化觀點來構(gòu)架其持久性。一般來說，持久存儲無需細粒度的 UNDO 機制，因為只有像新版本的 main 結(jié)構(gòu)這種量級的批量更改（bulk change）才會傳播到持久存儲，并且在系統(tǒng)故障后必須回滾。如圖 5 所示，SAP HANA 的持久性是基于臨時 REDO 日志和短期恢復(fù)或長期備份的 save pointing 的組合實現(xiàn)的。

當一條新數(shù)據(jù)進入系統(tǒng)時，無論是在 L1-delta 還是在 L2-delta （批量插入）進行，都只會為其創(chuàng)建一次 REDO 日志。當一條記錄的新版本進入 L1-delta 時，系統(tǒng)會為該新版本創(chuàng)建日志。從 L1-delta 到 L2-delta 的增量傳播過程中所發(fā)生的數(shù)據(jù)變化不會被寫入至REDO 日志中。反而是字典和 value index（值索引）中的變化會被添加到各個數(shù)據(jù)頁中的數(shù)據(jù)結(jié)構(gòu)中，這些數(shù)據(jù)結(jié)構(gòu)最終被移入至下一個保存點的持久存儲中。顯然，合并事件被寫入日志，以確保重啟后數(shù)據(jù)庫狀態(tài)的一致性。

圖 6 描繪了合并的細節(jié)。字典和值索引這兩種結(jié)構(gòu)都是基于分頁存儲布局（paged storage layout）。該布局由底層存儲子系統(tǒng)進行管理。無論是具有附加條目的現(xiàn)有頁或新頁，但凡是臟頁都會被存儲子系統(tǒng)清理掉。該功能由保存點基礎(chǔ)架構(gòu)（save pointing infrastructure）來控制。盡管 L2-delta 中的數(shù)據(jù)是按列組織的，但是系統(tǒng)可以在單個頁面內(nèi)存儲多個 L2-delta 的片段，以便優(yōu)化存儲器消耗。特別是對于小而寬的表，這一設(shè)計尤為合理。

在保存點之后，REDO 日志可以被截斷。在恢復(fù)過程中，系統(tǒng)重新加載 L2-delta 的最后一個快照。與之類似，main store 的一個新版本會被持久化至穩(wěn)定存儲中，并可用于重新加載統(tǒng)一表的 main store?？傊驗橄惹鞍姹镜挠诚袢匀淮嬖?，無論是 L2-delta 還是main store 的變化都不會寫入日志。傳統(tǒng)的日志方案僅適用于 L1-delta。

3.3 ?總結(jié)

SAP HANA 數(shù)據(jù)庫中的表的物理表示分為三個層級：

????L1-delta：用于高效捕獲插入、更新和刪除請求的行式存儲；????L2-delta：用于將寫優(yōu)化存儲和讀優(yōu)化存儲進行解耦的中間結(jié)構(gòu)，是一個列式存儲；????Main store：該結(jié)構(gòu)不僅非常適合類似于 OLAP 的查詢，并且還使用倒排索引對點查詢性能進行了針對性調(diào)優(yōu)。一條記錄在其“一生”之中，最開始通過異步復(fù)制保存至更新效率最高的存儲中，然后被復(fù)制到讀取效率最高的存儲中度過“余生”。

合并優(yōu)化

統(tǒng)一表方法的基本思想是通過將記錄從寫優(yōu)化的存儲結(jié)構(gòu)以透明的方式傳播至使用 L2-delta 索引的讀優(yōu)化的存儲結(jié)構(gòu)中，從而實現(xiàn)讀寫存儲之間的解耦。雖然從 L1-delta 到 L2-delta 的轉(zhuǎn)換不會對現(xiàn)有的數(shù)據(jù)結(jié)構(gòu)產(chǎn)生太大破壞，但 L2-delta 合并至 main store 的操作需要對表格內(nèi)容進行重大重組。

4.1 經(jīng)典合并

在經(jīng)典合并（classic merge）操作的第一步中，L2-delta 的字典條目會被編譯到 main 的字典中，從而實現(xiàn)為特定列生成一個排序后的新的 main 字典。新字典僅包含新的 main 的有效條目，丟棄所有被刪除和修改過的記錄的條目。按字典順序排序不僅為最佳壓縮提供了先決條件，也為特殊計算符能夠直接處理字典編碼列打下了基礎(chǔ)。

圖7顯示了一次合并步驟涉及到的主要階段。在第一階段，系統(tǒng)基于使用未排序字典的 L2-delta 和使用排序字典的舊 main，生成一個新的排序字典，并保存條目新舊位置的映射。新位置為條目在新字典中的位置；舊位置則為條目在 main 和 L2-delta 內(nèi)的位置（非顯式存儲）。如圖所示，一些條目同時存在于 L2-delta 和 main 的字典中，例如“Los Gatos”；還有一些條目僅出現(xiàn)在一個詞典中，例如“Campbell”在 L2-delta 中的位置為 4，在 main 的字典映射表中的值為 -1。在第二階段，系統(tǒng)會參考現(xiàn)有條目和新增條目在新字典中的位置構(gòu)建新的 main index（主索引）。如圖7 中的示例所示，“Daily City”的條目被轉(zhuǎn)移到新 main 中，位置為 4?！癓os Gatos”也從 L2-delta 中的位置 1 和舊 main 中的位置 5 映射到了新位置 6。新 main（字典和值索引）寫入磁盤，同時舊的數(shù)據(jù)結(jié)構(gòu)被釋放。在任何情況下，系統(tǒng)都必須在主內(nèi)存中保存列（字典和main index）的新舊兩個版本，直到所有引用該列的舊版本的開放事務(wù)的數(shù)據(jù)庫操作都已執(zhí)行完畢。

由于合并操作的初始版（naive version）非常耗費資源，SAP HANA 數(shù)據(jù)庫對其進行了許多優(yōu)化。例如，如果 L2-delta 的字典是 main 的字典的子集，那么會直接跳過用于生成字典的第一階段，從而形成了 main 條目的穩(wěn)定位置。另一種特殊情況是 L2-delta 字典的值大于 main 字典中的值，例如存在增加的時間戳。在這種情況下，如果對字典值進行編碼的位數(shù)（number of bits）足以應(yīng)對擴展基數(shù)（extended cardinality），則 L2-delta 字典可以直接添加到 main 字典中。

SAP HANA 數(shù)據(jù)庫還使用了正交技術(shù)（orthogonal technique）來實現(xiàn)更為復(fù)雜的優(yōu)化，例如下面即將介紹到的重排序合并（re-sorting merge）和部分合并（partial merge）策略。

4.2 重排序合并

L2-delta 和 main 之間的經(jīng)典合并（詳情請參考 4.1）需要條目的新舊位置之間的映射關(guān)系。這些位置用于對位打包值索引（bit-packed value index）內(nèi)的實值（real value）進行編碼，即，用?C?來表示一個列中的值去重后的數(shù)量，系統(tǒng)需要使用 ?ld(C)? 數(shù)量的位（bit）來對該位置進行編碼。合并操作會將舊的 main 值映射到新字典中的位置上（具有相同或增加的位數(shù)），并在新的 value index 的末尾添加 L2-delta 的條目。

合并操作的擴展版本（extended version）旨在重新組織整個表的內(nèi)容，將所有列進行重新布局，以提供更高的壓縮潛能。由于 SAP HANA 數(shù)據(jù)庫列存儲使用了位置尋址方案，因此第 k 條記錄中的值必須位于每一列的第 k 個位置。對表中某列進行重新排序會直接影響表中其他列的壓縮潛能。根據(jù)【9】中討論的概念，系統(tǒng)在創(chuàng)建新的 main 之前，會根據(jù) main 和 L2-delta 結(jié)構(gòu)的統(tǒng)計信息計算列的“最佳”排序順序。

圖 8 展示了必要的數(shù)據(jù)結(jié)構(gòu)（data structure）。除了用于字典的映射表（mapping table）將舊字典位置翻譯成新字典中的位置之外，重排序合并（re-sorting merge）的版本還創(chuàng)建了行位置的映射表，從而能夠在合并和重新排序某行的各個列之后重構(gòu)該行。圖8 顯示了合并過程之前和過程中的同一張表中的列，其中列“City”和“Prod”已經(jīng)合并，其余列（如“Time”）仍然反映合并前的狀態(tài)。因此，main 的舊版條目對應(yīng)于舊字典中的位置，例如“City”列的條目“Los Gatos”在舊字典中用值5 編碼，而在合并后的版本中用值6 編碼。一般來說，在對“City”列進行合并后，新的 main index 顯示新詞典的位置以及對行進行重新排序。如圖 8 中突出顯示的那樣，現(xiàn)在可以在第二個位置找到第7 行?！癙rod”列也被合并，但沒有新建字典，保留了字典位置值。然而“Time”欄還沒有合并，仍然是指舊字典和舊的排序順序。如果需要具有已經(jīng)合并的列的行構(gòu)造，則對尚未合并的列的任何訪問都需要通過行位置映射表采取額外步驟。在所有列的合并完成之后，可以消除行位置映射表。雖然系統(tǒng)可以通過“堆疊（stacking）”行位置映射表在概念上延遲不經(jīng)常訪問的列的合并，但是系統(tǒng)總是在開始新的合并生成之前完成整個表的合并操作。

因此，是否使用重新排序還需要基于成本考慮，用于平衡在所有列的合并期間用于列訪問的額外位置映射的開銷，以及由此產(chǎn)生的更高壓縮率的可能性。將合并應(yīng)用于各個列的排序標準還取決于多個因素，例如點對范圍訪問的比率、壓縮潛力的提高等。

4.3 部分合并

經(jīng)典合并或重排合并的主要缺點在于創(chuàng)建一個新版本的 main 所帶來的開銷。對于大型表或分區(qū)，要計算出一個新的字典并重新生成 main index 的確會占用額外的 CPU 和磁盤資源。而部分合并（partial merge）則通過使用以前的算法來緩和這個問題。部分合并策略體現(xiàn)了在字典中新條目數(shù)量較少的情況下，列的最佳壓縮潛能。

部分合并的核心思想是將 main 拆分成兩個或更多的獨立 main：

????消極 main（active main）：main store 中的穩(wěn)定部分，通常不參與合并過程。

????積極 main（passive main）：列中可動態(tài)伸縮、參與和 L2-delta 的合并的部分。

從概念上來看，部分合并策略中的合并間隔始于一個空的積極 main。消極 main 通過分類詞典和相應(yīng)的值索引（values index）來反映常規(guī) main 結(jié)構(gòu)。當一個合并操作開始執(zhí)行時，L2-delta 將合并至仍然為空的積極 main，而消極 main 保持不變。與完全合并（full merge）相比，部分合并有一個細微的不同之處。積極 main 的詞典以 n+1 的詞典位置值開始，而消極 main 的詞典則以 n 結(jié)束。盡管系統(tǒng)現(xiàn)在有兩個帶有本地排序字典的 main 結(jié)構(gòu)，但是各個 main value index 結(jié)構(gòu)的編碼并不重疊。顯然，積極 main 的字典只保存消極 main 的字典中尚未涵蓋的新值。

圖10 顯示了部分合并后一個消極 main 和一個積極 main 的示例情況。積極 main 的字典編碼從 n+1 = 6 開始，從而可以延續(xù)消極 main 的編碼方案。雖然消極 main 字典對應(yīng)的value index 結(jié)構(gòu)僅保存對消極main 字典中條目的引用，但是積極 main 字典的 value index 也可以展示main 字典的編碼值，使得積極 main 字典依賴于消極 main 字典。

點訪問（point access）在消極字典中被解析。如果找到了所請求的值，則相應(yīng)的位置被用作消極和積極 main 的 value index 的編碼值。執(zhí)行并行掃描以找到相應(yīng)的條目。但是，如果沒有找到所請求的值，則查詢積極 main 的字典。如果該值存在，則只掃描積極main 的 value index，識別出所需的行的位置。對于范圍訪問（range access），范圍會在積極 main 和消極 main 的字典中解析，并且范圍掃描在兩個 main 上被執(zhí)行。對于積極 main 的字典，掃描分為兩個部分范圍（partial range），一個是消極 main 的字典的編碼范圍值，另一個是積極 main 的字典的編碼范圍值。圖 10 展示了值在C%和L%之間的范圍查詢的合并過程。為了保證事務(wù)的一致性，查詢處理還要求與 L1-delta 和 L2-delta 進行類似的合并。

當系統(tǒng)運行時，積極 main 可能會動態(tài)地收縮和增長，直到一次完全合并被安排好。這種做法的主要優(yōu)點是將完全合并延遲到負載較低的時候執(zhí)行，并且降低了 L2-delta 到 main 或者積極 main 的合并成本。此外，該優(yōu)化策略可以通過以下方式部署為經(jīng)典合并的方案：將積極 main 的最大尺寸設(shè)置為 0 來強制在每個步驟中進行（經(jīng)典）完全合并。顯然，該過程可以輕松地擴展到多個消極 main 結(jié)構(gòu)，這些消極 main 結(jié)構(gòu)形成了和本地字典的依賴性相關(guān)的邏輯鏈。這種配置非常適合那些字典變化極少或者字典很穩(wěn)定的列（例如“Customer”表中的“Country”列）。不過對于大多數(shù)列來說，系統(tǒng)將僅維持一個消極 main。

從概念上來講，部分合并優(yōu)化策略在 SAP HANA 數(shù)據(jù)庫統(tǒng)一表概念的記錄生命周期中增加了一個步驟。越接近傳輸?shù)哪┒耍瑢τ涗浀闹亟M就越復(fù)雜、越耗費時間和資源，最終形成以傳統(tǒng)列存儲的高度壓縮和讀取優(yōu)化格式。此外，SAP HANA 數(shù)據(jù)庫提供了歷史表（historic table）的概念，可以透明地將記錄的歷史版本移動到單獨的表結(jié)構(gòu)中。因此，在建表時，就必須將表定義為“historic”類型。此外，從應(yīng)用的角度來看，分區(qū)（partitioning）概念的應(yīng)用可以將最近的數(shù)據(jù)集與穩(wěn)定的數(shù)據(jù)集分隔開來。

4.4 總結(jié)

如上所述，SAP HANA 數(shù)據(jù)庫通過對記錄進行生命周期管理，為事務(wù)型和分析型工作負載提供高效訪問。圖 11 對比了所討論的不同存儲格式和傳播的特征。L1-delta 針對更新密集型工作負載進行了優(yōu)化，并且可以頻繁地將增量數(shù)據(jù)合并到 L2-delta 結(jié)構(gòu)中。L2-delta 結(jié)構(gòu)已經(jīng)針對讀取操作進行了很好的調(diào)優(yōu)，但是與高度讀取優(yōu)化的 main 結(jié)構(gòu)相比，它產(chǎn)生了更大的內(nèi)存占用。然而，L2-delta 特別適合作為 L1-delta 行或者批量插入的目標。如前所述，main 結(jié)構(gòu)可以被分為積極 main 和消極 main，表現(xiàn)出極高的壓縮率，并且針對基于掃描的查詢模式（query pattern）進行了優(yōu)化。由于資源密集型重組任務(wù)，與積極 main 結(jié)構(gòu)的合并，尤其是創(chuàng)建新的 main 結(jié)構(gòu)的完全合并的頻率非常低。相比之下，L1-delta 到 L2-delta 的合并可以通過將數(shù)據(jù)附加到 L2-delta 的字典和 value index 中遞增進行。

結(jié)論

眾所周知，列存儲系統(tǒng)可以為 OLAP 型工作負載提供卓越的性能。通常而言，列式數(shù)據(jù)布局極其適合那些涉及數(shù)百萬行卻僅僅需要其中幾列數(shù)據(jù)的聚合查詢。但是，使用不同的系統(tǒng)處理 OLAP 和 OLTP 查詢的方案不再滿足現(xiàn)代業(yè)務(wù)應(yīng)用的最新需求。主要原因可歸納為兩方面：一方面，運營系統(tǒng)將越來越多的即時業(yè)務(wù)決策統(tǒng)計操作嵌入到個人業(yè)務(wù)流程中；另一方面，傳統(tǒng)的數(shù)據(jù)倉庫基礎(chǔ)設(shè)施需要捕獲事務(wù)流（transactions feed）以進行實時分析。在本文中，我們基于 SAP HANA 數(shù)據(jù)庫的經(jīng)典列存儲架構(gòu)，概述了涵蓋查詢轉(zhuǎn)換、計劃生成和不同專用引擎交互模型的查詢處理環(huán)境。此外，我們更詳細地解釋了通用統(tǒng)一表數(shù)據(jù)結(jié)構(gòu)。這種由不同狀態(tài)組成的數(shù)據(jù)結(jié)構(gòu)為消費查詢引擎提供了一個通用接口。本文的總體目標是介紹一些在 SAP HANA 數(shù)據(jù)庫中實施的優(yōu)化措施，使得列存儲適用于大規(guī)模事務(wù)處理，糾正人們關(guān)于列存技術(shù)僅用于 OLAP 型工作負載的偏見。

致謝

我們真誠感謝位于沃爾多夫、首爾、柏林和帕洛阿托的 SAP HANA 數(shù)據(jù)庫團隊，感謝他們讓 HANA 的故事成為現(xiàn)實。