Sybase數(shù)據(jù)倉庫解決方案指南DW-whitepaper

目錄

Sybase數(shù)據(jù)倉庫解決方案指南2

SybaseIQ技術(shù)白皮書_________________________________________________8

PowerDesignorWarehouseArchitect6.024

PowerDimensions實現(xiàn)動態(tài)OLAP30

SybaseIQ為數(shù)據(jù)倉庫應(yīng)用帶來的經(jīng)濟利益36

SybaseIQ的性能測試._______________________________________________43

Sybase數(shù)據(jù)倉庫解決方案指南

數(shù)據(jù)倉庫的概念

任何一個公司和企業(yè)，在訂貨、存貨清單、票據(jù)清單、帳目清算、客戶服務(wù)

以及財務(wù)報告等方面都存在大量的業(yè)務(wù)應(yīng)用和技術(shù)環(huán)節(jié)。數(shù)據(jù)倉庫的作用在于：

從這些應(yīng)用系統(tǒng)中獲得信息并轉(zhuǎn)換到一個新的數(shù)據(jù)庫，通過對新庫中的歷史信息

和面對主題的信息進行分析，為決策供應(yīng)支持。以往的產(chǎn)品系統(tǒng)，如訂貨或購置

系統(tǒng)，則很難從中獲得有關(guān)商業(yè)發(fā)展狀況的信息。

數(shù)據(jù)倉庫是企業(yè)決策支持的一部分。在做出下一個確定前，每個商業(yè)機構(gòu)中

的行政人員和分析人員都須要將很多關(guān)鍵商業(yè)問題搞清晰，例如：哪些產(chǎn)品最有

利可圖？哪些客戶會為我們帶來最大利益？哪些環(huán)節(jié)須要花費很高的費用？哪些市

場活動運行得最好，為什么？我們有可能會失去哪些客戶，為什么？這些都是數(shù)據(jù)

倉庫要回答的“百萬利潤”問題，也同時是一個最大的市場。據(jù)Gartner估計，

60%的關(guān)系數(shù)據(jù)庫管理系統(tǒng)被用作決策支持系統(tǒng)的應(yīng)用開發(fā)。

數(shù)據(jù)倉庫與數(shù)據(jù)集市的比較

在二十世紀八十年頭中期，BillInmon首次提出“數(shù)據(jù)倉庫”這一名詞。

它最初被設(shè)計為一個商業(yè)數(shù)據(jù)庫，具有穩(wěn)定性（主要成分不變）、歷史性（包含歷

史信息）和面對主題（信息由客戶、產(chǎn)品和市場等組成）等特點。這些最初的“數(shù)

據(jù)倉庫”依據(jù)對客戶、產(chǎn)品、銷售狀況和財務(wù)狀況等信息的分析，得到對企業(yè)活

動的整體相識。

要建立一個數(shù)據(jù)倉庫，一般分為四個步驟：

第一步：數(shù)據(jù)庫設(shè)計，即設(shè)計出一個包含商業(yè)數(shù)據(jù)和信息的數(shù)據(jù)庫，為商

業(yè)實體所用；

其次步：開發(fā)數(shù)據(jù)抽取和轉(zhuǎn)換程序，從產(chǎn)品系統(tǒng)中將數(shù)據(jù)取出后放入數(shù)據(jù)

倉庫中；

第三步：開發(fā)數(shù)據(jù)加載和更新技術(shù)，使得在產(chǎn)品數(shù)據(jù)發(fā)生變更時，數(shù)據(jù)倉

庫得到動態(tài)實時的更新；

第四步：購置查詢和報表生成工具，令運用者通過企業(yè)內(nèi)部網(wǎng)和個人計算

機很便利地獲得信息。

多年以來客戶發(fā)覺：盡管企業(yè)級數(shù)據(jù)倉庫很有吸引力，但是具體操作起來有

些難度。1996年“IDC探討”調(diào)查結(jié)果表明：盡管為建立數(shù)據(jù)倉庫平均投入了三

年多時間和近320萬美元，5096沒有達到應(yīng)有的效果。從項目起先算起，三年后，

大多數(shù)商人發(fā)覺所面臨的商業(yè)問題已經(jīng)不再是起先建立時的樣子，發(fā)生了很大變

更。另外，盡管開發(fā)進度被延長了一年又一年，仍舊做不到讓全部感愛好的客戶

對想看到什么信息給出明確的需求定義。因而“企業(yè)數(shù)據(jù)模型”的確立猶如練習(xí)

一樣進行了一年又一年。

在最近的18-24個月的時間里，出現(xiàn)了一種新的解決方法,那就是數(shù)據(jù)集市。

數(shù)據(jù)集市也是一種數(shù)據(jù)倉庫，只是它更精練，更面對主題。Sybase公司自創(chuàng)立

以來，便確立了在數(shù)據(jù)集市技術(shù)上的領(lǐng)導(dǎo)地位。目前，運用Sybase產(chǎn)品的2萬

多家客戶中的大多數(shù)已經(jīng)建立了運行在SQLServer上的數(shù)據(jù)集市，盡管通常也

稱為數(shù)據(jù)倉庫，卻幾乎沒有一個是企業(yè)級的。

數(shù)據(jù)集市的優(yōu)勢在于建設(shè)周期的縮短和費用上的大大降低。其中周期以月代

替了年，費用從幾百萬下降到一百萬。由于整個企業(yè)的數(shù)據(jù)很浩大，真正將它們

集中到一個數(shù)據(jù)庫中幾乎是不行能的。有人便對很多大數(shù)據(jù)倉庫實質(zhì)上是不是數(shù)

據(jù)集市產(chǎn)生了懷疑。運用數(shù)據(jù)集市后。設(shè)計、抽取、轉(zhuǎn)換、加載和查詢等環(huán)節(jié)變

得更加簡潔，因為客戶中的一部分人能夠更精確地知道他們自己所須要的信息是

什么。

然而，假如有很多的數(shù)據(jù)集市卻不能使它們保持同步，數(shù)據(jù)集市解決方案就

會遇到困難。一旦一個單位創(chuàng)建了兩個或兩個以上的數(shù)據(jù)集市，最大的問題就是

如何使它們之間協(xié)調(diào)一樣，如何使它們實時操作，以及如何維護全部的數(shù)據(jù)抽取

和轉(zhuǎn)換。另外，當一個單位要創(chuàng)建兩個或兩個以上的數(shù)據(jù)集市時，會發(fā)覺每一個

都要經(jīng)過一個重新的設(shè)計、抽取、加載和查詢步驟。于是，在面對多個數(shù)據(jù)集市

的開發(fā)時，如何共享設(shè)計和結(jié)構(gòu)成為一個有現(xiàn)實意義和挑戰(zhàn)性的問題。

運作型數(shù)據(jù)存儲與合并式數(shù)據(jù)倉庫

針對上述問題，一種解決方案是采納一種全新的數(shù)據(jù)倉庫概念一一“運作型

數(shù)據(jù)存儲(OperationalDataStore,ODS)”。在ODS方式下，數(shù)據(jù)被從業(yè)務(wù)數(shù)

據(jù)庫中復(fù)制到一個中心位置，再從這里被抽取到多個數(shù)據(jù)集市中。ODS是從客戶、

產(chǎn)品和其他商業(yè)角度來組織的，被稱為商業(yè)狀況的“實時快照”。它不包含歷史

信息，但可以很簡潔地滿意一個歷史數(shù)據(jù)庫或一組面對主題的數(shù)據(jù)集市的須要。

我們一般稱之為“合并式數(shù)據(jù)倉庫”，因為它在進入決策支持數(shù)據(jù)庫以前

是一個信息的結(jié)合點。ODS雖小，卻能被常常地修改，因而特別適合于建立在

AdaptiveServerEnterpriseReplicationServerJio

多維或OLAP(聯(lián)機分析處理)市場

