審校：李浩、宇亭
設(shè)計(jì)：Yeekin
責(zé)編：宇亭
導(dǎo)語(yǔ)
本篇是StoneDB學(xué)術(shù)分享會(huì)專(zhuān)欄的第八篇，在上一期里，我們分享了SAP 發(fā)表的《Efficient Transaction Processing in SAP HANA Database – The End of a Column Store Myth》，主要介紹了 SAP HANA 數(shù)據(jù)庫(kù)如何通過(guò)列式存儲(chǔ)實(shí)現(xiàn)同時(shí)在分析型和事務(wù)型工作負(fù)載環(huán)境中進(jìn)行高效工作，從而號(hào)召大家終結(jié)對(duì)列式存儲(chǔ)的偏見(jiàn)。
有心的同學(xué)可能會(huì)注意到，我們接連三期分享了 SAP 發(fā)布的論文，都是講SAP 如何實(shí)現(xiàn) HTAP 系統(tǒng)架構(gòu)的，而且，似乎SAP 非常想向大家證明：我一個(gè)數(shù)據(jù)庫(kù)是可以做到既能處理事務(wù)（OLTP）又能處理分析（OLAP）的，而且性能還挺好，幾乎完美。
不過(guò)，這好像就是在說(shuō)：咱們 SAP 的 HANA 是可以做到 “One Size Fits All” 的！看起來(lái)是和咱們今天的標(biāo)題宣戰(zhàn)呢~
沒(méi)錯(cuò)，SAP 宣戰(zhàn)的不是別人，正是數(shù)據(jù)庫(kù)領(lǐng)域的祖師爺級(jí)別人物 Michael Stonebraker 先生（順帶一提，我們之所以叫 StoneDB 其實(shí)有一層含義就是為了致敬 Stonebraker 先生），在 2005 年的 ICDE 上，Stonebraker 發(fā)表了一篇名為《“One Size Fits All”: An Idea Whose Time Has Come and Gone》的文章，正式向?qū)W術(shù)界和工業(yè)界宣布：“One Size Fits All” 的理論過(guò)時(shí)了哈，一種類(lèi)型一個(gè)數(shù)據(jù)庫(kù)，才是常態(tài)，你看看，我OLAP搞了一個(gè)，OLTP搞了一個(gè)，內(nèi)存數(shù)據(jù)庫(kù)也搞了一個(gè)，總之，你得分門(mén)別類(lèi)地每樣搞一個(gè)！（這樣大概就會(huì)很好賣(mài)）
后面的事情，熟悉數(shù)據(jù)庫(kù)圈子的也都知道了，SAP 在 4 年之后的 SIGMOD 2009 年上當(dāng)著 Stonebraker 的面介紹了他們研發(fā)出的的“One Size Fits All”—— SAP HANA，可以說(shuō)是當(dāng)眾打了大佬的臉。
但是，大佬就不可以被打臉么？我倒覺(jué)得 SAP 還是挺有勇氣的，如果沒(méi)有像 SAP 這樣的后起之秀扛起大旗來(lái)發(fā)出自己的聲音，或許，十幾年后的今天，數(shù)據(jù)庫(kù)圈子都不敢再談 HTAP 了。拋去商業(yè)界的競(jìng)爭(zhēng)較量，我們回歸到學(xué)術(shù)領(lǐng)域，仔細(xì)閱讀 Stonebraker 先生的這篇文章，其實(shí)還是非常有理有據(jù)的，從狹隘的商業(yè)視角看，“One Size Cannot fit All”可能是為了某種商業(yè)營(yíng)銷(xiāo)，不過(guò)，從宏觀的技術(shù)視角看，也正因?yàn)橛辛诉@個(gè)理論，我們?nèi)缃竦臄?shù)據(jù)庫(kù)產(chǎn)品種類(lèi)才能如此繁榮多樣。當(dāng)然，此篇論文的觀點(diǎn)僅供參考，讀者應(yīng)該有自己的判斷，今天，就讓我們來(lái)學(xué)習(xí)一下這篇經(jīng)典論文吧~
摘要
過(guò)去25年間的商業(yè)數(shù)據(jù)庫(kù)管理系統(tǒng)（database management system，DBMS）的發(fā)展可以用一個(gè)詞來(lái)概括：“One Size Fits All”?！癘ne Size Fits All”闡述了這樣一個(gè)事實(shí)：傳統(tǒng)的 DBMS 架構(gòu)最初是為處理業(yè)務(wù)數(shù)據(jù)而設(shè)計(jì)和優(yōu)化的，但如今卻被用來(lái)支持許多以數(shù)據(jù)為中心的應(yīng)用，這些應(yīng)用在特征和要求上存在著巨大的差異。本文論證了“One Size Fits All”的策略不再適用于數(shù)據(jù)庫(kù)市場(chǎng)。 數(shù)據(jù)庫(kù)市場(chǎng)將被一系列的獨(dú)立的數(shù)據(jù)庫(kù)引擎切分成無(wú)數(shù)個(gè)細(xì)分市場(chǎng)。當(dāng)然，在這些數(shù)據(jù)庫(kù)引擎中，也許有一部分可以通過(guò)一個(gè)通用的前端解析器統(tǒng)一起來(lái)。
本文使用流處理市場(chǎng)和數(shù)據(jù)倉(cāng)庫(kù)市場(chǎng)作為例證來(lái)支持我們的觀點(diǎn)。在本文中，我們還簡(jiǎn)要討論了傳統(tǒng)架構(gòu)在其他市場(chǎng)中存在的水土不服的情況，并指出應(yīng)該對(duì)將系統(tǒng)服務(wù)考慮進(jìn)產(chǎn)品中的做法進(jìn)行批判性思考。
關(guān)系型 DBMS 在20世紀(jì)70年代以 System R【10】和INGRES【27】作為產(chǎn)品原型出現(xiàn)。這兩個(gè)原型的定位是在應(yīng)用（即“業(yè)務(wù)數(shù)據(jù)處理”）上超越 IMS 對(duì)客戶(hù)的價(jià)值。因此，這兩個(gè)系統(tǒng)都是為聯(lián)機(jī)事務(wù)處理（online transaction processing，OLTP）應(yīng)用而設(shè)計(jì)的，它們的商業(yè)化產(chǎn)品 DB2 和 INGRES 在20世紀(jì)80年代得到了市場(chǎng)的認(rèn)可。Sybase、Oracle、Informix 以及其他供應(yīng)商也遵循了相同的基礎(chǔ) DBMS 模型。該模型逐行存儲(chǔ)關(guān)系表，使用 B-tree 進(jìn)行索引，使用基于成本的優(yōu)化器，并提供 ACID 事務(wù)屬性。
自20世紀(jì)80年代初以來(lái)，主要的 DBMS 供應(yīng)商一直堅(jiān)持“One Size Fits All”的策略，即所有的 DBMS 服務(wù)使用同一行代碼。選擇這種策略的原因很簡(jiǎn)單――使用多行代碼會(huì)導(dǎo)致各種實(shí)際問(wèn)題，包括:
- 成本問(wèn)題：維護(hù)成本會(huì)隨著代碼行數(shù)線(xiàn)性增長(zhǎng)，甚至增長(zhǎng)得更快。
- 兼容性問(wèn)題：所有的應(yīng)用都必須能夠支持每一行代碼。
- 銷(xiāo)售問(wèn)題：銷(xiāo)售人員不知道該向顧客推銷(xiāo)哪種產(chǎn)品。
- 營(yíng)銷(xiāo)問(wèn)題：如果使用多行代碼，那么每一行代碼必須有清晰、準(zhǔn)確的市場(chǎng)定位。
為了避免這些問(wèn)題，所有的主流 DBMS 供應(yīng)商都遵循集中精力做一款產(chǎn)品的行業(yè)策略。本文我們主要論證這種策略在當(dāng)下的數(shù)據(jù)庫(kù)市場(chǎng)中早已行不通了，并且使用這種策略的缺點(diǎn)會(huì)逐漸全面地暴露出來(lái)。
本文的框架結(jié)構(gòu)如下：第2章通過(guò)引用數(shù)據(jù)倉(cāng)庫(kù)市場(chǎng)的一些關(guān)鍵特征簡(jiǎn)要說(shuō)明為什么一行代碼闖天下的策略已經(jīng)行不通了。第3章討論流處理應(yīng)用，并用一個(gè)案例來(lái)說(shuō)明了流處理引擎比關(guān)系型 DBMS 在性能上高兩個(gè)數(shù)量級(jí)。承接第3章，第4章討論了造成這種性能差異的原因，并指出了傳統(tǒng) DBMS 技術(shù)缺乏市場(chǎng)競(jìng)爭(zhēng)力這一事實(shí)。基于此，我們判斷流處理引擎將成為 DBMS 市場(chǎng)發(fā)展的趨勢(shì)。第5章討論了一系列“One Size Fits All”策略可能不適用的市場(chǎng)。這些市場(chǎng)需要專(zhuān)門(mén)的數(shù)據(jù)庫(kù)系統(tǒng)。DBMS 市場(chǎng)可能會(huì)被細(xì)化切分。第6章提供了一些我們關(guān)于將系統(tǒng)軟件分解成產(chǎn)品的看法。最后，在第7章我們對(duì)我們的觀點(diǎn)進(jìn)行了總結(jié)。
在20世紀(jì)90年代初，DBMS 市場(chǎng)出現(xiàn)了一種新趨勢(shì): 出于 BI（商業(yè)智能，Business Intelligence）考慮，企業(yè)希望將來(lái)自多個(gè)操作型數(shù)據(jù)庫(kù)的數(shù)據(jù)收集到一個(gè)數(shù)據(jù)倉(cāng)庫(kù)中。一個(gè)典型的大型企業(yè)約有50個(gè)操作型系統(tǒng)，每個(gè)系統(tǒng)都有一個(gè)聯(lián)機(jī)用戶(hù)（on-line user）社區(qū)，這些用戶(hù)都期望快速響應(yīng)。因此，系統(tǒng)管理員一直以來(lái)都不愿意讓 BI 用戶(hù)和聯(lián)機(jī)用戶(hù)使用相同的系統(tǒng)，擔(dān)心 BI 用戶(hù)執(zhí)行的復(fù)雜即席查詢(xún)會(huì)影響系統(tǒng)性能，造成系統(tǒng)響應(yīng)時(shí)間過(guò)長(zhǎng)。此外，BI 用戶(hù)的常見(jiàn)需求還包括查看歷史趨勢(shì)以及關(guān)聯(lián)多個(gè)操作型數(shù)據(jù)庫(kù)的數(shù)據(jù)。在功能需求上，BI 用戶(hù)與聯(lián)機(jī)用戶(hù)之間存在巨大的差異。
因此，基本上每個(gè)企業(yè)都創(chuàng)建了一個(gè)大型數(shù)據(jù)倉(cāng)庫(kù)，用于存儲(chǔ)定期從操作型系統(tǒng)中同步過(guò)來(lái)的數(shù)據(jù)。BI 用戶(hù)可以對(duì)倉(cāng)庫(kù)中的數(shù)據(jù)執(zhí)行復(fù)雜的即席查詢(xún)，而不會(huì)影響到聯(lián)機(jī)用戶(hù)。盡管大多數(shù)數(shù)據(jù)倉(cāng)庫(kù)項(xiàng)目都大大超出了預(yù)算，且最終交付的功能和供應(yīng)商承諾交付的功能相比打了折扣，但是這些項(xiàng)目仍然帶來(lái)了合理的投資回報(bào)。事實(shí)上，人們普遍承認(rèn)存放零售交易歷史數(shù)據(jù)的倉(cāng)庫(kù)在一年內(nèi)就收回了成本。這主要是因?yàn)閭}(cāng)庫(kù)幫助他們做出了更明智的存貨周轉(zhuǎn)和購(gòu)買(mǎi)決策。例如，某 BI 用戶(hù)可以通過(guò)倉(cāng)庫(kù)數(shù)據(jù)分析發(fā)現(xiàn)寵物石已經(jīng)過(guò)時(shí)了,取而代之的是芭比娃娃的風(fēng)靡，然后做出恰當(dāng)?shù)纳唐贩胖煤唾?gòu)買(mǎi)決策。
因此，基本上每個(gè)企業(yè)都創(chuàng)建了一個(gè)大型數(shù)據(jù)倉(cāng)庫(kù)，用于存儲(chǔ)定期從操作型系統(tǒng)中同步過(guò)來(lái)的數(shù)據(jù)。BI 用戶(hù)可以對(duì)倉(cāng)庫(kù)中的數(shù)據(jù)執(zhí)行復(fù)雜的即席查詢(xún)，而不會(huì)影響到聯(lián)機(jī)用戶(hù)。盡管大多數(shù)數(shù)據(jù)倉(cāng)庫(kù)項(xiàng)目都大大超出了預(yù)算，且最終交付的功能和供應(yīng)商承諾交付的功能相比打了折扣，但是這些項(xiàng)目仍然帶來(lái)了合理的投資回報(bào)。事實(shí)上，人們普遍承認(rèn)存放零售交易歷史數(shù)據(jù)的倉(cāng)庫(kù)在一年內(nèi)就收回了成本。這主要是因?yàn)閭}(cāng)庫(kù)幫助他們做出了更明智的存貨周轉(zhuǎn)和購(gòu)買(mǎi)決策。例如，某 BI 用戶(hù)可以通過(guò)倉(cāng)庫(kù)數(shù)據(jù)分析發(fā)現(xiàn)寵物石已經(jīng)過(guò)時(shí)了,取而代之的是芭比娃娃的風(fēng)靡，然后做出恰當(dāng)?shù)纳唐贩胖煤唾?gòu)買(mǎi)決策。
數(shù)據(jù)倉(cāng)庫(kù)模式中的標(biāo)準(zhǔn)做法是創(chuàng)建一個(gè)事實(shí)表，表中包含每個(gè)操作型事務(wù)的“人物、時(shí)間、地點(diǎn)、發(fā)生了什么”。圖1描繪了零售行業(yè)中的典型數(shù)據(jù)倉(cāng)庫(kù)模式。請(qǐng)注意，中央事實(shí)表（central fact table）為連鎖店中每個(gè)商店的收銀員掃描的每個(gè)商品保存一條記錄。數(shù)據(jù)倉(cāng)庫(kù)還包含維度表（dimension table）。這些維度表中記錄了每個(gè)商店、客戶(hù)、產(chǎn)品和時(shí)間段的信息。這種組成方式產(chǎn)生的效果是，事實(shí)表包含了每個(gè)維度的外鍵（foreign key），從而產(chǎn)生了星形模式。這種星型模式在數(shù)據(jù)倉(cāng)庫(kù)中隨處可見(jiàn)，但在 OLTP 系統(tǒng)中卻鮮有存在。
眾所周知，倉(cāng)庫(kù)應(yīng)用使用位圖索引可以運(yùn)行得更好，而 OLTP 用戶(hù)則更傾向于使用 B-tree 索引。產(chǎn)生這種差異的原因很簡(jiǎn)單：位圖索引在倉(cāng)庫(kù)工作負(fù)載上更快、更緊湊，但在 OLTP 環(huán)境中則收效甚微。 因此，許多供應(yīng)商在其 DBMS 產(chǎn)品中同時(shí)支持 B-tree 索引和位圖索引。
另外，物化視圖在倉(cāng)庫(kù)環(huán)境中是非常有效的優(yōu)化策略，但在 OLTP 環(huán)境中卻毫無(wú)作用。OLTP 環(huán)境更適合使用普通視圖（也稱(chēng)為虛擬視圖）。
概括來(lái)講，大多數(shù)供應(yīng)商都有一個(gè)倉(cāng)庫(kù)型的 DBMS 和一個(gè) OLTP 型的 DBMS。倉(cāng)庫(kù)型的 DBMS 使用位圖索引、物化視圖、星型模式以及針對(duì)星型模式查詢(xún)的優(yōu)化策略，OLTP 型的 DBMS 則 B-tree 索的引和一個(gè)標(biāo)準(zhǔn)的基于成本的優(yōu)化器。二者由一個(gè)通用的解析器連接起來(lái)，如圖2所示。
請(qǐng)先看圖2中的例子。此例中，兩個(gè)系統(tǒng)共用同一個(gè)用戶(hù)界面（user interface）。這就給大家造成了一種假象：“One Size Fits All”具有可行性。接下來(lái)我們看看在流處理市場(chǎng)中，多個(gè)系統(tǒng)共用同一前端的想法是多么的不切實(shí)際。 在這個(gè)市場(chǎng)中，不僅會(huì)有不同的引擎，而且會(huì)有不同的前端?！癘ne Size Fits All”的可行性假象將會(huì)在這個(gè)市場(chǎng)中被無(wú)情的戳破。
最近，研究界興起了流處理應(yīng)用的興趣【7、13、14、20】。這種興趣的來(lái)源于市場(chǎng)對(duì)未來(lái)幾年內(nèi)傳感器網(wǎng)絡(luò)的商業(yè)可行性的預(yù)期。雖然射頻識(shí)別技術(shù)（Radio Frequency Identification，RFID）最近受到了所有媒體的關(guān)注，并將在零售行業(yè)中的供應(yīng)鏈優(yōu)化應(yīng)用中得到廣泛使用，但還有許多其他技術(shù)（例如 Lojack【3】)值得我們關(guān)注。大量低成本傳感器設(shè)備的使用給人們的生活帶來(lái)了翻天覆地的變化，也衍生出了監(jiān)控應(yīng)用這個(gè)新興市場(chǎng)。許多行業(yè)專(zhuān)家將眼光投向了這片藍(lán)海。
#3.1 傳感器應(yīng)用的興起
傳感器網(wǎng)絡(luò)技術(shù)在軍事領(lǐng)域有著廣泛應(yīng)用。例如，美國(guó)陸軍正在研究在所有士兵身上安裝生命體征監(jiān)視器，從而可以實(shí)現(xiàn)在戰(zhàn)時(shí)優(yōu)化醫(yī)療分類(lèi)。許多軍用車(chē)輛中已經(jīng)安裝了 GPS 系統(tǒng)，但這些 GPS 系統(tǒng)之間尚未連接形成一個(gè)閉環(huán)。而陸軍希望能夠監(jiān)控到所有車(chē)輛的位置，實(shí)時(shí)識(shí)別出哪些車(chē)輛偏離了路線(xiàn)。在炮塔上安裝傳感器也列入了考慮范圍。這樣再加上位置信息，陸軍就能檢測(cè)到交火情況。另外，如果在汽油表上安裝傳感器，就可以實(shí)現(xiàn)優(yōu)化加油?？傊粋€(gè)由30,000人和12,000輛車(chē)組成的軍營(yíng)很快將會(huì)被一個(gè)由幾十萬(wàn)個(gè)節(jié)點(diǎn)組成的大規(guī)模傳感器網(wǎng)絡(luò)所覆蓋。這個(gè)網(wǎng)絡(luò)需要實(shí)時(shí)傳送車(chē)輛狀態(tài)和位置信息。
這就要求網(wǎng)絡(luò)中的處理節(jié)點(diǎn)和下游服務(wù)器必須能夠處理這種 “流水” 數(shù)據(jù)。必需操作包括復(fù)雜的警報(bào)（例如，“排里的4輛車(chē)，什么時(shí)候有三輛車(chē)進(jìn)入到前線(xiàn)？”）、歷史查詢(xún)（例如，“在過(guò)去的兩個(gè)小時(shí)內(nèi)，編號(hào)12的車(chē)輛去了哪里？”）、以及縱向查詢(xún)（例如，“部隊(duì)現(xiàn)在的總體準(zhǔn)備狀態(tài)是什么？”）。
隨著時(shí)間的推移，基于傳感器的監(jiān)控應(yīng)用會(huì)逐漸出現(xiàn)在非軍事領(lǐng)域中，比如交通擁堵監(jiān)控以及旅游路線(xiàn)推薦。還有一個(gè)和軍事領(lǐng)域相似的應(yīng)用：可變的、基于擁堵的高速公路系統(tǒng)收費(fèi)系統(tǒng)。這個(gè)應(yīng)用的靈感來(lái)源于《線(xiàn)性道路基準(zhǔn)（Linear Road Benchmark）》【9】。游樂(lè)園將很快使用傳感器來(lái)取代顧客使用的普通腕帶，這樣不僅可以?xún)?yōu)化游樂(lè)設(shè)施還可以定位走丟的小朋友。手機(jī)早已活躍于人們?nèi)粘Ｉ钪?。我們可以幻想有這么一個(gè)服務(wù)可以為饑腸轆轆的用戶(hù)定位到最近的餐館。甚至是圖書(shū)館里的書(shū)籍也可以被貼上帶有傳感器的標(biāo)簽。這樣就不用擔(dān)心被放錯(cuò)書(shū)架的書(shū)本難以找回了。
人們推測(cè)，傳統(tǒng)的 DBMS 將不再適用于這種新型的監(jiān)控應(yīng)用。 事實(shí)也是如此。根據(jù)線(xiàn)性道路基準(zhǔn)來(lái)測(cè)試，傳統(tǒng)解決方案比專(zhuān)用流處理引擎慢了近一個(gè)數(shù)量級(jí)【9】。傳統(tǒng)的 DBMS 技術(shù)不適用于流應(yīng)用。當(dāng)前流數(shù)據(jù)應(yīng)用領(lǐng)域的研究也論證了這個(gè)觀點(diǎn)。接下來(lái)我們將分享一個(gè)我們?cè)谔幚斫鹑谛畔⒘鳎╢inancial feed）的應(yīng)用上的經(jīng)驗(yàn)。
#3.2 一個(gè)現(xiàn)有的應(yīng)用：金融信息流處理
大多數(shù)大型金融機(jī)構(gòu)會(huì)訂閱提供市場(chǎng)活動(dòng)實(shí)時(shí)數(shù)據(jù)的信息流，特別是新聞、已完成的交易、出價(jià)和要價(jià)等。路透社、彭博社和 Infodyne 就是提供這類(lèi)信息的供應(yīng)商。金融機(jī)構(gòu)有各種各樣的應(yīng)用用于處理這些信息流，包括實(shí)時(shí)業(yè)務(wù)分析系統(tǒng)、電子交易系統(tǒng)、用于確保所有交易符合各種公司和 SEC 規(guī)則的系統(tǒng)，以及用于計(jì)算實(shí)時(shí)風(fēng)險(xiǎn)和外匯匯率波動(dòng)的市場(chǎng)披露的系統(tǒng)。用于實(shí)現(xiàn)這類(lèi)應(yīng)用的技術(shù)總是需要“自力更生”，因?yàn)椴](méi)有現(xiàn)成的系統(tǒng)軟件產(chǎn)品供應(yīng)用專(zhuān)家使用。
為了更深入地探索信息流的處理問(wèn)題，接下來(lái)我們會(huì)詳細(xì)地描述一個(gè)特定的示例應(yīng)用。這個(gè)應(yīng)用是由一家大型共同基金公司指定的。該公司訂閱了幾份商業(yè)信息流，并且有一個(gè)生產(chǎn)應(yīng)用用于監(jiān)控所有信息流中是否存在滯后數(shù)據(jù)（late data）。從而當(dāng)發(fā)現(xiàn)某一信息流存在滯后現(xiàn)象時(shí)，該公司能夠提醒交易者，該信息流所提供的數(shù)據(jù)不可信。但是，該公司當(dāng)前使用的解決方案在性能和靈活性無(wú)法滿(mǎn)足需求，于是該公司要求試點(diǎn)使用流處理引擎。
該公司的工程師指定了一個(gè)當(dāng)前應(yīng)用的簡(jiǎn)化版本，用于比較他們當(dāng)前使用的系統(tǒng)和流處理引擎之間存在的性能差異。根據(jù)他們的具體要求，他們希望能在單臺(tái) PC 上為其應(yīng)用的子集獲得最大的消息處理吞吐量，由兩條信息流組成且兩條信息流中的數(shù)據(jù)來(lái)源于兩個(gè)交易所，共涉及4500只證券，其中500只交易非常頻繁。針對(duì)一只交易頻繁的證券而言，如果從某個(gè)交易所收到的兩個(gè)連續(xù) tick（交易快照）之間間隔超過(guò)了5秒，那么后收到的那一條 tick 則被視為滯后 tick。對(duì)于另外4000只證券而言，這個(gè)時(shí)間間隔為60秒。
由于使用了兩家信息流供應(yīng)商，該公司希望一旦有來(lái)自任一供應(yīng)商的一條滯后 tick，都能收到一條告警信息。該公司還希望為每個(gè)提供商分別維護(hù)一個(gè)計(jì)數(shù)器。當(dāng)某一供應(yīng)商有超過(guò)100條滯后 tick 時(shí)，該公司希望能夠收到一條特殊預(yù)警信息，提醒該供應(yīng)商的 tick 信息可信度極低，從而該公司能夠控制后續(xù)來(lái)自該供應(yīng)商的 tick 報(bào)告。
該公司的最后一條要求是，希望從兩個(gè)交易所（比如紐約證券交易所和全美證券交易商協(xié)會(huì)）中累計(jì)滯后 tick 數(shù)，而不用管具體滯后 tick 源于哪個(gè)信息流供應(yīng)商。從而，總滯后 tick 數(shù)達(dá)到100和某一信息流供應(yīng)商的滯后 tick 數(shù)達(dá)到100所產(chǎn)生的提醒消息是不同的。所以，該公司一共需要四個(gè)計(jì)數(shù)器。一旦任一計(jì)數(shù)器計(jì)數(shù)到100，便會(huì)觸發(fā)對(duì)應(yīng)的預(yù)警消息。這個(gè)任務(wù)的查詢(xún)圖的抽象表示如圖3所示。
雖然這個(gè)示例應(yīng)用只是實(shí)際生產(chǎn)系統(tǒng)中使用的應(yīng)用邏輯的一個(gè)子集，但它代表了一個(gè)易于指定的任務(wù)，其性能很容易被測(cè)量，因此極具代表性?，F(xiàn)在我們來(lái)對(duì)比下這個(gè)示例應(yīng)用在流處理引擎上和關(guān)系型 DBMS 上的速度。
上一章中討論的示例應(yīng)用是在 StreamBase 流處理引擎【5】中實(shí)現(xiàn)的，它基本上可以看作是Aurora 【8，13】的商業(yè)、工業(yè)級(jí)版本。我們使用的2.8 Ghz 奔騰處理器規(guī)格為512 MB 內(nèi)存，擁有一個(gè) SCSI 磁盤(pán)。在 CPU 飽和之前，圖3中的工作流可以以每秒160,000條消息的速度執(zhí)行。相比之下，StreamBase 的工程師使用主流的商業(yè)關(guān)系型 DBMS 實(shí)現(xiàn)同一個(gè)應(yīng)用時(shí)，每秒只能處理900條消息。
在本章中，我們將討論造成這種性能差異的主要原因。正如我們下面即將討論的，差異的產(chǎn)生與入站處理模型、正確的流處理原語(yǔ)以及 DBMS 處理與應(yīng)用處理的無(wú)縫集成有關(guān)。另外，我們還考慮了另一主要因素：事務(wù)性操作。
#4.1 “入站”與“出站”處理
我們稱(chēng)之為“出站”處理的流程是 DBMS 模型的基本組成流程，如圖4所示。具體可分為三步：
1. 將數(shù)據(jù)插入（updates）數(shù)據(jù)庫(kù)。
2. 為數(shù)據(jù)創(chuàng)建索引并提交事務(wù)（pull processing），從而后續(xù)步驟可以使用該數(shù)據(jù)。
3. 將處理結(jié)果（results）呈現(xiàn)給用戶(hù)。
這種“存儲(chǔ)后處理（process-after-store） ”的模式是所有傳統(tǒng) DBMS 的核心，畢竟 DBMS 的主要功能是接收數(shù)據(jù)并保證數(shù)據(jù)不會(huì)丟失。
當(dāng)然，也許有人會(huì)問(wèn)“DBMS 能支持入站處理嗎？ ”DBMS 最初被設(shè)計(jì)為出站處理引擎，但是在多年以后才想到將觸發(fā)器移植到它們的引擎上進(jìn)行補(bǔ)救。使用觸發(fā)器存在許多限制，比如每個(gè)表允許使用的數(shù)量。另外，使用觸發(fā)器的安全性沒(méi)法保證，我們無(wú)法確保觸發(fā)器不會(huì)進(jìn)入無(wú)限循環(huán)（infinite loop）中?？傮w看來(lái)，關(guān)于觸發(fā)器的編程支持少之又少，甚至于沒(méi)有。例如，用戶(hù)無(wú)法查看到應(yīng)用中存在哪些觸發(fā)器，也無(wú)法通過(guò)圖形用戶(hù)界面將觸發(fā)器添加到表中。此外，DBMS 為常規(guī)表提供了虛擬視圖和物化視圖，但卻不為觸發(fā)器提供。最后，觸發(fā)器在現(xiàn)有引擎中經(jīng)常會(huì)出現(xiàn)性能問(wèn)題。當(dāng) StreamBase 的工程師嘗試在信息流告警應(yīng)用（feed alarm application）中使用觸發(fā)器時(shí)，仍然無(wú)法實(shí)現(xiàn)高于每秒900條消息的性能。總之，觸發(fā)器作為現(xiàn)有設(shè)計(jì)中的“外來(lái)者”，在當(dāng)前的系統(tǒng)中處于二等公民的地位。
因此，關(guān)系型 DBMS 其實(shí)質(zhì)是出站引擎，僅有限地提供一些入站處理能力。相比之下，Aurora 和 StreamBase 之類(lèi)的流處理引擎基本上是入站處理引擎。入站引擎與出站引擎是完全不同的。例如，出站引擎使用“拉?。╬ull）”處理模型，即：當(dāng)一個(gè)查詢(xún)被提交之后，由引擎來(lái)實(shí)現(xiàn)從存儲(chǔ)中高效拉取滿(mǎn)足查詢(xún)的記錄。相反，入站引擎使用“推送（push）”處理模型，即當(dāng)一個(gè)查詢(xún)被提交之后，由引擎來(lái)按照應(yīng)用中指定的處理步驟來(lái)高效地推送傳入消息（incoming message）。
出站引擎和入站引擎還有一個(gè)很大的區(qū)別。出站引擎先存儲(chǔ)數(shù)據(jù)然后根據(jù)存儲(chǔ)的數(shù)據(jù)執(zhí)行查詢(xún)。而入站引擎恰好相反，入站引擎先存儲(chǔ)查詢(xún)，然后通過(guò)查詢(xún)傳遞傳入消息。
很明顯，構(gòu)建一個(gè)同時(shí)擁有出站和入站引擎能力的引擎是擁有可行性的也是值得研究的。同時(shí)，DBMS 針對(duì)出站處理進(jìn)行了優(yōu)化，而流處理引擎則針對(duì)入站處理進(jìn)行了優(yōu)化。在信息流告警應(yīng)用中，這種原理上的差異是造成我們觀察到的性能差異的主要原因。
#4.2 正確的原語(yǔ)
SQL系統(tǒng)包含一個(gè)復(fù)雜的聚合系統(tǒng)，用戶(hù)可以通過(guò)該系統(tǒng)對(duì)數(shù)據(jù)庫(kù)表中的記錄分組進(jìn)行統(tǒng)計(jì)計(jì)算。下述代碼提供了一個(gè)標(biāo)準(zhǔn)的示例：
Select avg (salary)
From employee
Group by department
當(dāng)執(zhí)行引擎處理表中的最后一條記錄時(shí)，它可以針對(duì)每組記錄分別進(jìn)行聚合計(jì)算。然而，這種結(jié)構(gòu)在流應(yīng)用中并沒(méi)有什么優(yōu)勢(shì)。在流應(yīng)用中，流永遠(yuǎn)不會(huì)結(jié)束，沒(méi)有“表結(jié)束（end of table）”的概念。
因此，流處理引擎用時(shí)間窗口（window）的概念對(duì) SQL（或其他一些聚合語(yǔ)言）進(jìn)行了擴(kuò)展。StreamBase 支持根據(jù)時(shí)鐘時(shí)間、消息數(shù)量或其他屬性中的斷點(diǎn)來(lái)定義窗口。在信息流告警應(yīng)用中，每個(gè)流中最左邊的框就是這樣一個(gè)聚合框。該聚合按符號(hào)對(duì)股票進(jìn)行分組，然后為每一只股票定義窗口為 tick 1和2、tick 2和3、tick 3和4等。通常情況下，這種滑動(dòng)的窗口（sliding windows）在實(shí)時(shí)應(yīng)用中非常有用。
此外，StreamBase 將聚合構(gòu)建成能夠智能地處理滯后、失序或丟失的消息的操作。在信息流告警應(yīng)用中，客戶(hù)最感興趣的是查找最新的數(shù)據(jù)。StreamBase 允許窗口聚合可以攜帶兩個(gè)附加參數(shù)：timeout 和 slack。timeout 參數(shù)指示 StreamBase 執(zhí)行引擎關(guān)閉一個(gè)窗口并發(fā)出一個(gè)值，即使窗口并不滿(mǎn)足關(guān)閉條件。該參數(shù)能夠有效地應(yīng)對(duì)元組滯后和缺失問(wèn)題。slack 參數(shù)指示執(zhí)行引擎保持一個(gè)窗口的打開(kāi)狀態(tài)即使該窗口滿(mǎn)足關(guān)閉條件。此參數(shù)解決了元組的無(wú)序接收問(wèn)題。這兩個(gè)參數(shù)允許用戶(hù)指定如何處理流異常并且可以有效提高系統(tǒng)彈性。
在信息流告警應(yīng)用中，每個(gè)窗口為兩個(gè) tick，但 tick 有超時(shí)設(shè)置，超時(shí)時(shí)間為5秒或60秒。如果兩個(gè)連續(xù) tick 之間的間隔時(shí)間超過(guò)用戶(hù)定義的超時(shí)閾值，對(duì)應(yīng)窗口將會(huì)被關(guān)閉。超時(shí)設(shè)置能夠有效地發(fā)現(xiàn)滯后數(shù)據(jù)，這算是高度調(diào)整的集合邏輯所帶來(lái)的一個(gè)意外之喜。在示例應(yīng)用中，每個(gè)聚合后的框在丟棄掉有效數(shù)據(jù)之后，只保留超時(shí)消息。應(yīng)用的其他部分對(duì)這些超時(shí)執(zhí)行必要的分類(lèi)記錄（bookkeeping）。
系統(tǒng)底層使用正確的原語(yǔ)可以實(shí)現(xiàn)非常高的性能。相比之下，關(guān)系型引擎不包含這樣的內(nèi)置結(jié)構(gòu)。用傳統(tǒng)的 SQL 模擬這種內(nèi)置結(jié)構(gòu)的效果不僅繁冗復(fù)雜，并且導(dǎo)致了第二個(gè)顯著的性能差異。
SQL 支持添加時(shí)間窗口，但是這樣做對(duì)存儲(chǔ)的數(shù)據(jù)沒(méi)有任何意義。因此，窗口構(gòu)造必須集成到某種入站處理模型中。
#4.3 DBMS 處理和應(yīng)用邏輯的無(wú)縫集成
關(guān)系型 DBMS 都被設(shè)計(jì)成了 C/S （client-server）結(jié)構(gòu)。這個(gè)模型中存在許多客戶(hù)端應(yīng)用。應(yīng)用的作者可能是任何人，因此通常是不可信的。出于安全性和可靠性考慮，這些客戶(hù)端應(yīng)用與 DBMS 運(yùn)行在不同的地址空間中。但是這么做會(huì)導(dǎo)致頻繁的進(jìn)程切換。
而信息流應(yīng)用是一個(gè)嵌入式系統(tǒng)，由一個(gè)受信任（trusted）的人或團(tuán)體編寫(xiě)。整個(gè)應(yīng)用包括：
1. DBMS 處理，例如聚合和過(guò)濾框（filter box）
2. 控制邏輯，用于將消息導(dǎo)向正確的下一個(gè)處理步驟
3. 應(yīng)用邏輯
在 StreamBase 中，這三種功能可以自由分布。應(yīng)用邏輯通過(guò)自定義框?qū)崿F(xiàn)。在我們使用的例子金融信息流處理應(yīng)用自定義了框Count100。實(shí)際代碼如圖 6 所示，由四行 C++ 代碼組成。計(jì)數(shù)到100，并設(shè)置了一個(gè)標(biāo)志以確保發(fā)出消息的正確性。應(yīng)用的支持邏輯通過(guò)允許在一個(gè)過(guò)濾框中使用多個(gè)謂詞來(lái)實(shí)現(xiàn)，從而可以有多個(gè)退出?。╡xit arcs）。因此，除了過(guò)濾流之外，過(guò)濾框還負(fù)責(zé)執(zhí)行“if-then-else”邏輯。
實(shí)際上，信息流告警應(yīng)用混合了 DBMS 風(fēng)格的處理、條件表達(dá)式和傳統(tǒng)編程語(yǔ)言中的自定義函數(shù)。 StreamBase 在單個(gè)地址空間內(nèi)執(zhí)行這種組合，無(wú)需進(jìn)行任何進(jìn)程切換。Rigel【23】和 Pascal-R【25】在多年前就提出了這種將 DBMS 邏輯與傳統(tǒng)編程工具無(wú)縫集成的設(shè)想，但從未在商業(yè)化的關(guān)系型系統(tǒng)中實(shí)現(xiàn)。
取而代之的是，主流供應(yīng)商實(shí)現(xiàn)了存儲(chǔ)過(guò)程，這是一個(gè)非常有限的編程系統(tǒng)。最近，市場(chǎng)上出現(xiàn)了使用對(duì)象-關(guān)系（object-relational）引擎的刀片服務(wù)器和擴(kuò)展程序，它們比存儲(chǔ)過(guò)程更強(qiáng)大，但仍然不支持靈活的控制邏輯。
嵌入式系統(tǒng)不需要 C/S 架構(gòu)的 DBMS 進(jìn)行保護(hù)，這種兩層架構(gòu)只會(huì)造成更大的開(kāi)銷(xiāo)。這是造成我們觀察到的性能差異的第三個(gè)原因。
另一個(gè)集成問(wèn)題是流式應(yīng)用中狀態(tài)信息的存儲(chǔ)。信息流告警應(yīng)用不涉及該問(wèn)題。大多數(shù)流處理應(yīng)用都需要保存一些狀態(tài)信息，小到幾 MB，大到幾千 GB。 這些狀態(tài)信息可能包括：
1. 參考數(shù)據(jù)（即，市場(chǎng)對(duì)哪些股票感興趣）；
2. 轉(zhuǎn)換表（以防不同信息流來(lái)源使用不同的符號(hào)代表同一股票）
3. 歷史數(shù)據(jù)（例如，“在去年中，每天觀察到多少個(gè)滯后 tick？”）。因此，大多數(shù)流處理應(yīng)用都要求對(duì)數(shù)據(jù)進(jìn)行表格式存儲(chǔ)。
StreamBase 在 BerkeleyDB 中內(nèi)嵌了狀態(tài)存儲(chǔ)功能【4】。然而，在 StreamBase 地址空間中調(diào)用 BerkeleyDB 和在不同的地址空間中以 C/S 模式調(diào)用 BerkeleyDB 之間存在大約一個(gè)數(shù)量級(jí)的性能差異。這也是為何要在一個(gè)地址空間中混合 DBMS 和應(yīng)用處理來(lái)避免進(jìn)程切換的另一個(gè)原因。雖然有人可能會(huì)建議通過(guò)增強(qiáng) DBMS 的編程模型來(lái)解決這個(gè)性能問(wèn)題，但是 DBMS 采用 C/S 模型有其必要性，因?yàn)榇蠖鄶?shù)業(yè)務(wù)數(shù)據(jù)處理應(yīng)用需要這種模型來(lái)提供保護(hù)。存儲(chǔ)過(guò)程和對(duì)象-關(guān)系刀片都是一種將部分客戶(hù)端邏輯移至服務(wù)端以提高性能的嘗試。為了更進(jìn)一步，DBMS 必須實(shí)現(xiàn)一個(gè)嵌入式和一個(gè)非嵌入式模型，并且這兩個(gè)模型使用不同的運(yùn)行時(shí)系統(tǒng)（runtime system）。這種做法等同于放棄了“One Size Fits All”策略。
相反，信息流處理系統(tǒng)都是嵌入式應(yīng)用。應(yīng)用和 DBMS 的作者是相同的，并由外部數(shù)據(jù)源驅(qū)動(dòng)，而非由人工輸入的事務(wù)驅(qū)動(dòng)。因此，沒(méi)有理由針對(duì)應(yīng)用給 DBMS 提供保護(hù)，且二者在同一地址空間運(yùn)行是完全可以接受的。在嵌入式處理模型中，對(duì)應(yīng)用邏輯、控制邏輯和 DBMS 邏輯進(jìn)行自由混合是合理的，而 StreamBase 也確實(shí)完成了該實(shí)現(xiàn)。
#4.4 高可用
許多基于流的應(yīng)用都要求高可用性和24/7不間斷運(yùn)行。標(biāo)準(zhǔn) DBMS 日志記錄和崩潰恢復(fù)機(jī)制（例如【22】）不適合流數(shù)據(jù)市場(chǎng)，主要原因如下：
首先，基于日志的恢復(fù)可能需要幾秒到幾分鐘。在此期間，應(yīng)用將被“關(guān)閉”。這種行為在許多實(shí)時(shí)流領(lǐng)域（例如，金融服務(wù)）中顯然是不能接受的。第二，如果系統(tǒng)崩潰，必須采取措施來(lái)緩沖傳入數(shù)據(jù)流，否則這些數(shù)據(jù)將在恢復(fù)過(guò)程中永久丟失。第三，DBMS 恢復(fù)將只處理表格狀態(tài)，忽略了操作員（operator）狀態(tài)。例如，在信息流告警應(yīng)用中，計(jì)數(shù)器并未存儲(chǔ)在表格中。如果系統(tǒng)崩潰，計(jì)數(shù)器的狀態(tài)信息將會(huì)丟失。一個(gè)簡(jiǎn)單的解決方法是將所有操作符狀態(tài)強(qiáng)制轉(zhuǎn)換到表中，使其適用于 DBMS 風(fēng)格的恢復(fù)；但是，這種解決方案會(huì)大大降低應(yīng)用的速度。
一個(gè)常見(jiàn)的高可用替代方案是使用依賴(lài)于串聯(lián)式進(jìn)程對(duì)（Tandem-style process pair）【11】的技術(shù)手段。該替代方案的基本思路是，在系統(tǒng)崩潰的情況下，應(yīng)用通過(guò)故障恢復(fù)，恢復(fù)到備機(jī)（backup machine）上運(yùn)行。備機(jī)通常以“熱備（hot standby）”方式部署，并和主機(jī)（active machine）之間保持極小的時(shí)延。這種方法免除了日志記錄的開(kāi)銷(xiāo)。再以 StreamBase 為例，StreamBase 關(guān)閉了 BerkeleyDB 中的日志記錄。
與需要精確恢復(fù)以確保正確性的傳統(tǒng)數(shù)據(jù)處理應(yīng)用不同，許多流處理應(yīng)用可以容忍并能受益于沒(méi)那么嚴(yán)格的恢復(fù)概念。換句話(huà)說(shuō)，故障恢復(fù)并不總是需要“完美”的。監(jiān)控應(yīng)用操作的數(shù)據(jù)流的值會(huì)被定期刷新。如果由于系統(tǒng)崩潰造成的業(yè)務(wù)終端時(shí)間很短，這種程度的元組丟失對(duì)于監(jiān)控應(yīng)用而言通常是可以容忍的。即，如果在故障恢復(fù)期間丟失了信息流告警應(yīng)用中的幾個(gè) tick，正確性可能仍然可以保障。相比之下，一些用于在某些事件組合發(fā)生時(shí)觸發(fā)告警的應(yīng)用則要求沒(méi)有元組丟失，但可以容忍短暫的重復(fù)。例如，患者監(jiān)控應(yīng)用可能能夠容忍元組重復(fù)（“心率是79”），但不能容忍元組丟失（“心率已經(jīng)變?yōu)榱恪保?strong>當(dāng)然，總有一類(lèi)應(yīng)用需要強(qiáng)大、精確的恢復(fù)保證，例如基于單個(gè)股票交易執(zhí)行投資組合管理的金融類(lèi)應(yīng)用。
因此，當(dāng)應(yīng)用對(duì)準(zhǔn)確性要求不那么嚴(yán)格的時(shí)候，可以考慮采用低開(kāi)銷(xiāo)的簡(jiǎn)化版的故障恢復(fù)方案。近期出現(xiàn)了很多關(guān)于如何在流領(lǐng)域?qū)崿F(xiàn)高可用的詳細(xì)研究【17】。
# 4.5 同步
許多基于流的應(yīng)用依賴(lài)于共享數(shù)據(jù)和計(jì)算。共享數(shù)據(jù)通常包含在一個(gè)表中。有的用戶(hù)會(huì)查詢(xún)表中的更新，而有的僅讀取數(shù)據(jù)。例如，線(xiàn)性道路應(yīng)用要求使用車(chē)輛位置數(shù)據(jù)來(lái)更新高速公路使用情況的統(tǒng)計(jì)數(shù)據(jù)，然后讀取這些數(shù)據(jù)來(lái)確定高速公路上每個(gè)路段的過(guò)路費(fèi)。因此，消息隔離是一個(gè)基本需求。
傳統(tǒng)的 DBMS 使用滿(mǎn)足 ACID 屬性的事務(wù)來(lái)實(shí)現(xiàn)多個(gè)用戶(hù)之間提交的并發(fā)事務(wù)的隔離。在非多用戶(hù)的流系統(tǒng)中，這種隔離可以通過(guò)簡(jiǎn)單的臨界區(qū)（critical section）有效地實(shí)現(xiàn)，臨界區(qū)可以通過(guò)輕量級(jí)信號(hào)量（semaphore）來(lái)實(shí)現(xiàn)。由于完全符合 ACID 屬性的事務(wù)不再是必需，使用重量級(jí)基于鎖的機(jī)制也并非必要。
總之，大多數(shù)流處理應(yīng)用不需要 ACID 屬性，因此可以使用更簡(jiǎn)單、更專(zhuān)業(yè)的性能結(jié)構(gòu)。
上一章已經(jīng)指出了一系列造成專(zhuān)用流處理引擎和傳統(tǒng) DBMS 之間的性能差異的架構(gòu)因素。這些設(shè)計(jì)上的不同選擇同時(shí)還導(dǎo)致了兩種引擎之間巨大的內(nèi)部差異。事實(shí)上，StreamBase 使用了完全不同于傳統(tǒng)的 DBMS 的運(yùn)行時(shí)代碼。這樣做的結(jié)果是大大提高了一類(lèi)實(shí)時(shí)應(yīng)用的性能。這些考量將導(dǎo)致針對(duì)流處理使用單獨(dú)的代碼，當(dāng)然產(chǎn)生這種情況的前提是市場(chǎng)足夠大。
在本章中，我們概述了其他幾個(gè)市場(chǎng)。這些市場(chǎng)有著一個(gè)共同點(diǎn)：有專(zhuān)用數(shù)據(jù)庫(kù)引擎的潛在需求。
# 5.1 數(shù)據(jù)倉(cāng)庫(kù)
在第2章中我們討論到的 OLTP 和倉(cāng)庫(kù)數(shù)據(jù)庫(kù)系統(tǒng)之間的架構(gòu)差異只是冰山一角，隨著時(shí)間的推移，二者之間會(huì)產(chǎn)生更大的差異。接下來(lái)我們討論下我們可能關(guān)注到的最大的架構(gòu)差異：列式存儲(chǔ)和行式存儲(chǔ)的選擇。
所有主流DBMS 供應(yīng)商都實(shí)現(xiàn)了面向記錄的存儲(chǔ)系統(tǒng)，其中記錄的屬性被連續(xù)地放置在存儲(chǔ)中。使用這種“行式存儲(chǔ)”架構(gòu)會(huì)將單個(gè)記錄的所有屬性推送到磁盤(pán)，產(chǎn)生一次磁盤(pán)寫(xiě)操作。因此，這樣的系統(tǒng)是“寫(xiě)優(yōu)化的”，這種架構(gòu)能夠保障極高的記錄寫(xiě)入性能。不難看出，寫(xiě)優(yōu)化的系統(tǒng)非常適合 OLTP 風(fēng)格的應(yīng)用，這也是大多數(shù)商業(yè) DBMS 采用這種架構(gòu)的主要原因。
相比之下，倉(cāng)庫(kù)系統(tǒng)則需要“讀優(yōu)化”,因?yàn)槠浯蠖鄶?shù)工作負(fù)載由涉及針對(duì)大量歷史數(shù)據(jù)的即席查詢(xún)組成。在這樣的系統(tǒng)中，一個(gè)能夠把一個(gè)屬性對(duì)應(yīng)的所有行中的值進(jìn)行連續(xù)存儲(chǔ)的“列式存儲(chǔ)”模型更為高效（已被 Sybase IQ【6】，Addamark 【1】和 KDB【2】所證明）。
使用列式存儲(chǔ)架構(gòu)的 DBMS 只需要讀取和處理查詢(xún)中指定的屬性，可以避免將其他不相關(guān)的屬性帶入內(nèi)存。 鑒于具有數(shù)百個(gè)屬性（包含許多空值）的記錄越來(lái)越常見(jiàn)，這種架構(gòu)對(duì)于倉(cāng)庫(kù)工作負(fù)載來(lái)說(shuō)能夠提供相當(dāng)大的性能優(yōu)勢(shì)，因?yàn)閭}(cāng)庫(kù)場(chǎng)景下的典型查詢(xún)包含對(duì)大型數(shù)據(jù)集上的少量屬性進(jìn)行聚合計(jì)算。本文的第一作者正在研究探索列式存儲(chǔ)系統(tǒng)的性能優(yōu)勢(shì)。
#5.2 傳感器網(wǎng)絡(luò)（Sensor networks）
傳感器網(wǎng)絡(luò)中的處理節(jié)點(diǎn)用于管理網(wǎng)絡(luò)的傳感器。 而在這些處理節(jié)點(diǎn)上運(yùn)行傳統(tǒng) DBMS 是一個(gè)不切實(shí)際的想法。這些新興的設(shè)備網(wǎng)絡(luò)平臺(tái)的應(yīng)用正在被探索中，包括、環(huán)境和醫(yī)療監(jiān)控、工業(yè)自動(dòng)化、自主機(jī)器人團(tuán)隊(duì)和智能家居【16、19、26、28、29】。
為了能在通信和能源領(lǐng)域開(kāi)發(fā)出這些系統(tǒng)的全部潛力，組件被設(shè)計(jì)成無(wú)線(xiàn)的。在這種環(huán)境下，帶寬和功率成為需要省著用的關(guān)鍵資源。此外，與處理或存儲(chǔ)訪(fǎng)問(wèn)相反，通信是能源的主要消耗者。因此，標(biāo)準(zhǔn)的 DBMS 優(yōu)化策略并不適用，需要另尋突破口。事務(wù)處理能力也并未納入倉(cāng)庫(kù)系統(tǒng)的考慮范圍。
一般來(lái)說(shuō)，倉(cāng)庫(kù)系統(tǒng)需要設(shè)計(jì)靈活、輕量級(jí)的數(shù)據(jù)庫(kù)抽象（如 TinyDB【18】），針對(duì)數(shù)據(jù)移動(dòng)進(jìn)行優(yōu)化，而不是數(shù)據(jù)存儲(chǔ)。
#5.3 文本搜索（Text search）
目前的文本搜索引擎都沒(méi)有使用 DBMS 技術(shù)進(jìn)行存儲(chǔ)，即使它們處理的是海量的、不斷增長(zhǎng)的數(shù)據(jù)集。 例如，Google 構(gòu)建了自己的存儲(chǔ)系統(tǒng)（稱(chēng)為 Google File System，GFS【15】），它的性能優(yōu)于傳統(tǒng)的 DBMS 技術(shù)以及文件系統(tǒng)技術(shù)。產(chǎn)生這種性能優(yōu)勢(shì)的原因我們已經(jīng)在第4章中討論過(guò)了。
一個(gè)典型的搜索引擎工作負(fù)載【12，15】由需要清洗并合并到現(xiàn)有搜索索引中的入站流數(shù)據(jù)（來(lái)自網(wǎng)絡(luò)爬蟲(chóng)）和現(xiàn)有索引上的即席查找（ad hoc look-up）操作組成。尤其是，大多數(shù)寫(xiě)操作只涉及數(shù)據(jù)追加（append），而大多數(shù)讀操作都是順序讀（sequential read）。對(duì)同一文件的并發(fā)寫(xiě)（即追加寫(xiě)）是獲得良好性能的必要條件。最后，由商品零件組成的大量存儲(chǔ)機(jī)器確保了故障是常態(tài)而非例外。因此，高可用是設(shè)計(jì)考慮的一個(gè)關(guān)鍵因素，并且只能通過(guò)快速恢復(fù)和復(fù)制來(lái)實(shí)現(xiàn)。
可以很明顯的看出，這些應(yīng)用的特征與傳統(tǒng)的業(yè)務(wù)處理應(yīng)用有很大的不同。這樣就導(dǎo)致即使一些 DBMS 具有內(nèi)置的文本搜索能力，但卻過(guò)于笨重、不靈活，依然無(wú)法滿(mǎn)足這個(gè)領(lǐng)域?qū)τ谛阅芎涂捎眯缘囊蟆?/p>
#5.4 科學(xué)的數(shù)據(jù)庫(kù)（Scientific databases ）
各種類(lèi)型的傳感器不斷地收集大量數(shù)據(jù)，這些傳感器連接著衛(wèi)星和顯微鏡等設(shè)備，或者由高分辨率科學(xué)和工程人工模擬生成。
關(guān)于這類(lèi)數(shù)據(jù)集的分析能夠幫助我們更好地了解物理現(xiàn)象，并且在許多科學(xué)研究領(lǐng)域變得越來(lái)越普遍。對(duì)這些龐大數(shù)據(jù)庫(kù)的有效分析和查詢(xún)需要高效的多維索引結(jié)構(gòu)和特定應(yīng)用的聚集技術(shù)。 此外，對(duì)高效的數(shù)據(jù)存檔、分級(jí)、沿襲和錯(cuò)誤傳播技術(shù)的需求可能會(huì)在這個(gè)重要領(lǐng)域中產(chǎn)生對(duì)另一個(gè)專(zhuān)用引擎的需求。
#5.5 XML 數(shù)據(jù)庫(kù)（XML databases）
半結(jié)構(gòu)化數(shù)據(jù)無(wú)處不在。但是這類(lèi)數(shù)據(jù)不能立即適應(yīng)關(guān)系模型。關(guān)于怎么存儲(chǔ)和操作 XML 數(shù)據(jù)才是最好的方式存在著巨大的爭(zhēng)議。盡管有些人認(rèn)為關(guān)系型 DBMS（帶有適當(dāng)?shù)臄U(kuò)展）是可行的，但其他人會(huì)認(rèn)為需要一個(gè)專(zhuān)門(mén)的引擎來(lái)存儲(chǔ)和處理這種數(shù)據(jù)格式。
大多數(shù)流應(yīng)用需要以下三項(xiàng)基本服務(wù)：
- 消息傳輸: 許多流應(yīng)用要求數(shù)據(jù)能在多個(gè)分布式機(jī)器間高效、可靠地進(jìn)行傳輸。原因有三：第一、數(shù)據(jù)源（source）和傳輸?shù)哪康牡兀╠estination）通常在地理上是分散的。第二、高性能和高可用要求使用多臺(tái)服務(wù)器。第三、幾乎所有大型企業(yè)系統(tǒng)都是一個(gè)嵌入了 SPE （單對(duì)以太網(wǎng)，single-pair Ethernet）的復(fù)雜業(yè)務(wù)應(yīng)用網(wǎng)絡(luò)，而這些應(yīng)用分散運(yùn)行在大量的機(jī)器上。因此，來(lái)自外部應(yīng)用的輸入和輸出消息在經(jīng)過(guò) SPE 時(shí)需要正確地路由到恰當(dāng)?shù)钠渌獠繎?yīng)用中
- 狀態(tài)存儲(chǔ)：如4.3節(jié)所述，除了最簡(jiǎn)單的應(yīng)用之外，所有應(yīng)用都需要存儲(chǔ)狀態(tài)。狀態(tài)通常存儲(chǔ)在只讀引用表、只讀歷史表以及讀寫(xiě)變換（read-write translation, 如哈希）表中。
- 應(yīng)用邏輯的執(zhí)行：許多流應(yīng)用要求特定域的消息處理中穿插查詢(xún)。一般來(lái)說(shuō)，僅使用內(nèi)置查詢(xún)?cè)Z(yǔ)來(lái)表示這種應(yīng)用邏輯既是不可能的也是不現(xiàn)實(shí)的，比如通過(guò)解讀遺留代碼。
流處理應(yīng)用的傳統(tǒng)設(shè)計(jì)將整個(gè)應(yīng)用邏輯分布在三個(gè)不同的系統(tǒng)中:
1. 消息傳遞系統(tǒng)（例如 MQSeries、WebMethods 或 Tibco）：將各組成系統(tǒng)可靠地聯(lián)系起來(lái)，通常使用發(fā)布/訂閱范例；
2. DBMS(如 DB2 或 Oracle)：保證狀態(tài)信息的持久性；
3. 應(yīng)用服務(wù)器（如 WebSphere 或 WebLogic）,為一組定制編碼的程序提供應(yīng)用服務(wù)。圖7展示了該種三層配置的架構(gòu)。
這種將所需功能分散在三個(gè)重量型系統(tǒng)軟件上的設(shè)計(jì)在性能上卻不盡如人意。例如，每個(gè)需要查找狀態(tài)和應(yīng)用服務(wù)的消息都需要在這些不同的服務(wù)之間進(jìn)行多次切換。
為了說(shuō)明每條消息的開(kāi)銷(xiāo)，我們來(lái)看看消息處理時(shí)涉及的步驟。在步驟1中，傳入的消息首先經(jīng)過(guò)總線(xiàn)，被總線(xiàn)轉(zhuǎn)發(fā)給自定義應(yīng)用代碼，后者清理并處理該消息。如果消息需要與歷史數(shù)據(jù)相關(guān)聯(lián)或者需要訪(fǎng)問(wèn)持久數(shù)據(jù)，那么則會(huì)進(jìn)行步驟2和3，向 DB 服務(wù)器發(fā)送一個(gè)請(qǐng)，DB 服務(wù)器會(huì)訪(fǎng)問(wèn) DBMS。步驟4和5描繪了請(qǐng)求響應(yīng)路徑，方向和應(yīng)用代碼路徑剛好相反。在最后一步（步驟6） 時(shí)，消息處理后的結(jié)果被轉(zhuǎn)發(fā)到客戶(hù)端的任務(wù) GUI。總的來(lái)說(shuō)，處理一條消息涉及6次“跨界（boundary crossing）”。 除了引發(fā)明顯的上下文切換之外，每次從消息總線(xiàn)中提取消息并傳遞到消息總線(xiàn)時(shí)，還需要使用恰當(dāng)?shù)倪m配器將消息即時(shí)地轉(zhuǎn)換為系統(tǒng)的本機(jī)格式或從系統(tǒng)的本機(jī)格式轉(zhuǎn)換為目的端格式。這就導(dǎo)致了極低的有效工作:開(kāi)銷(xiāo)比（useful work:overhead）。即使對(duì)消息進(jìn)行一定程度的批處理，開(kāi)銷(xiāo)也依然很大并且限制了系統(tǒng)的性能實(shí)現(xiàn)。
為了避免這種性能損失，流處理引擎必須在一個(gè)系統(tǒng)軟件中提供所有三種服務(wù)，該軟件在其運(yùn)行的每臺(tái)機(jī)器上作為一個(gè)多線(xiàn)程進(jìn)程執(zhí)行。因此，SPE 必須具有 DBMS、應(yīng)用服務(wù)器和消息傳遞系統(tǒng)三要素。實(shí)際上，一個(gè) SPE 應(yīng)該“在一個(gè)屋檐下”提供所有三種軟件的功能。
這一觀察提出了這樣一個(gè)問(wèn)題，即當(dāng)前將系統(tǒng)軟件分解成組件（例如，應(yīng)用服務(wù)器、DBMS、ETL 系統(tǒng)、消息總線(xiàn)、文件系統(tǒng)、web 服務(wù)器等）的做法是否是最優(yōu)解。畢竟，這種特殊的分解方案一部分是歷史產(chǎn)物，而另一部分則是偶然的營(yíng)銷(xiāo)事件。這樣看起來(lái)系統(tǒng)服務(wù)的其他分解方案似乎也是合理的。這也意味著組件定義和分解在未來(lái)將迎來(lái)巨大的發(fā)展。
總之，未來(lái)可能會(huì)出現(xiàn)大量應(yīng)用于特定領(lǐng)域的數(shù)據(jù)庫(kù)引擎。 這些引擎將提供不同功能。這使我們想起了“愿你生活在有趣的時(shí)代”這句祝福。我們認(rèn)為 DBMS 市場(chǎng)正變得愈發(fā)有趣起來(lái)。許多已有的和新出現(xiàn)的應(yīng)用都能從數(shù)據(jù)管理、處理原則和處理技術(shù)手段中受益。同時(shí)，這些應(yīng)用與業(yè)務(wù)數(shù)據(jù)處理有很大的不同，而且應(yīng)用之間也存在著巨大的差異。這就導(dǎo)致使用一行代碼來(lái)支持所有應(yīng)用成為了一個(gè)不切實(shí)際的想法。在這種情況下，“One Size Fits All”策略的結(jié)局只能是逐漸被市場(chǎng)淘汰。
