翻譯：王學(xué)姣

審校：李浩，宇亭

責(zé)編：宇亭

導(dǎo)語

本篇是StoneDB學(xué)術(shù)分享會專欄的第六篇，在上一期里，我們分享了奠定 HTAP 數(shù)據(jù)庫基礎(chǔ)的現(xiàn)象級論文《A Common Database Approach for OLTP and OLAP Using an In-Memory Column DataBase》，如果說，上一期 SAP 在 2009 年的論文只是初步的提出了一個看起來很強(qiáng)悍并且可行的理論，那么三年后，SAP 在 2012 年發(fā)表的這篇《The SAP HANA Database – An Architecture Overview》，則用一個實(shí)打?qū)嵉募軜?gòu)體系向世界宣布了一體化 HTAP 數(shù)據(jù)庫——SAP HANA 的強(qiáng)大（我們已經(jīng)不是吹概念了，而是實(shí)現(xiàn)了有木有，直接給全世界看我們的架構(gòu)體系啦~）

這下子，信仰“One Size Doesn't Fit All”的學(xué)者和商業(yè)團(tuán)隊(duì)們可慌了神，說好的，OLAP 數(shù)據(jù)庫和 OLTP 數(shù)據(jù)庫要分開賣的呢？你們 SAP 怎么這么不講武德?。恳粋€內(nèi)存數(shù)據(jù)庫非要來搶我們兩個派系的生意？

不過，市場并不會接受吐槽，SAP HANA 以其高水平的研發(fā)團(tuán)隊(duì)、極致的性能和獨(dú)特的營銷技巧在數(shù)據(jù)庫行業(yè)開始異軍突起~

摘要

隨著企業(yè)發(fā)展，企業(yè)級應(yīng)用對數(shù)據(jù)庫的要求變得越來越嚴(yán)苛。這些應(yīng)用程序要求數(shù)據(jù)庫系統(tǒng)能基于事務(wù)數(shù)據(jù)生成復(fù)雜的報(bào)告，且要保證多達(dá)上萬的用戶能夠同時對相同數(shù)據(jù)進(jìn)行讀取、更新操作。SAP HANA 數(shù)據(jù)庫旨在使用一個數(shù)據(jù)庫管理系統(tǒng)同時處理事務(wù)性和分析性工作負(fù)載。為了實(shí)現(xiàn)這一目標(biāo)，我們設(shè)計(jì)了一個列存引擎。該列存引擎利用現(xiàn)代硬件（多 CPU 內(nèi)核、大容量主內(nèi)存和緩存），支持?jǐn)?shù)據(jù)壓縮、數(shù)據(jù)庫內(nèi)核并行最大化，提供層次結(jié)構(gòu)（hierarchy）專用的數(shù)據(jù)結(jié)構(gòu)、用于特定領(lǐng)域的語言支持等企業(yè)應(yīng)用所需的數(shù)據(jù)庫擴(kuò)展。在本文中，我們將重點(diǎn)介紹 SAP HANA 數(shù)據(jù)庫的架構(gòu)。我們還會公布在真實(shí)的企業(yè)應(yīng)用場景中通過 SAP HANA 數(shù)據(jù)庫收集的反饋和洞察。

簡介

關(guān)于企業(yè)數(shù)據(jù)的全方位解讀已經(jīng)成為每個企業(yè)的核心資產(chǎn)（小編注：這就是數(shù)據(jù)價值）。企業(yè)數(shù)據(jù)通過各種渠道，如以 SAP ERP 為代表的企業(yè)資源規(guī)劃系統(tǒng)、生產(chǎn)環(huán)境中使用的傳感器或 Web 界面，成批或逐筆輸入。舉個例子，銷售過程中會產(chǎn)生訂單創(chuàng)建、修改和刪除等操作。這些訂單是生產(chǎn)計(jì)劃和交付的基礎(chǔ)。因此，銷售過程往往會針對記錄進(jìn)行查找、插入和更新操作。這類數(shù)據(jù)處理通常被稱為聯(lián)機(jī)事務(wù)處理（Online Transaction Processing，OLTP）。OLTP 是當(dāng)前基于磁盤（disk-based）的行存（row-oriented）數(shù)據(jù)庫系統(tǒng)的強(qiáng)項(xiàng)。（小編注：MySQL 就是這種基于磁盤和行存的 OLTP 數(shù)據(jù)庫）