作為數(shù)據(jù)倉庫應(yīng)用環(huán)節(jié)中的一部分，OLAP在市場份額上得到快速增長，變

得越來越大。簡潔來說，OLAP是從商業(yè)角度進行信息組織，而不象通常的由行、

列和表構(gòu)成。例如，在一個類似Arbor或OracleExpress的OLAP數(shù)據(jù)中，信

息是通過客戶、產(chǎn)品、日期、銷售部門和地域等屬性來存取的，這對于數(shù)據(jù)理解

和信息獲得來說都顯得特別直觀。

OLAP產(chǎn)品取得關(guān)系數(shù)據(jù)后，將它放入一個特別簡潔的表格中，使之很簡潔

分析。OLAP數(shù)據(jù)庫和一個OLAP產(chǎn)品可被看做一個多維表格。這個市場相當熱門，

Arbor>Oracle的Express和Microstrategy在此領(lǐng)域中各占一席之地，而Sybase

的PowerDimentions(原名whitelight),Cognos的Impromptu和Powerplay,Brio

Technology的BrioQuery處于優(yōu)勢地位。

競爭對手與合作伙伴一覽

RDBMS公司：Sybase,Oracle,IBM,Teradata/NCR,Informix,Microsoft

硬件公司：IBM,Teradata,Sun,Digital/Compaq.HP

轉(zhuǎn)換工具：VMARK,Infomatica,Carleton/Apertus,ETZ,PrismSolutions

OLAP：Sybase/PowerDimentions,Arbor,Oracle/Express,Microstrategy,

InfomationAdvantage0

Sybase的解決方案及其組成

Sybase擁有一個獨特而強有力的點對點方案，用來設(shè)計、建立和管理數(shù)據(jù)

倉庫和數(shù)據(jù)集市。各個部門之間通過集中的元數(shù)據(jù)進行交互,這便具有了完整性、

集中性和敏捷性等特點。我們的工具也具有很多優(yōu)越性能。

下表列出了各個組成部分：

(1)PowerDesignerWarehouseArchitect

PowerDesigner不但是業(yè)界知名的數(shù)據(jù)庫設(shè)計工具，也是數(shù)據(jù)倉庫模型設(shè)計

工具。其中的WarehouseArchitect模塊支持多種數(shù)據(jù)倉庫模型，包括星型模式、

雪花模式、以及雪暴模式。這是同行業(yè)中最優(yōu)秀、最敏捷的開發(fā)工具，可用來設(shè)

H"一個關(guān)系的或OLAP的軟件倉庫。PowerDesigner在數(shù)據(jù)倉庫設(shè)計工具市場中

占有最大份額。它能從已有的數(shù)據(jù)庫進行反向工程，從運行系統(tǒng)中將現(xiàn)存的數(shù)據(jù)

結(jié)構(gòu)抽取出來形成數(shù)據(jù)模型，使設(shè)計變得簡潔。

(2)PowerStage

強大的數(shù)據(jù)抽取和數(shù)據(jù)轉(zhuǎn)換產(chǎn)品。它是領(lǐng)導(dǎo)市場的客戶/服務(wù)器轉(zhuǎn)換方法，

使數(shù)據(jù)倉庫模型用PowerDesigner實現(xiàn)起來更加簡潔，更加直觀。PowerStage

真正是平安并基于引擎的。它有一個簡潔的面對處理的圖形用戶接口，使得用戶

可以快速啟動，重復(fù)利用以往的工作，從任何源中獲得數(shù)據(jù)。

(3)適用于數(shù)據(jù)倉庫的AdaptiveServerfortheWarehouse

AdaptiveServerfortheWarehouse(ASW),是一個包含AdaptiveServer

Enterprise(ASE)和AdaptiveServerIQ(ASIQ)的新關(guān)系數(shù)據(jù)庫管理系統(tǒng)。它

具有一項新的數(shù)據(jù)庫查詢技術(shù)一一干脆英文查詢。該產(chǎn)品使得高性能的OLAP和

高性能的DSS在同一服務(wù)器上得到集成。

AdaptiveServerIQ,是服務(wù)于數(shù)據(jù)倉庫的最優(yōu)秀關(guān)系數(shù)據(jù)庫管理系統(tǒng)，可

以對數(shù)據(jù)庫進行壓縮，也可以以傳統(tǒng)關(guān)系數(shù)據(jù)庫管理系統(tǒng)的10至100倍的速度

執(zhí)行快速查詢，使得數(shù)據(jù)規(guī)?？梢赃_到并超過十億行數(shù)據(jù)。

⑷PowerDimensions

快速、可擴展的聯(lián)機分析工具。這是業(yè)界中最新的OLAP解決方案，對建立

于ASIQ和ASW數(shù)據(jù)庫的數(shù)據(jù)可以供應(yīng)快速敏捷的多維模型建立和分析。區(qū)分于

多維數(shù)據(jù)庫，Powerdimensions能支持幾百千兆以至萬億字節(jié)的原始數(shù)據(jù)和多個

角度。

(5)IntellidexControlCenter

對元數(shù)據(jù)和分布式數(shù)據(jù)集市供應(yīng)點對點集中管理的產(chǎn)品。它是業(yè)界中管理分

布式數(shù)據(jù)集市的唯一的完全點對點的解決方案。作為一個新產(chǎn)品，它供應(yīng)了建立

分布式數(shù)據(jù)集市的點對點方案，并且從一個中心位置上管理它們，它同時解決了

業(yè)界中在元數(shù)據(jù)管理方面的問題。

(6)SAFE/DW

建立數(shù)據(jù)倉庫的一套完整的測試方法，在世界上得到廣泛應(yīng)用。

(7)Sybase專業(yè)服務(wù)

是一個全球范圍的數(shù)據(jù)倉庫協(xié)作組織，可快速、牢靠地設(shè)計和供應(yīng)數(shù)據(jù)倉庫

解決方案。

Sybase方案的主要好處

1、快速實現(xiàn)

由于Sybase的解決方案是集成的，客戶只須要選擇一套最適合的產(chǎn)品集，

即可使它們無縫地工作。這樣，一方面可以快速實現(xiàn)，另一方面只須要面對一個

廠商就可以獲得全部的支持和服務(wù)。

2、數(shù)據(jù)集市與中心倉庫的無縫集成

在市場上,Sybase方案唯一地能夠?qū)⒍鄠€數(shù)據(jù)集市和中心倉庫管理集成在一

起。我們的方案是為企業(yè)供應(yīng)的“唯一的可行方案”，對進入數(shù)據(jù)集市的數(shù)據(jù)移

動、平安和元數(shù)據(jù)管理進行調(diào)度。

3、極高的查詢速度

ASIQ是世界上用于決策支持（DSS）的最快速數(shù)據(jù)庫。由于具有先進的

Bit-wise索引技術(shù)，它能夠以10至100倍于其競爭對手的速度查詢，這些對手

包括Oracle,RedBrack,Informix和Teradata。這更有利于最終用戶的特殊的、

重復(fù)的分析，也支持了在以前根本做不到的應(yīng)用開發(fā)。

4、高效的數(shù)據(jù)壓縮

ASIQ和ASE的數(shù)據(jù)壓縮結(jié)果是傳統(tǒng)RDBMS方法的三分之一至七分之一。在一

個典型的ASIQ實現(xiàn)上，假如以五年左右時間來計算，一個Sybase方案可以做到

每增加100GB數(shù)據(jù)節(jié)約大約41.5萬美元（包括磁盤購置、維護和操作）。

5、無限的可擴展性

區(qū)分于傳統(tǒng)的RDBMS解決方案,ASIQ和ASE將共同支持客戶存放更多的歷史

和具體數(shù)據(jù)?？蛻舫３P(guān)切對VLDB的支持。采納Sybase解決方案后，數(shù)據(jù)庫

規(guī)模比用非Sybase解決方案要小得多。今日，我們的用戶已經(jīng)可以利用ASIQ