根據(jù)我們的仔細(xì)觀察，一個看似非常簡單的銷售過程可能包含大量復(fù)雜的分析處理。例如，作為銷售流程的一部分，檢查交付產(chǎn)品的可用性需要匯總預(yù)期銷售額、預(yù)期交付量和生產(chǎn)批次的完成情況，以及將最終庫存與客戶需求進(jìn)行比較。類似地，銷售組織將對基于最近的銷售和成本信息生成的盈利能力度量指標(biāo)感興趣，因?yàn)檫@個指標(biāo)方便他們進(jìn)行銷售策略的規(guī)劃。以上這類工作負(fù)載被認(rèn)為是聯(lián)機(jī)分析處理（Online Analytical Processing，OLAP）。通過將數(shù)據(jù)復(fù)制到讀取優(yōu)化的數(shù)據(jù)倉庫中，可以執(zhí)行周期性任務(wù)，如季度末結(jié)算或客戶細(xì)分。對于這些類型的報(bào)告，列存（column-stores）變得越來越流行[3]。

此外，分析型應(yīng)用需要過程邏輯，而過程邏輯，例如根據(jù)銷售數(shù)量對不同產(chǎn)品進(jìn)行聚類（clustering）或?qū)蛻粜袨檫M(jìn)行分類，并不能用簡單的 SQL 來表達(dá)。常規(guī)的做法是將所有需要的數(shù)據(jù)從數(shù)據(jù)庫轉(zhuǎn)移到應(yīng)用上，然后在應(yīng)用上進(jìn)行處理。因此，優(yōu)化的數(shù)據(jù)結(jié)構(gòu)和元數(shù)據(jù)不能被使用，而且如果后續(xù)業(yè)務(wù)流程需要用到相關(guān)中間結(jié)果，中間結(jié)果還必須回傳到數(shù)據(jù)庫中。

理想情況下，數(shù)據(jù)庫應(yīng)該能夠在單個系統(tǒng)中處理所有上述工作負(fù)載和特定應(yīng)用（Application-specific）的邏輯[13]。這一發(fā)現(xiàn)促使了我們開發(fā)了 SAP HANA DB。SAP HANA DB 的 In-Memory 列式存儲基于 SAP TREX 文本引擎[15]和 SAP BI 加速器（SAP BIA）[10]，可快速處理 OLAP 查詢。SAP HANA DB 的高性能 In-Memory 行式存儲源自專為 OLTP 工作負(fù)載而設(shè)計(jì)的 P*Time[2]。SAP HANA DB 的持久性則來源于 SAP MaxDB 數(shù)據(jù)庫系統(tǒng)的成熟技術(shù)，包括日志、恢復(fù)和持久存儲特性。截至目前，SAP HANA DB 已作為 SAP HANA 設(shè)備的一部分上市。

在第2章中，我們將簡要介紹 SAP HANA DB 架構(gòu)中的各組件。第3章討論了執(zhí)行分析型應(yīng)用特定邏輯的能力。第4章簡述了 SAP HANA DB 如何實(shí)現(xiàn)傳統(tǒng)數(shù)據(jù)倉庫工作負(fù)載加速處理。我們在第5章討論了如何應(yīng)對企業(yè)資源規(guī)劃系統(tǒng)中事務(wù)型工作負(fù)載的挑戰(zhàn)，并在第6章總結(jié)了我們在 SAP HANA DB 上的工作。

SAP HANA DB 架構(gòu)

SAP HANA DB 的總體目標(biāo)是提供一個以內(nèi)存為中心的數(shù)據(jù)管理平臺，以支持傳統(tǒng)應(yīng)用的純 SQL，以及一個更具表現(xiàn)力的交互模型，專門用于滿足 SAP 應(yīng)用的需求[4，14]。此外，該系統(tǒng)被設(shè)計(jì)為提供完整的事務(wù)行為，從而實(shí)現(xiàn)對交互式業(yè)務(wù)應(yīng)用的支持。最后，SAP HANA DB 的設(shè)計(jì)特別重視并行化，從線程級并行、到內(nèi)核級并行、再到跨機(jī)器的高度分布式設(shè)置。