數(shù)據(jù)庫來存取萬億字節(jié)（TB級）的數(shù)據(jù)。

6、面對不同數(shù)據(jù)庫環(huán)境

Sybase解決方案也可以適用在混合的非Sybase環(huán)境中。在數(shù)據(jù)庫網(wǎng)關(guān)方面,

Sybase是世界上的先驅(qū)者，可以干脆訪問25種不同的主機，以及其它的客戶機

/服務(wù)器數(shù)據(jù)庫系統(tǒng)，通過其DirectConnect系列產(chǎn)品。我們同時為基于軟件的

數(shù)據(jù)倉庫和數(shù)據(jù)集市供應(yīng)了具有數(shù)據(jù)變更捕獲實力的復(fù)制服務(wù)器Replication

Server,它可以反映Sybase、Oracle.DB2、VSAM、IMS以及其它關(guān)系型數(shù)據(jù)庫

中的數(shù)據(jù)變更。

7、平安性和易管理性

利用intellidex,我們的方案使IT用戶僅通過一個簡潔的承諾模式，就可

以管理分布的數(shù)據(jù)集市，具有高度的平安性、用戶可限制性。除此之外，我們還

有一個管理整個企業(yè)元數(shù)據(jù)的解決方案，這樣既可以運用戶創(chuàng)建自己的數(shù)據(jù)集

市，也可以得到一個“唯一可行的方案”。intellidex能自動告知用戶哪些數(shù)

據(jù)是在他們的數(shù)據(jù)集市中，這些數(shù)據(jù)從哪里來，以及到哪里去取等附加信息。

8、供應(yīng)強大的、可擴展的OLAP集成

業(yè)務(wù)分析人員希望通過利用數(shù)據(jù)倉庫中的數(shù)據(jù)做一些困難分析。利用

PowerDimensions,用戶可以快速建立簡潔或困難的多角度模型，干脆訪問數(shù)據(jù)

倉庫中的數(shù)據(jù)。而這些模型可以被成百上千的用戶共享，允許分析人員建立一些

能為最終用戶的決策者所運用的業(yè)務(wù)模型。

9、Web上的基于軟件的數(shù)據(jù)倉庫解決方案

Sybase的PowerDimensions包含一個用來分析和查詢的基于Java的閱讀器。

它支持圖形、主元選擇和表格模型。Sybase的PowerDynamo自動將數(shù)據(jù)倉庫并

入Web,產(chǎn)生簡潔的基于HTML的查詢。

10、豐富的閱歷

Sybase在數(shù)據(jù)倉庫和數(shù)據(jù)集市的實現(xiàn)方面閱歷豐富，涉及金融服務(wù)、電訊、

醫(yī)療保健、公用事業(yè)、交通運輸、媒體和消遣業(yè)。正由于在業(yè)務(wù)和技術(shù)上的特長,

我們可以快速地為客戶建立好用可行的高效的解決方案。

SybaseIQ技術(shù)白皮書

數(shù)據(jù)庫背景學(xué)問

SQL數(shù)據(jù)庫

長期以來，數(shù)據(jù)庫管理系統(tǒng)始終被用于在線事務(wù)處理(OnlineTransaction

Processing,簡稱OLTP),也就是將日常事務(wù)處理中的數(shù)據(jù)以表的形式存放在數(shù)

據(jù)庫里。為了在數(shù)據(jù)庫中“加入”數(shù)據(jù)，OLTP系統(tǒng)通常要發(fā)出查詢一個記錄或

少量幾個記錄的吩咐，比如OLTP系統(tǒng)中的一個查詢可能會查找某一個客戶的數(shù)

據(jù)記錄，如在一個航空訂票系統(tǒng)中查找訂票號為35的記錄。由此可以看出，OLTP

系統(tǒng)查詢數(shù)據(jù)的用途主要為滿意即時性的事務(wù)處理需求，在這種需求中，查詢比

較簡潔，查詢獲得的數(shù)據(jù)列的數(shù)量(相對于整個數(shù)據(jù)表的大小)也較少。換句話

說，OLTP系統(tǒng)是被優(yōu)化用來執(zhí)行“大海撈針”類型的任務(wù)的，即在大量的數(shù)據(jù)

中找尋符合給定查詢條件的少量記錄。

最近一段時間，人們對數(shù)據(jù)倉庫的愛好越來越濃。數(shù)據(jù)倉庫是應(yīng)用于決策

支持系統(tǒng)(DecisionSupportSystem,簡稱DSS),對于這類應(yīng)用來說，數(shù)據(jù)庫

系統(tǒng)的主要任務(wù)并不是“加入”信息，而是“提取”信息。供應(yīng)DSS的作法通

常是將基于SQL的OLTP數(shù)據(jù)庫引擎(如SybaseSQLServerOracle或Informix)

加以擴展以用來處理DSS應(yīng)用。但是，這樣構(gòu)造出的DSS功能性能普遍較差，

緣由特別簡潔：這些數(shù)據(jù)庫的底層物理結(jié)構(gòu)都是特地為事務(wù)處理而設(shè)計和優(yōu)化

的，并不適用于DSS的分析性處理，所以這些數(shù)據(jù)庫在OLTP應(yīng)用中的性能特

別好，而在DSS應(yīng)用中的性能則出現(xiàn)明顯差異。

為了說明這一點，讓我們來做個比方。十年前，假如你想要買一輛自行車，

你只要到商店去買一輛即可，你雖然可以在不同的顏色和式樣中做選擇，但自行

車還是自行車。而現(xiàn)在，我們有山地車、賽車和絕技用車等不同種類的自行車。

之所以有這么多種自行車的緣由是不同任務(wù)對自行車的物理要求也不同，例如山

地車輪胎所必需的物理結(jié)構(gòu)就與賽車完全不同。你雖然可以在山地環(huán)境中湊合運

用賽車，但效果確定不會好。

對于數(shù)據(jù)庫也是一樣，讓OLTP數(shù)據(jù)庫來做DSS的工作，就象騎著賽車翻

山越嶺，緣由是OLTP與DSS的基本物理結(jié)構(gòu)的不同導(dǎo)致解決方案的不同。在

一條特別平坦的山路上，你可以若無其事地騎幾次賽車，但當騎行的次數(shù)增加或

山路變得陡峭時，采納山地車這樣特地解決方案就會顯得特別明智。

數(shù)據(jù)庫結(jié)構(gòu)

大多數(shù)現(xiàn)代關(guān)系型數(shù)據(jù)庫由五個主要部件組成，即句法分析/語言層

(Parser/Languagelayer)、SQL節(jié)(SQLCatalog)、查詢優(yōu)化(QueryOptimization)>

查詢運行庫(QueryRuntime)和數(shù)據(jù)庫存儲管理系統(tǒng)(DatabaseStorage

ManagementSystem)0以下是一個典型的數(shù)據(jù)庫結(jié)構(gòu)的示意圖:

典型的數(shù)據(jù)庫結(jié)構(gòu)

句法分析/語言層

查詢優(yōu)化

SQL節(jié)

查詢運行庫

存儲管理系統(tǒng)

讓我們再回到自行車的比方上。山地車和賽車都有車把、車座和腳蹬，這其

中的一些部件是相同的，有些則是不同的，其不同之處是為了更有利于不同的用

途。對于數(shù)據(jù)庫也是一樣，我們發(fā)覺有利于供應(yīng)DSS性能的數(shù)據(jù)庫結(jié)構(gòu)與原始

數(shù)據(jù)庫結(jié)構(gòu)的不同之處主要在于數(shù)據(jù)庫存儲管理系統(tǒng)。一個特地為DSS編寫的

數(shù)據(jù)庫存儲管理器(StorageManager)在處理DSS方面要遠遠優(yōu)于為OLTP編

寫的存儲管理器。

多維數(shù)據(jù)庫

為了供應(yīng)更多的解決方案，一些廠商實施了具有DSS功能的非SQL系統(tǒng)。

這些非SQL或“多維數(shù)據(jù)庫(Multi-DimensionalDatabase,簡稱MDDB)”有

PiloJM和ComshareTM等。這些系統(tǒng)采納了一個能夠讓用戶以一個類似立方體的

形式查看數(shù)據(jù)的非關(guān)系型模型。

這些系統(tǒng)典型的運作方式是先從SQL數(shù)據(jù)庫中導(dǎo)出數(shù)據(jù)記錄，然后以各種

不同的專用格式將這些數(shù)據(jù)保存起來。信息一旦從SQL格式轉(zhuǎn)化為專用的格式,

就被保存在一個或多個服務(wù)器上以便讓用戶通過專用界面進行訪問，因此這些系

統(tǒng)一般都集成了專用的客戶端或前端系統(tǒng)。

大多數(shù)被稱為在線分析處理(OnlineAnalyticProcessing,簡稱OLAP)引擎

的多維數(shù)據(jù)庫產(chǎn)品試圖以犧牲一些敏捷性為代價獲得更好的性能。用自行車的比

方來說，MDDB就象一輛行駛在兩旁都是懸崖峭壁的山路上的山地車，假如你

希望離開現(xiàn)成的小路，不是根本行不通，就是要付出很大的代價。

雖然MDDB能夠以很高的速度完成預(yù)先設(shè)定好的分析工作，但這種方法也

存在著重大的劣勢，特殊是當數(shù)據(jù)的容量達到10GB以上時，即用戶必需事先將

數(shù)據(jù)導(dǎo)入并整理成各種專用格式。然而事實上，用戶通常希望數(shù)據(jù)以最基本的形

式存在于SQL數(shù)據(jù)庫表中，這其中至少有兩個緣由：一是長期以來收集與積累

起來的信息業(yè)已以SQL格式保存在數(shù)據(jù)庫中；二是用戶已經(jīng)對諸如Sybase或

Oracle等主要的SQL數(shù)據(jù)庫廠商的客戶端查詢軟件特別熟識。假如實施DSS須

要有附加工具，用戶會比較喜愛采納那些與他們?nèi)粘Ｋ霉ぞ咄瑢僖粋€家族的產(chǎn)

品。現(xiàn)在大多數(shù)關(guān)系型數(shù)據(jù)庫廠商正在或安排將MDDB技術(shù)融入到自己的關(guān)系

數(shù)據(jù)庫引擎中，而且有些廠商已經(jīng)推出了各種對SQL語言的擴展，以為各自的

用戶群供應(yīng)OLAP功能。

為什么DSS別出心裁

現(xiàn)在須要的是具有更佳DSS性能的系統(tǒng)和方法，而且這些系統(tǒng)和方法應(yīng)屬

于用戶所喜聞樂見的傳統(tǒng)的SQL/關(guān)系型模式。從用戶的角度來看，這樣的系統(tǒng)

將完全是一個基于SQL的關(guān)系型系統(tǒng)，但它供應(yīng)很高的DSS性能。SybaseIQ

就是這樣一個滿意以上要求的系統(tǒng)。這份白皮書將試圖描述與探討分別為DSS

和OLTP用途而優(yōu)化的數(shù)據(jù)庫存儲管理系統(tǒng)之間的根本性區(qū)分。

什么是DSS?

對不同的人來說，DSS是不同的東西。SybaseIQ為DSS供應(yīng)了以下這些運

用特點：

OLTP與DSS

預(yù)先設(shè)定查詢特定查詢

簡潔查詢困難查詢

小查詢結(jié)果集大查詢結(jié)果集

事務(wù)數(shù)量大事務(wù)數(shù)量小

事務(wù)歷時短事務(wù)歷時長

更新/選擇主要為選擇

實時更新批更新

細微環(huán)節(jié)行提取整理分組

高選擇性查詢條件低選擇性查詢條件

同時用戶數(shù)大，1000以上同時用戶數(shù)小，100以上

多用戶/特定查詢

DSS數(shù)據(jù)庫領(lǐng)域必需勝利解決的一個最為重要的問題是多用戶的特定查詢

性能?；贠LTP的數(shù)據(jù)庫無法在大量的數(shù)據(jù)上很好地完成此類查詢，因為這些

數(shù)據(jù)庫是為預(yù)先設(shè)定好的查詢而建立的?，F(xiàn)在看來，這種只限于預(yù)設(shè)查詢的高性

能并不能供應(yīng)一個健全的解決方案。當今用于特定和困難查詢的OLTP數(shù)據(jù)庫采

納的是并行表掃描方法。這種方法在一個大型SMP上只有一個用戶的狀況下，

效果是最好的，但在多用戶查詢環(huán)境中的性能會大打折扣。緣由是現(xiàn)在的大多數(shù)

SMP系統(tǒng)只能同時支持一至兩個大型的并行表掃描，假如掃描數(shù)量增加，不是

CPU資源不夠，就是耗盡了I/O總線的帶寬。每一個表的掃描同時也使數(shù)據(jù)庫緩

沖完全失效，因為大多數(shù)大型DSS應(yīng)用的表掃描都遠大于物理緩沖區(qū)的存儲實

力。

SybaseIQ在開發(fā)的時候就考慮到多用戶特定查詢在本質(zhì)上的不行預(yù)料性和

對于DSS市場勝利的極端重要性，因此我們找尋了其它可以預(yù)料的方面來努力

供應(yīng)性能。我們發(fā)覺，雖然查詢本身無法預(yù)料，但數(shù)據(jù)的屬性是可以預(yù)料的。

SybaseIQ利用這一點供應(yīng)了更高的性能，這些技術(shù)中的一部分將在這份白皮書

中予以探討。

事務(wù)模型

DSS與OLTP的事務(wù)特性是極為不同的。OLTP模型中有很多很短的事務(wù)，

這些讀取與更新的短小事務(wù)組成了一個混合體。數(shù)據(jù)庫廠商花了很大的精力來提

高自己的事務(wù)速率，通常的作法是對CPU上下文開關(guān)進行內(nèi)部管理并通過去除

代碼間的模塊性來縮短代碼的路徑長度。為了表明這些短事務(wù)的性能，大多數(shù)

OLTP數(shù)據(jù)庫都供應(yīng)了各自的每分鐘事務(wù)速率（TransactionPerMinute,簡稱

TPM）o現(xiàn)在，大多數(shù)數(shù)據(jù)庫可以達到18000TPM以上的速率。

而DSS的事務(wù)特點則迥然不同。DSS中有很多長時間運行的只讀事務(wù)和少

量一些長時間運行的更新事務(wù)?？偟膩碚f，是留意查詢的反應(yīng)時間與批量更新實

力。

人們通常知道在SMP環(huán)境中，只讀（非登錄）系統(tǒng)的性能要大大高于非只

讀（登錄）系統(tǒng)，緣由是須要有更多的系統(tǒng)資源來管理SMP環(huán)境中的可更新系

統(tǒng)和運行大量的內(nèi)容鎖定。

DSS系統(tǒng)的優(yōu)點在于能夠在大多數(shù)狀況下以非登錄方式運行，從而提高了查

詢的性能。

困難查詢

DSS與OLTP之間另一個重大的區(qū)分是查詢的困難程度。在OLTP環(huán)境中，

查詢總是比較簡潔，只涉及到數(shù)據(jù)庫中少量的行，查詢返回的通常是實際的細微

環(huán)節(jié)數(shù)據(jù)。DSS查詢要困難一些，常常要涉及到數(shù)據(jù)庫四分之一或更多的行，查

詢通常不返回實際的數(shù)據(jù)行，而是先把數(shù)據(jù)整理壓縮到少量的幾行后再交給用

戶。在OLTP數(shù)據(jù)庫環(huán)境中，困難的DSS查詢總是要造成TPM的大大降低。