圖1：SAP HANA DB 架構(gòu)概述

圖1展示了的 SAP HANA DB 架構(gòu)。SAP HANA DB 的核心是一組 In-Memory 處理引擎。在行列混存引擎中，關(guān)系數(shù)據(jù)存儲在采用列布局或者行布局的表中，并且可以從一種布局轉(zhuǎn)換到另一種布局，以允許查詢表達(dá)式包含兩種布局的表。圖形數(shù)據(jù)和文本數(shù)據(jù)則分別存儲在圖形引擎和文本引擎中。得益于可擴(kuò)展的架構(gòu)，SAP HANA DB 還能支持更多的引擎。只要可用空間足夠，所有引擎都會將所有數(shù)據(jù)保存在主內(nèi)存中。SAP HANA DB 一個特有特性是所有數(shù)據(jù)結(jié)構(gòu)都針對緩存效率進(jìn)行了優(yōu)化，而不是針對傳統(tǒng)磁盤數(shù)據(jù)塊的組織形式進(jìn)行優(yōu)化。此外，這些引擎采用了多種多樣的壓縮方案來實(shí)現(xiàn)對數(shù)據(jù)的靈活壓縮。當(dāng)可用主內(nèi)存達(dá)到最低閾值時，在應(yīng)用語義的控制下，表或分區(qū)等整個數(shù)據(jù)對象會從主內(nèi)存中卸載掉，并在再次需要時重新加載至主內(nèi)存中。

從應(yīng)用的角度來看，SAP HANA DB 提供了多種接口，例如用于通用數(shù)據(jù)管理功能的標(biāo)準(zhǔn) SQL，或者 SQLScript（參見第3章）和 MDX 等更專業(yè)的語言。SQL 查詢由計(jì)劃生成器翻譯成執(zhí)行計(jì)劃，然后由執(zhí)行引擎進(jìn)行優(yōu)化和執(zhí)行。來自其他接口的查詢最終也被轉(zhuǎn)換為相同類型的執(zhí)行計(jì)劃，并在相同的引擎中執(zhí)行，但首先會在計(jì)算引擎中用更具表達(dá)力的抽象數(shù)據(jù)流模型來進(jìn)行描述。執(zhí)行引擎無需考慮外部接口，可以使用所有處理引擎并且支持跨節(jié)點(diǎn)分布式執(zhí)行。

與傳統(tǒng)數(shù)據(jù)庫系統(tǒng)一樣，SAP HANA DB 提供用于管理查詢執(zhí)行的組件。會話管理器（session manager）控制著數(shù)據(jù)庫層和應(yīng)用層之間的所有連接，而授權(quán)管理器（authorization manager）用于管理用戶權(quán)限。事務(wù)管理器（transaction manager）實(shí)現(xiàn)快照隔離或更低的隔離級別，即使在分布式環(huán)境中也是如此。元數(shù)據(jù)管理器（metadata manager）存儲用于描述表和其他數(shù)據(jù)結(jié)構(gòu)的數(shù)據(jù)。和事務(wù)管理器一樣，出于分布式考量，元數(shù)據(jù)管理器由本地部分和全局部分組成。

為了保證高性能，幾乎所有數(shù)據(jù)都由處理引擎保存在主內(nèi)存中，但是數(shù)據(jù)也必須持久化至數(shù)據(jù)持久層，以便在系統(tǒng)顯示關(guān)閉或出現(xiàn)故障后重啟時進(jìn)行備份恢復(fù)。數(shù)據(jù)更新按需記錄日志，以便數(shù)據(jù)能夠恢復(fù)到數(shù)據(jù)庫的最后提交狀態(tài)。并且在保存點(diǎn)（savepoint）和合并操作期間，整個數(shù)據(jù)對象定期持久化保存至數(shù)據(jù)存儲（data storage）中（詳情請參見第4章）。

支持分析型應(yīng)用