DSS數(shù)據(jù)庫內(nèi)核物理結(jié)構(gòu)

上面我們探討了OLTP與DSS的應(yīng)用模型的一些不同之處。接下來我們將

探討為了支持DSS和OLTP這兩種不同模式，數(shù)據(jù)庫的內(nèi)核層應(yīng)有的一些差別。

假如仍以自行車作比方，那么我們下面想要說明的是：為什么用來登山時，

為競賽而設(shè)計的賽車的性能不如為登山而設(shè)計的山地車。我們將探討的是為什么

這兩種不同應(yīng)用模型的結(jié)構(gòu)須要實行不同的方案才能達到卓越的性能。

數(shù)據(jù)庫頁面大小

大多數(shù)的數(shù)據(jù)庫中有數(shù)據(jù)庫頁面大小這一概念。頁面大小通常代表著數(shù)據(jù)

庫送數(shù)據(jù)到磁盤或從磁盤取數(shù)據(jù)時以字節(jié)計算的內(nèi)部數(shù)據(jù)量。這是數(shù)據(jù)庫的基

石，數(shù)據(jù)庫其余操作都會用到這一概念。好玩的是，基于OLTP的應(yīng)用模型在頁

面較小時性能較好，而基于DSS的應(yīng)用模型則在頁面較大時性能較好。

在OLTP系統(tǒng)中，從磁盤一次讀/寫的信息量通常只是一條或幾條記錄，所

以I/O頁面一般不大，大約2K至4K。假設(shè)一頁數(shù)據(jù)約有50至100條記錄，而

每次查詢或更新操作只涉及其中一條記錄，這樣就可以通過削減一頁上的無關(guān)數(shù)

據(jù)量來達到更高的I/O檢索效率。在這個例子中，查詢只用到緩慢的I/O操作所

取到數(shù)據(jù)的1/100到1/50,而由于數(shù)據(jù)庫內(nèi)核所采納的存儲方式，數(shù)據(jù)庫系統(tǒng)不

得不檢索全部這些數(shù)據(jù)。當數(shù)據(jù)庫的大小與物理內(nèi)存大小之比達到或超過2:1（當

前典型的大型系統(tǒng)均如此）時，這一影響因素就變得不容忽視了。

讓我們以一臺有1GB物理內(nèi)存的機器為例說明，假設(shè)在這臺機器上有一個

10GB的數(shù)據(jù)庫。假設(shè)數(shù)據(jù)勻稱分布并且懇求是隨機的，那么每10次I/O中僅有

1次會命中Cache,而其余的不能命中Cache,而必定導(dǎo)致物理I/O。既然大多數(shù)

I/O都會導(dǎo)致物理I/O（與CPU訪問內(nèi)存相比物理I/O是一個極慢的操作），那

么僅僅取那些必需的信息或元組能帶來更高的性能。因此，同時滿意以下兩條規(guī)

則前提下，頁面越小，OLTP系統(tǒng)越好：

?頁面大小應(yīng)大于或等于記錄大小。

?頁面大小應(yīng)大于或等于操作系統(tǒng)最小I/O傳輸量（常為2K或4K）。

除此以外還有別的需考慮的因素，但這是最基本的兩條。

與此相反，典型DSS系統(tǒng)為了響應(yīng)一個查詢需取得大量信息；其操作通常

須要查詢數(shù)據(jù)庫中的大量數(shù)據(jù)。假如DSS查詢所取來的數(shù)據(jù)頁中很大的一部分

的確是DSS查詢所需的（大約25%至100%）,那么I/O頁面大小可以增加到對

于環(huán)境/平臺來說最優(yōu)的水平，例如以64K為數(shù)據(jù)頁面的大小。從我們的測試可

以看出，讀一張10GB的表，163,840個64K的I/O明顯比5,242,880個2K的I/O

快得多。

LargerPageSize=FasterThroughput

數(shù)據(jù)分割方式

典型的OLTP數(shù)據(jù)庫內(nèi)核中數(shù)據(jù)庫的一張表常常表示為一條數(shù)據(jù)庫頁的鏈

（頁鏈），每一數(shù)據(jù)頁中有一個或多個數(shù)據(jù)記錄或元組。這種方式適用于事務(wù)處

理，當數(shù)據(jù)庫要檢索某條特定記錄時，只需將存有該記錄的相關(guān)數(shù)據(jù)頁讀入。我

們將這種按頁存儲記錄的方式稱為“水平數(shù)據(jù)分割”，在這種方式下數(shù)據(jù)庫將一

張表水平分割為N個數(shù)據(jù)頁，每頁上有Y條完整記錄。

在DSS應(yīng)用模型中，從查詢性能的觀點動身，這種水平分割方式是全部可

能的數(shù)據(jù)存儲方式中最不行取的。較好的方式是采納“垂直分割”，在這種方式

下，每張表是一組相互獨立的頁鏈的集合，每一頁鏈代表表中的一列。所以有

100列的表將有100條相互獨立的頁鏈，每一列都有一條頁鏈與之對應(yīng)，而不是

象OLTP中那樣一張表對應(yīng)一條頁鏈。

VerticalPartitioning

|VerticalPartitioningTableByColumn|

Account八?

,ncomc

NumberSlatc00Kle「

Customer

5Table

|TraditionalHorizontalTablePartitioning||

Customer

Table

垂直按列進行頁面鏈接所固有的優(yōu)越性在于：大多數(shù)DSS查詢只關(guān)切表中

全部列的一個很小的子集。讓我們以一個DSS應(yīng)用為例，這個應(yīng)用有兩個較大

的表，分別是Customers表和Transactions表。描述顧客的信息在Customers表

中，而當一個顧客購買了某樣?xùn)|西，這一事務(wù)被記錄到Transactions表中。

Customers表和Transactions表通過顧客帳號（Accountnumber）字段形成一對多

的關(guān)系。為簡潔起見，不妨設(shè)每張表大小均為100GB且各有100歹！J,兩張表共

有200列數(shù)據(jù)。我們發(fā)覺大多數(shù)DSS類的查詢只關(guān)注10個甚至是更少的列。此

例中，數(shù)據(jù)的垂直按列存儲方式將使得從磁盤檢索的數(shù)據(jù)量至多是原來的1/20。

這是由200（總列數(shù)）除以10（查詢涉及的不同列的總數(shù)）得到，結(jié)果為20。

磁盤檢索數(shù)據(jù)量削減20倍，通常會使查詢響應(yīng)時間提高20倍。

運用這一技術(shù)，SybaseIQ在最壞的狀況下的查詢方案是對查詢涉及的全部

列進行并行掃描，而不是象大多數(shù)的OLTP數(shù)據(jù)庫內(nèi)核那樣進行并行的表掃描。

然而，SybaseIQ也極少運用對查詢涉及的全部列并行掃描的方式，而常常采納

附加的技術(shù)以進一步削減查詢時間。

Column-wiseQueryProcessingTechnology

Cache命中率

典型的大型數(shù)據(jù)庫應(yīng)用中，DSS類查詢的Cache命中率很低。這是因為數(shù)

據(jù)庫大小與物理內(nèi)存之比很大，而大多數(shù)被傳統(tǒng)OLTP數(shù)據(jù)庫內(nèi)核執(zhí)行的DSS

型查詢會導(dǎo)致對表的并行掃描。表掃描使Cache命中率降低，并且也使得后續(xù)查

詢也停留在如此低的命中率。

SybaseIQ由于運用按列的垂直數(shù)據(jù)分割方式存儲數(shù)據(jù)，Cache命中率大大

提高。所以在反復(fù)查詢或多用戶查詢的狀況下，查詢響應(yīng)加快。這一提高是源于

數(shù)據(jù)的更好的聚集方式，某些列，如連接字段或其它一些公共字段，由于數(shù)據(jù)垂

直存儲，將有更大的機會得以留在Cache中。

數(shù)據(jù)壓縮

數(shù)據(jù)壓縮在數(shù)據(jù)庫中被廣泛采納已有多年。Stacker公司為數(shù)據(jù)壓縮在PC

領(lǐng)域中的推廣做出了很大的貢獻，它把透亮數(shù)據(jù)壓縮加入到Microsoft的MS-DOS

操作系統(tǒng)中。這使得用戶可以在硬盤上存儲更多信息，而代價只是應(yīng)用性能很小

的降低。

OLTP應(yīng)用不能以一種通用的方式進行數(shù)據(jù)壓縮，主要是由于存在以下三個

問題：

1.第一個問題是其數(shù)據(jù)存儲方式（按行）不利于壓縮。這是因為這些數(shù)據(jù)

（大多為二進制數(shù)據(jù)）在以這種方式存儲時重復(fù)并不多。我們發(fā)覺，以傳統(tǒng)方式

存儲的數(shù)據(jù)，最多能有5-10%的壓縮比例；

2.其次個問題是對于很多的2K和4K的二進制數(shù)據(jù)的頁來說，為壓縮和

解壓縮而增加的開銷太大；

3.第三個問題是在OLTP環(huán)境中，大量讀取和更新混雜在一起。每一次更

新須要進行壓縮操作，而讀取只需解壓縮操作，大多數(shù)的數(shù)據(jù)壓縮算法在壓縮時

比解壓縮時慢4倍。這一開銷將明顯降低OLTP數(shù)據(jù)庫內(nèi)核的TPM率而使得數(shù)

據(jù)壓縮的代價昂貴到幾乎不能忍受。

DSS應(yīng)用中，數(shù)據(jù)壓縮可以用小得多的代價換取更大好處。其中包括削減

對于存儲量的要求；增大數(shù)據(jù)吞吐量，這相當于削減查詢響應(yīng)時間。

SybaseIQ在其Cache管理器或Buffer管理器中運用了數(shù)據(jù)壓縮。由于數(shù)據(jù)

垂直（按列）存儲，可以更多地實現(xiàn)壓縮。數(shù)據(jù)按列存儲，其二進制值的范圍通

常要小得多，所以壓縮更簡潔。SybaseIQ對垂直存儲的數(shù)據(jù)通常能得到大于50%

的壓縮。更大的壓縮比例，加上大頁面I/O,使得SybaseIQ在獲得查詢應(yīng)有的

全部優(yōu)良性能的同時，削減了對于存儲量的需求。

前面我們已經(jīng)看到垂直按列分割能削減95%的來自磁盤的數(shù)據(jù)，因而得以

將查詢響應(yīng)速度提高20倍。運用數(shù)據(jù)壓縮我們可以把20倍的速度進一步提高到

40倍，因為按列的數(shù)據(jù)壓縮在大多數(shù)狀況下可以削減50%的數(shù)據(jù)量。

DSS而進行了優(yōu)化的索引技術(shù)

通常，索引是數(shù)據(jù)庫內(nèi)核建立的，并用以削減針對給定查詢和更新的工作

量的數(shù)據(jù)結(jié)構(gòu)。這種工作量的削減主要是圍圍著避開對在相應(yīng)查詢時對下層的表

的全部或部分進行搜尋。工作量（多為I/O）的削減的結(jié)果是查詢響應(yīng)速度的加

快。

大多數(shù)流行的基于OLTP的RDBMS運用相像的索引方法，即“B-樹索引

盡管B-樹索引有很多不同形式，它們基本上都努力解決同一問題一一“大海撈

針”問題。也就是說，一張表中或許有數(shù)百萬條記錄，我們要找的只是其中之一。

例如，在一張以帳號為主碼的表中，有一個查詢須要找出帳號為4032的記錄。

基于OLTP的數(shù)據(jù)庫內(nèi)核的編寫和優(yōu)化都是針對這種查詢的，這種類型的查詢具

有高選擇性，這就意味著為了滿意查詢須要，表中僅有少數(shù)幾行須要被檢索到。

現(xiàn)在仍被OLTP數(shù)據(jù)庫運用的傳統(tǒng)B—樹索引技術(shù)在以下兩件事上做得較好。首

先，B一樹索引技術(shù)使得系統(tǒng)能快速找到某條特定記錄。其次，B-樹索引技術(shù)允

許個別記錄的快速更新，所以任何一條單獨的記錄都能快速修改。而不幸的是，

對于用戶來說，大多數(shù)DDS查詢都不會做以上兩件事，因而也就幾乎不能從B-

樹索引技術(shù)中得到什么好處。所以，在DSS應(yīng)用中運用傳統(tǒng)索引技術(shù)通常不能

帶來什么優(yōu)越性（甚至于可能帶來系統(tǒng)性能的降低）。

DSS應(yīng)用中通常不是高選擇性查詢而是恰恰相反。大多數(shù)DSS查詢具有高

度的非選擇性，所以在OLTP數(shù)據(jù)庫中負有盛名的B-樹索引技術(shù)不適用于DSS

應(yīng)用和查詢。一個數(shù)據(jù)庫內(nèi)核要針對DSS進行優(yōu)化，就必需采納一些別的可隨

意運用的索引技術(shù)。事實上SybaseIQ產(chǎn)品針對DSS應(yīng)用有四種完全不同的可隨

意運用的索引技術(shù)，這些技術(shù)中每一個都與DSS查詢問題相吻合。我們將在此

白皮書中探討其中的一部分。

數(shù)據(jù)屬性與SQL運用方式的關(guān)系

Sybase公司的開發(fā)人員發(fā)覺了列的秩（即不同的值的個數(shù)）與該列在SQL

語言和DSS應(yīng)用模型中的運用方式之間存在聯(lián)系。假如一列的秩較低（也就是

少于1000個不同的值），在DSS中該列會被最頻繁地用在SQL的WHERE子

句和GROUPBY子句中。當用在SQLWHERE子句中，低秩的列通常被用在EQ

（=）和NE（＜＞）謂詞中。在DSS中很少發(fā)覺低秩的列被用在范圍查詢和聚集

中。

一個具有特殊高的秩的列（超過100,000個不同的值），在DSS中常被用

于SQL的WHERE子句和聚集中。當用在SQL的WHERE子句中時，高秩的列

常用于范圍謂詞。

我們還發(fā)覺很多數(shù)據(jù)屬性隨時間變更保持相對穩(wěn)定。也就是說，秩、分布

和范圍保持相對穩(wěn)定。一個初始時秩為52的列（例如：州名），或許隨著時間

的推移其秩會增加到100,但很可能恒久也不會增加到100,000。數(shù)據(jù)的分布也

保持相對穩(wěn)定。仍以州名這一列為例，對大多數(shù)公司，在California的顧客數(shù)或

許比在RhodeIsland的顧客數(shù)更多，并且可能總是這樣。數(shù)據(jù)的范圍也趨向于保

持穩(wěn)定。

數(shù)據(jù)屬性的這些相對穩(wěn)定的特性可被利用以獲得更高的查詢性能。通常的

想法是：雖然針對特定目的的查詢按其定義是不行預(yù)料的，數(shù)據(jù)自身和它在DSS

中的運用方式是可預(yù)料的。這種可預(yù)料性可以用來提高查詢的性能。

低秩的索引技術(shù)

此項位圖索引技術(shù)從1960年起先推廣，如今很多產(chǎn)品都采納了這項技術(shù)，

SybaseIQ是第一個將這項技術(shù)用于解決關(guān)系型SQL查詢問題的數(shù)據(jù)庫產(chǎn)品。針

對非選擇性（低秩）的數(shù)據(jù)，此項技術(shù)能供應(yīng)比傳統(tǒng)的B-樹索引高得多的查詢

性能。值得指出的是，在典型的DSS數(shù)據(jù)庫中，低秩的列占了全部列的75%。

既然低秩數(shù)據(jù)的分布如此廣泛，那么能否對其進行高效的處理就顯得尤其重要。