SAP HANA DB 的一項(xiàng)關(guān)鍵資產(chǎn)是其在數(shù)據(jù)庫內(nèi)核中執(zhí)行業(yè)務(wù)和應(yīng)用邏輯的能力。為此，計(jì)算引擎提供了計(jì)算模型。計(jì)算模型是邏輯執(zhí)行計(jì)劃的抽象表達(dá)。比如我們將 SQLScript 編譯到了計(jì)算模型中。SQLScript 是一種用于將應(yīng)用邏輯表示為數(shù)據(jù)流或使用過程邏輯的聲明性和可優(yōu)化語言。沿著這個思路，只要是編譯器能夠生成中間計(jì)算模型表示的應(yīng)用于特定領(lǐng)域的語言，我們都可以提供支持。

計(jì)算模型的原語構(gòu)成了一個邏輯執(zhí)行計(jì)劃。該計(jì)劃由一個非循環(huán)數(shù)據(jù)流圖形組成，圖中的節(jié)點(diǎn)表示操作符（計(jì)劃操作），途中的邊緣反映數(shù)據(jù)流（計(jì)劃數(shù)據(jù)）。SAP HANA DB 使用了一類操作符來實(shí)現(xiàn)標(biāo)準(zhǔn)的關(guān)系操作符，如連接（join）和選擇（selection）。此外，SAP HANA DB 支持多種特殊運(yùn)算符，用于在數(shù)據(jù)庫內(nèi)核中實(shí)現(xiàn)針對特定應(yīng)用（application-specific）的組件。幾乎所有這些操作符都只能加速數(shù)據(jù)處理，因?yàn)樗鼈兝昧肆袛?shù)據(jù)布局。而通過在計(jì)算引擎中實(shí)現(xiàn)特殊運(yùn)算符，可以實(shí)現(xiàn)對多個應(yīng)用域的支持：

• Statistical Algorithms：可以掛載到計(jì)算模型上，從而可以在相關(guān)的 R 運(yùn)行時內(nèi)執(zhí)行復(fù)雜的統(tǒng)計(jì)計(jì)算。這包括不同的統(tǒng)計(jì)方法，如線性和非線性模型、統(tǒng)計(jì)測試、時間序列分析、分類和聚類。同時，計(jì)算模型允許利用數(shù)據(jù)庫內(nèi)核中預(yù)處理和后處理大數(shù)據(jù)的能力，從而將統(tǒng)計(jì)算法與數(shù)據(jù)庫操作結(jié)合在一起[5]。

• Planning：提供了一組常用的通用計(jì)劃函數(shù)，允許直接在數(shù)據(jù)庫中建模和執(zhí)行復(fù)雜的計(jì)劃場景。Planning 的邏輯由計(jì)算引擎的數(shù)據(jù)流運(yùn)算符來進(jìn)行表達(dá)。此外，特殊運(yùn)算符執(zhí)行特定的計(jì)劃算法，如分解和自定義公式[7，8]。

• Other Special Operators：由計(jì)算引擎提供，包括需要復(fù)雜運(yùn)算的業(yè)務(wù)邏輯。這些運(yùn)算很難使用 SQL 進(jìn)行有效實(shí)現(xiàn)，例如貨幣兌換。另一個例子是描述諸如企業(yè)人力資本管理中雇員和相關(guān)信息之間的關(guān)系的大型層次結(jié)構(gòu)。在這里，SAP HANA DB 提供了特定應(yīng)用的操作符，利用可替代的內(nèi)部數(shù)據(jù)結(jié)構(gòu)來實(shí)現(xiàn)即時返回關(guān)于層次結(jié)構(gòu)的查詢結(jié)果。

特定的計(jì)算模型或邏輯執(zhí)行計(jì)劃一旦通過 SQLScript 或其他方式提交到 SAP HANA DB，就可以像訪問數(shù)據(jù)庫視圖一樣被訪問，從而使計(jì)算模型成為一種參數(shù)化視圖。使用這種視圖的查詢會調(diào)用數(shù)據(jù)庫計(jì)劃執(zhí)行（database plan exectuion）來處理執(zhí)行計(jì)劃，而執(zhí)行計(jì)劃派生自計(jì)算模型提供的邏輯數(shù)據(jù)流描述。如果計(jì)算模型包含獨(dú)立的數(shù)據(jù)流路徑，則派生的執(zhí)行計(jì)劃隱式包含運(yùn)算符間并行執(zhí)行（inter-operator parallel execution）。此功能的實(shí)現(xiàn)歸功于 SQLScript 和編譯到計(jì)算模型中的特定域的語言。