低秩索引為維護索引字段上的每一個唯一的值創(chuàng)建一個稱為位圖（Bitmap）

的數(shù)據(jù)結(jié)構(gòu)。每一個位圖是數(shù)據(jù)庫中數(shù)據(jù)頁面的一個獨立的鏈。簡潔地說，它就

是一個二進制位的數(shù)組，這個二進制位的取值可以是0也可以是1。在此方法中，

相對的位號（例如，第1位，第2位，等等）用來表示數(shù)據(jù)庫中的表中的元組。

因此，我們就可以有一個紐約州的位圖，其中的第一位、第七位和第八位的位置

置為1,就表示第一個，第七個和第八個記錄滿意條件state="NewYork”。

LowCardinalityIndex

對于非選擇性的查詢謂詞，這項技術(shù)可以顯著改善查詢的響應(yīng)時間。讓我們

以下面的查詢?yōu)槔?，將傳統(tǒng)的B-樹索引技術(shù)和我們的低秩索引技術(shù)進行一下對

比：

SELECTCOUNT(*)FROMcustomers

WHEREstate="NY”

我們假設(shè)customers表中有10,000,000個元組，其中有2,000,000個的state

列的值為“NY”。

傳統(tǒng)的B-樹索引中將有10,000,000個實體，表中的每一個元組對應(yīng)索引中的

一個實體。每一個實體通常大約包含16字節(jié)(或128位)的信息。對傳統(tǒng)的B-

樹進行閱讀就須要從磁盤中讀取大約32MB(16*2,000,000)的數(shù)據(jù)。

低秩方法只須要從磁盤讀取1.25MB(10,000,000/8)的數(shù)據(jù)，這是采納B-

樹方法所要讀取的數(shù)據(jù)的1/25o因此，采納低秩方法的效率至少要比采納傳統(tǒng)的

B-樹方法要高25倍。

正如我們在前面所指出的，低秩數(shù)據(jù)在DSS中的運用特別普遍，主要用于運

用量化謂詞的WHERE子句和SQL的GROUPBY子句中。此項索引技術(shù)針對這

些操作進行優(yōu)化。例如，在GROUPBY的狀況下，假如索引已經(jīng)是依據(jù)GROUP

組織好的，并且不再須要進行排序，就可以很快將結(jié)果返回。

SybaseIQ低秩索引技術(shù)與其它技術(shù)的對比

SybaseIQ實現(xiàn)上述的低秩索引技術(shù)的方法有別于對同樣技術(shù)的其它的一些

實現(xiàn)方法。大多數(shù)實現(xiàn)(包括Oracle的實現(xiàn))只適用于指標特別低的狀況(例

如，秩＜50)。這是因為隨著秩的增長，索引的大小也將隨之增長，而隨著索引

的大小的增長，開銷增大，好用性降低。

形象地說，建立在50個唯一值和10,000,000個元組上的低秩索引須要

62.5MB的磁盤空間。當秩由50增至500時，所須要的磁盤空間猛增至625MB。

索引空間的爆炸性增長是使得此項技術(shù)只有在低秩狀況下才有好用價值的重要

緣由。

SybaseIQ通過增加數(shù)據(jù)壓縮技術(shù)勝利地解決了這一問題。通常，隨著秩的

增長，位圖中的值為0的位的個數(shù)快速增長。值為1的位的個數(shù)隨著元組個數(shù)的

增長而增長。因此，假如秩的增長幅度與元組個數(shù)的增長幅度相同，那么，所增

加的值為0的位的個數(shù)將遠遠大于所增加的值為1的位的個數(shù)。由于0的個數(shù)的

增加，使得壓縮的效果特別顯著。由于采納了這樣的技術(shù)，SybaseIQ可以將秩

的范圍由50（此時，大多數(shù)數(shù)據(jù)庫產(chǎn)品就不再運用此項技術(shù)了）擴展到500-1000。

Sybase在此項技術(shù)上取得了專利，這就使得我們的競爭對手要想超越我們就更加

困難了。

高秩索引技術(shù)

SybaseIQ所采納的另一項索引技術(shù)是獲得專利的高秩（HC）索引技術(shù)。這

項技術(shù)特地為具有HC數(shù)據(jù)的DSS查詢（包含聚集和WHERE子句中的范圍謂

詞）進行了優(yōu)化。

在這種方法中，數(shù)據(jù)列被分割成N個分別的位圖。每一個位圖對應(yīng)索引所在

的數(shù)值的一個有效位。例如，假設(shè)reve〃圖域是一個32位的無符號數(shù)，在這種

狀況下，SybaseIQHC索引就建立32個分別的位圖，每一個位圖對應(yīng)一個有效

位。以這種方式組織數(shù)據(jù)大大減小了數(shù)據(jù)的大小。大多數(shù)的reve/we數(shù)據(jù)通常沒

有運用32位有效數(shù)字中的全部。商務(wù)數(shù)據(jù)通常都有一個自然的數(shù)值的聚集區(qū)域,

只運用了40億種可能的取值中的很小的一部分。這種數(shù)值的聚集，加上SybaseIQ

的數(shù)據(jù)壓縮功能，使得索引只要運用實際數(shù)據(jù)所占用的空間的20%,甚至更少，

就可以表示全部的數(shù)據(jù)了。所用空間的減小，具有在位圖之間運用SET操作（SET

操作的運用與AND、OR和XOR操作完全相同）的實力，這些使得SybaseIQ

能夠快速計算出哪些元組在所指定的范圍內(nèi)，以及有關(guān)的SUM、AVG等統(tǒng)計結(jié)

果。此項索引技術(shù)使得范圍查詢操作很快由芯片微代碼演化成為軟件，并以向量

的形式加以實現(xiàn)。采納此項技術(shù)比采納傳統(tǒng)的B-樹要快10至100倍，這沒有什

么可驚異的，因為它存儲數(shù)據(jù)的方式是獨一無二的。目前，我們不知道還有哪一

家其他的數(shù)據(jù)庫公司采納了這項技術(shù)。Sybase在此項技術(shù)上擁有專利。

HighCardinalityIndexing

IfWPInQprtpdthenumber7intothpind^xnt

Row23.

Decimal7=0111Binary

TurnOnBit23inBitmap1,2,4.

1Bitmap2Bitmap4Bitmap8Bitmap

基于用戶的并行

傳統(tǒng)的基于OLTP的數(shù)據(jù)庫核心所采納的并行方法，如今已集中在一項簡潔

的技術(shù)，以解決DSS查詢的有關(guān)問題，這項技術(shù)稱為“并行表掃描”。這種方

法是特地為具有多處理器SMP硬件，并且一次運行一個預(yù)先規(guī)劃好的查詢的狀

況而設(shè)計的，它帶來了新的性能上的重大突破。它與早先的主機批處理類似，在

一次運行多個困難查詢的狀況下，這種方法就會變得很慢，并導(dǎo)致總體性能的降

低。

SybaseIQ還采納了一項圍繞DSS應(yīng)用模型而設(shè)計的方法。“并行表掃描”

的確不是解決查詢速度問題的最佳方法。

SybaseIQ采納的是針對用戶的并行模型。這就是說，在多處理器SMP環(huán)境

中，SybaseIQ會在用戶之間對CPU資源進行分布。它是為特定的多用戶DSS

應(yīng)用環(huán)境而設(shè)計的。SybaseIQ的設(shè)計目的在于最大限度地增加多個同時進行的

查詢的吞吐量，而不是為了支持一次一個的查詢的吞吐量的提高。它的每一個查

詢平均運用1.2個CPUo因此，在20個CPU的SMP機器上同時做15個特定查

詢，SybaseIQ的查詢性能與單機上處理一個查詢的性能大體相當。

DDS數(shù)據(jù)倉庫市場正在不斷發(fā)展，如今，沒有人再考慮做單用戶的OLTP

性能對比測試了。對DSS也是同樣，大多數(shù)公司都不希望為了創(chuàng)建和維護只有

一個用戶的數(shù)據(jù)倉庫花幾百萬美元。

查詢優(yōu)化

OLTP和DSS中的查詢優(yōu)化都是特別重要的，這兩個問題的關(guān)鍵性的差別在

于它們所能夠用于優(yōu)化的時間的多少不同。

OLTP引擎可以用于查詢優(yōu)化的時間特別少，沒有必要花30秒鐘來為一個執(zhí)

行時間僅僅1/10秒的查詢選擇最優(yōu)的查詢方案。存儲過程對此有所幫助，但是

從總體上講，大多數(shù)OLTP數(shù)據(jù)庫查詢優(yōu)化用在選擇查詢方案上的時間都不到一

秒。

另一方面，DSS的查詢優(yōu)化器可以花大量的時間來確定最佳的查詢方案。假

如大多數(shù)的DSS查詢的執(zhí)行時間都是5-10分鐘的話，那么花5-15秒來選擇一個

最終可能節(jié)約20分鐘的執(zhí)行時間的查詢方案就顯得特別必要了。

優(yōu)先線索模型

SybaseIQ運用的是一個非傳統(tǒng)型的數(shù)據(jù)庫核心線索模型。大多數(shù)OLTP數(shù)

據(jù)庫核心都實現(xiàn)了非優(yōu)先的或基于產(chǎn)量的線索模型。它們的每一個重型的進程中

都有很多非優(yōu)先性的重型的用戶線索。每一個引擎運用共享內(nèi)存來進行重型的進

程間的數(shù)據(jù)共享。對OLTP來講，這是一個不錯的模型，因為OLTP常常須要管

理特別小的工作單元，在這種狀況下，費時太多的操作系統(tǒng)的上下文切換會極大

的降低OLTP的性能。

SybaseIQ采納的是一個迥然不同的線索模型，對每一個并發(fā)的連接都有一

個重型的進程。在每一個重型的進程中，SybaseIQ又有很多輕型的或核心的線

索。這些線索是優(yōu)先的，OS對它們進行獨立的調(diào)度。由于SybaseIQ是在DSS

應(yīng)用模型中運做的，而DSS應(yīng)用模型中的平均工作單元是以秒，而不是以千分

秒來計的，因此SybaseIQ能夠充分利用這種新的方法所帶來的優(yōu)勢。下圖是

SybaseIQ進程模型的示意圖。

SybaseIQProcessDiagram

解決特定的的查詢問題

SybaseIQ通過大幅度降低索引的開銷和以異于大多數(shù)基于OLTP的數(shù)據(jù)庫

系統(tǒng)的方式對數(shù)據(jù)進行存儲和訪問，來達到解決特定的查詢問題的目的。在大多

數(shù)基于OLTP的數(shù)據(jù)庫中，核心索引的代價很高，主要緣由如下：

?索引的創(chuàng)建特別慢

?索引通常都特別大

?在增量更新中索引通常都特別慢

SybaseIQ針對這三點都進行了相應(yīng)的處理。

索引的創(chuàng)建速度快

首先，由于SybaseIQ采納的是針對DDS類型的操作而設(shè)計的索引數(shù)據(jù)結(jié)構(gòu),

所以創(chuàng)建索引能夠做得很快。SybaseIQ通常對每一列數(shù)據(jù)都創(chuàng)建一個索引，盡

管我們這樣做，在性能上還是大大超出那些只在10-15%的列上創(chuàng)建索引的競爭

對手。我們創(chuàng)建索引的速度是一般的OLTP數(shù)據(jù)庫創(chuàng)建索引的速度的10-20倍。

另外，與其它的數(shù)據(jù)庫一樣，我們也采納并行技術(shù)以便進一步提高索引的創(chuàng)建速

度。這樣，通過加快索引的創(chuàng)建速度，我們掃除了運用重型索引方法的第一個障

礙。

索引很小

SybaseIQ還順當?shù)亟鉀Q了有關(guān)索引的其次個問題。典型的OLTP數(shù)據(jù)庫核

心在存儲數(shù)據(jù)的基礎(chǔ)上附加數(shù)量較少的索引來幫助提高查詢的速度?；贒SS

應(yīng)用的OLTP數(shù)據(jù)庫的大多數(shù)實現(xiàn)須要的磁盤空間的數(shù)量大約是原始數(shù)據(jù)的3-6

倍。這就是說，假如你有100GB的原始數(shù)據(jù)，你還須要300-600GB的磁盤空間

來存儲OLTP索引，這樣，總的磁盤需求量大約是400-700GB。甚至在這種磁盤

空間爆炸的狀況下，也只有10-15%的數(shù)據(jù)上創(chuàng)建了索引。

SybaseIQ解決了索引大小的問題。SybaseIQ裝入數(shù)據(jù)，在數(shù)據(jù)庫中的每一

列上創(chuàng)建索引，并且所占用的空間遠遠小于協(xié)助數(shù)據(jù)所占用的空間。這樣，假如

有100GB的原始數(shù)據(jù)，在SybaseIQ中只須要一個100GB或不足100GB的數(shù)據(jù)

庫。

索引可以增量式裝入

大多數(shù)OLTP數(shù)據(jù)庫在數(shù)據(jù)的增量式裝入方面都存在嚴峻的問題。這就是說,

假如你一次裝入了100GB的原始數(shù)據(jù)并在其上創(chuàng)建了索引，再在此基礎(chǔ)上增加

100MB或幾個GB的數(shù)據(jù)都會特別特別慢。這一過程實在是太慢了，以至于假

如先刪除全部的OLTP索引，裝入增加的數(shù)據(jù)，再重新對整個數(shù)據(jù)庫創(chuàng)建索引反

而會快一點。

SybaseIQ在裝入其次個100MB或100GB的時候的速度幾乎與裝入第一批

數(shù)據(jù)一樣快。這是因為SybaseIQ存儲數(shù)據(jù)和創(chuàng)建索引的方式別出心裁。SybaseIQ

的索引是特地為增量式裝入而設(shè)計和開發(fā)的。這就給最終用戶帶來的更大的敏捷

性。

SybaseIQ使得索引的開銷大大降低，并供應(yīng)了一個新的開發(fā)環(huán)境，在這樣

的開發(fā)環(huán)境中，索引的運用可以比過去任何時候更充分。我們所設(shè)計的索引還更

適合于DSS類型的查詢的須要。這些特性結(jié)合起來，使得SybaseIQ與其它的基

于OLTP的數(shù)據(jù)庫核心相比具有更優(yōu)越的特定查詢相應(yīng)時間。

DSS與OLTP數(shù)據(jù)庫核心的對比

數(shù)據(jù)庫物理結(jié)構(gòu)的對立原則

現(xiàn)在，明顯很多數(shù)據(jù)庫核心所必需的，特殊是為了對DSS供應(yīng)強有力的支

持所必需的基礎(chǔ)技術(shù)會使OLTP操作變得很慢。反之也是如此，很多數(shù)據(jù)庫核心

所必需的,特殊是為了對OLTP供應(yīng)強有力的支持所必需的基礎(chǔ)技術(shù)也會使DSS

操作變得很緩慢。例如，前面所提到的垂直分割技術(shù)能夠使DSS查詢的速度提

高20多倍，同時垂直分割還會使OLTP查詢的速度減低20多倍。事務(wù)模型的種

類、數(shù)據(jù)庫頁面的大小、壓縮，以及垂直分割都是數(shù)據(jù)庫物理結(jié)構(gòu)的對立原則的

例子。DSS和OLTP在很多本質(zhì)的和重要的問題上處于兩個極端。

混合任務(wù)裝入數(shù)據(jù)庫核心

在同一個數(shù)據(jù)庫中進行混合任務(wù)裝入就好象“一邊為地板打蠟一邊刷牙”。

你當然可以這樣做，但是