分析型查詢處理

眾所周知，列式存儲非常適合用于處理對大量數(shù)據(jù)進(jìn)行的分析型查詢[1]。為了保證讀操作的高性能，SAP HANA DB 的列式存儲在使用高效的壓縮方案之外，還結(jié)合了緩存感知和并行算法。每一列都基于排序字典被壓縮，即每一個值都被映射到一個整數(shù)值（valueID）。此外，這些 valueID 還將進(jìn)行位壓縮（bit-packing）和壓縮（compression）。通過游程編碼（RLE）、稀疏編碼或聚類編碼[11，12]等方式對表中的行進(jìn)行重新排序可以實(shí)現(xiàn)對表中的列進(jìn)行最有效的壓縮。數(shù)據(jù)壓縮不僅使得單個節(jié)點(diǎn)可以保存更多的數(shù)據(jù)，同時還可以利用諸如 RLE 進(jìn)行聚合計(jì)算等方式來提升查詢處理速度。通過對直接作用于壓縮數(shù)據(jù)的 SIMD 算法進(jìn)行極致利用來加速掃描[16]。

由于在描述的布局中，單次更新的開銷很大，所以每個表都有一個增量存儲（delta storage）用于實(shí)現(xiàn)高更新率和高性能讀取之間的平衡。我們還使用了字典壓縮，但是字典存儲在緩存敏感的B+-樹（CSB+-Tree）中。增量存儲會定期合并到主數(shù)據(jù)存儲（main data storage）中。為了最小化表被鎖定的時間，當(dāng)增量合并開始時，寫操作會被重定向到新的增量存儲上。在合并完成前，讀操作會訪問新增量存儲、舊增量存儲以及就舊主數(shù)據(jù)存儲[9]。

查詢執(zhí)行通過使用操作符內(nèi)并行性來利用節(jié)點(diǎn)內(nèi)不斷增加的可用執(zhí)行線程數(shù)量。例如，分組操作幾乎與線程數(shù)量成線性關(guān)系，直到 CPU 達(dá)到飽和。此外，SAP HANA DB 還利用了查詢執(zhí)行計(jì)劃內(nèi)部以及跨內(nèi)核和跨節(jié)點(diǎn)的并行性。大表可以通過各種分區(qū)標(biāo)準(zhǔn)進(jìn)行分區(qū)。分區(qū)后的各表分區(qū)或者整個表可以被分配至環(huán)境中的不同節(jié)點(diǎn)上[10]。如果運(yùn)算符可以獨(dú)立處理，執(zhí)行引擎會并行調(diào)度這些運(yùn)算符并且盡可能在保存相關(guān)數(shù)據(jù)的節(jié)點(diǎn)上執(zhí)行這些運(yùn)算符。在工作負(fù)載變化的情況下，且數(shù)據(jù)庫支持查詢和更新的前提下，表的分區(qū)方案以及表至節(jié)點(diǎn)的分配可根據(jù)工作負(fù)載做調(diào)整適配。當(dāng) JOIN 查詢涉及跨節(jié)點(diǎn)存儲的表時，使用 semi-join reduction（半連接縮減）進(jìn)行處理[6]。

事務(wù)型查詢處理

很明顯，列式存儲非常適合 OLAP 工作負(fù)載。并且，我們認(rèn)為列式存儲也同樣可以用于處理 OLTP 工作負(fù)載，尤其是在 ERP 系統(tǒng)中[9]，具體原因如下：

1. OLTP 場景可以極大地受益于列式存儲中提供的壓縮方案：在像 SAP ERP 這樣高度可定制的系統(tǒng)中，許多列并沒有被使用，只包含默認(rèn)值或者為空。并且還有一些列具有很小的域，例如狀態(tài)標(biāo)志（status flag）。在這兩種情況下，數(shù)據(jù)壓縮都非常高效，這對于 OLTP 場景來說是一個決定性的優(yōu)勢：通過減少內(nèi)存消耗，所需的存儲變少，從而減少了節(jié)點(diǎn)的開銷。此外，壓縮還會降低內(nèi)存帶寬使用率。

2. 與 TPC-C 等標(biāo)準(zhǔn)基準(zhǔn)測試相比，實(shí)際場景中的事務(wù)型工作負(fù)載的讀操作比例更大。因此，讀優(yōu)化的面向列的存儲布局可能比基準(zhǔn)建議更適合 OLTP 工作負(fù)載。

3. 列式存儲通常遵循簡單的“僅追加（append-only）”方案：當(dāng)對一個行進(jìn)行更新操作時，當(dāng)前版本失效，并追加新版本。這種方案既不需要重新排序也不需要對值進(jìn)行編碼，比就地更新（in-place update）簡單。

4. 列式存儲極大減少了對索引的需求：事實(shí)上，現(xiàn)代硬件上的列式存儲的高掃描性能允許我們只為主鍵、具有唯一約束的列和頻繁連接的列建立索引。在其他情況下，即使沒有索引，列式存儲也能提供足夠好的掃描性能，尤其是在多達(dá)幾十萬行的小表或小分區(qū)中。其優(yōu)點(diǎn)包括大大簡化了物理數(shù)據(jù)庫設(shè)計(jì)，減少了主內(nèi)存消耗，并消除了索引維護(hù)工作，從而提高了整體查詢吞吐量。

當(dāng)然，除了上述優(yōu)勢以外，列式存儲在處理 OLTP 工作負(fù)載時，還面臨著以下挑戰(zhàn)：一個挑戰(zhàn)直接來自基于列的數(shù)據(jù)布局。盡管基于列的數(shù)據(jù)布局支持更細(xì)粒度的數(shù)據(jù)訪問模式，但為處理大量列而為每一列分配內(nèi)存會導(dǎo)致顯著的性能開銷，例如，當(dāng)構(gòu)造由100列或更多列組成的單個結(jié)果行（result row）時。到目前為止，只要有助于降低性能開銷，SAP HANA DB 就會將分配給多各列的內(nèi)存合并到一起。

作為一個主要挑戰(zhàn)，我們看到在 ERP 應(yīng)用中，大量的更新是并發(fā)執(zhí)行的。與批量更新的數(shù)據(jù)倉庫相反，單個記錄的頻繁更新會不斷地向增量存儲中添加新的實(shí)體，從而導(dǎo)致了從增量存儲到主數(shù)據(jù)存儲的頻繁合并。合并操作是 CPU 和內(nèi)存密集型操作。由此帶來的挑戰(zhàn)是如何最大限度地減少其對并發(fā)處理的請求的影響。SAP HANA 通過精心設(shè)計(jì)的調(diào)度和并行化解決了這個問題[9]。

小結(jié)

在本文中，我們總結(jié)了 SAP HANA DB 的設(shè)計(jì)和實(shí)施指導(dǎo)原則。我們的分析表明，使用列引擎的 In-Memory 處理是同時處理分析型和事務(wù)型工作負(fù)載的最有前景的方法。對業(yè)務(wù)應(yīng)用需求和兩種工作負(fù)載的強(qiáng)大支持使 SAP HANA DB 有別于其他列存儲。畢竟，大多數(shù) OLAP 和 OLTP 操作都是讀操作，這些操作都將受益于按列進(jìn)行的數(shù)據(jù)壓縮。此外，列存儲僅需要極少量的索引，簡化了物理數(shù)據(jù)庫設(shè)計(jì)并減少了內(nèi)存消耗。為了進(jìn)一步將當(dāng)今企業(yè)應(yīng)用產(chǎn)生的大量數(shù)據(jù)保存在內(nèi)存中，SAP HANA DB 允許將數(shù)據(jù)分布在集群內(nèi)的節(jié)點(diǎn)中。因此，在對大型數(shù)據(jù)集進(jìn)行分析處理時，SAP HANA DB比傳統(tǒng)數(shù)據(jù)庫系統(tǒng)快幾個數(shù)量級。

然而，In-Memory 分布式列存儲對數(shù)據(jù)庫開發(fā)提出了很多挑戰(zhàn)，包括對分區(qū)的要求、對分布式事務(wù)的支持以及將更新合并到讀優(yōu)化的存儲布局中的過程設(shè)計(jì)。但是這些挑戰(zhàn)只是冰山一角，因?yàn)楫?dāng)我們考慮到云上的數(shù)據(jù)密集型應(yīng)用、彈性要求、多租戶或科學(xué)計(jì)算時，更多的挑戰(zhàn)還在前方等著我們?nèi)ソ鉀Q。

參考文獻(xiàn)

[1]D. J. Abadi, S. R. Madden, and N. Hachem. Column-Stores vs. Row-Stores: How Different Are They Really? In Proc. SIGMOD, pages 967–980, 2008.

[2]S. K. Cha and C. Song. P*TIME: Highly Scalable OLTP DBMS for Managing Update-Intensive Stream Workload. In Proc.VLDB, pages 1033–1044, 2004.

[3]S. Chaudhuri, U. Dayal, and V. Narasayya. An Overview of Business Intelligence Technology. CACM, 54(8):88–98, 2011.

[4]F. Fa¨rber, S. K. Cha, ?J. Primsch, ?C. Bornho¨vd, ?S. Sigg, ?and W. Lehner. ? SAP HANA Database - Data Management for Modern Business Applications. SIGMOD Record, 40(4):45–51, 2011.

[5]P. Gro?e, W. Lehner, T. Weichert, F. Fa¨rber, and W.-S. Li. ?Bridging Two Worlds with RICE – Integrating R into the SAP In-Memory Computing Engine. Proc. VLDB, 4(12):1307–1317, 2011.

[6]G. Hill and A. Ross. Reducing outer joins. VLDB Journal, 18(3):599–610, 2009.

[7]B. Ja¨cksch, F. Fa¨rber, and W. Lehner. ? Cherry Picking in Database Languages. ? In Proc.IDEAS, pages 117–122, 2010.

[8]B. Ja¨cksch, W. Lehner, and F. Fa¨rber. A Plan for OLAP. In Proc.EDBT, pages 681–686, 2010.

[9]J. Kru¨ger, C. Kim, M. Grund, N. Satish, D. Schwalb, J. Chhugani, P. Dubey, H. Plattner, and A. Zeier. Fast Updates on Read-Optimized Databases Using Multi-Core CPUs. Proc.VLDB, 5(1):61–72, 2011.

[10]T. Legler, W. Lehner, and A. Ross. Data Mining with the SAP NetWeaver BI Accelerator. In Proc.VLDB, pages 1059–1068, 2006.

[11]C. Lemke, K.-U. Sattler, F. Fa¨rber, and A. Zeier. ?Speeding Up Queries in Column Stores – A Case for Compression. In Proc.DaWak, pages 117–129, 2010.

[12]M. Paradies, C. Lemke, H. Plattner, W. Lehner, K.-U. Sattler, A. Zeier, and J. Kru¨ger. ? How to Juggle Columns: An Entropy-Based Approach for Table Compression. In Proc.IDEAS, pages 205–215, 2010.

[13]H. Plattner. A Common Database Approach for OLTP and OLAP Using an In-Memory Column Database. In Proc.SIGMOD, pages 1–2, 2009.

[14]H. Plattner and A. Zeier. In-Memory Data Management: An Inflection Point for Enterprise Applications. Springer, Berlin Heidelberg, 2011.

[15]F. Transier and P. Sanders. Engineering Basic Algorithms of an In-Memory Text Search Engine. ACM TOIS, 29(1):2, 2010.

[16]T. Willhalm, N. Popovici, Y. Boshmaf, H. Plattner, A. Zeier, and J. Schaffner. SIMD-Scan: Ultra Fast in-Memory Table Scan using on- Chip Vector Processing Units. Proc.VLDB, 2(1):385–394, 2009.