Sybase数据仓库解决方案指南DW-whitepaper.doc_第1页
Sybase数据仓库解决方案指南DW-whitepaper.doc_第2页
Sybase数据仓库解决方案指南DW-whitepaper.doc_第3页
Sybase数据仓库解决方案指南DW-whitepaper.doc_第4页
Sybase数据仓库解决方案指南DW-whitepaper.doc_第5页
免费预览已结束,剩余43页可下载查看

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

目 录Sybase数据仓库解决方案指南2Sybase IQ技术白皮书8PowerDesignor WarehouseArchitect 6.025PowerDimensions实现动态OLAP31Sybase IQ为数据仓库应用带来的经济利益37Sybase IQ的性能测试44Sybase数据仓库解决方案指南数据仓库的概念 任何一个公司和企业,在订货、存货清单、票据清单、帐目清算、客户服务以及财务报告等方面都存在大量的业务应用和技术环节。数据仓库的作用在于:从这些应用系统中获取信息并转换到一个新的数据库,通过对新库中的历史信息和面向主题的信息进行分析,为决策提供支持。以往的产品系统,如订货或购置系统,则很难从中获得有关商业发展状况的信息。 数据仓库是企业决策支持的一部分。在做出下一个决定前,每个商业机构中的行政人员和分析人员都需要将许多关键商业问题搞清楚,例如:哪些产品最有利可图?哪些客户会为我们带来最大利益?哪些环节需要花费很高的费用?哪些市场活动运行得最好,为什么?我们有可能会失去哪些客户,为什么?这些都是数据仓库要回答的“百万利润”问题,也同时是一个最大的市场。据Gartner估计,60%的关系数据库管理系统被用作决策支持系统的应用开发。数据仓库与数据集市的比较 在二十世纪八十年代中期,Bill Inmon首次提出“数据仓库”这一名词。它最初被设计为一个商业数据库,具有稳定性(主要成分不变)、历史性(包含历史信息)和面向主题(信息由客户、产品和市场等组成)等特点。这些最初的“数据仓库”根据对客户、产品、销售情况和财务状况等信息的分析,得到对企业活动的整体认识。要建立一个数据仓库,一般分为四个步骤:第一步:数据库设计,即设计出一个包含商业数据和信息的数据库,为商业实体所用;第二步:开发数据抽取和转换程序,从产品系统中将数据取出后放入数据仓库中;第三步:开发数据加载和更新技术,使得在产品数据发生变化时,数据仓库得到动态实时的更新;第四步:购置查询和报表生成工具,令使用者通过企业内部网和个人计算机很方便地获取信息。 多年以来客户发现:尽管企业级数据仓库很有吸引力,但是具体操作起来有些难度。1996年“IDC研究”调查结果表明:尽管为建立数据仓库平均投入了三年多时间和近320万美元,50%没有达到应有的效果。从项目开始算起,三年后,大多数商人发现所面临的商业问题已经不再是开始建立时的样子,发生了很大变化。另外,尽管开发进度被延长了一年又一年,仍然做不到让所有感兴趣的客户对想看到什么信息给出明确的需求定义。因而“企业数据模型”的确立如同练习一样进行了一年又一年。 在最近的18-24个月的时间里,出现了一种新的解决办法,那就是数据集市。数据集市也是一种数据仓库,只是它更精练,更面向主题。Sybase公司自创立以来,便确立了在数据集市技术上的领导地位。目前,使用Sybase产品的2万多家客户中的大多数已经建立了运行在SQL Server上的数据集市,尽管通常也称为数据仓库,却几乎没有一个是企业级的。 数据集市的优势在于建设周期的缩短和费用上的大大降低。其中周期以月代替了年,费用从几百万下降到一百万。由于整个企业的数据很庞大,真正将它们集中到一个数据库中几乎是不可能的。有人便对很多大数据仓库实质上是不是数据集市产生了怀疑。使用数据集市后。设计、抽取、转换、加载和查询等环节变得更加简单,因为客户中的一部分人能够更精确地知道他们自己所需要的信息是什么。 然而,如果有很多的数据集市却不能使它们保持同步,数据集市解决方案就会遇到困难。一旦一个单位创建了两个或两个以上的数据集市,最大的问题就是如何使它们之间协调一致,如何使它们实时操作,以及如何维护所有的数据抽取和转换。另外,当一个单位要创建两个或两个以上的数据集市时,会发现每一个都要经过一个重新的设计、抽取、加载和查询步骤。于是,在面对多个数据集市的开发时,如何共享设计和结构成为一个有现实意义和挑战性的问题。运作型数据存储与合并式数据仓库 针对上述问题,一种解决方案是采用一种全新的数据仓库概念“运作型数据存储(Operational Data Store,ODS)”。在ODS方式下,数据被从业务数据库中复制到一个中心位置,再从这里被抽取到多个数据集市中。ODS是从客户、产品和其他商业角度来组织的,被称为商业状况的“实时快照”。它不包含历史信息,但可以很容易地满足一个历史数据库或一组面向主题的数据集市的需要。我们一般称之为“合并式数据仓库”,因为它在进入决策支持数据库以前是一个信息的结合点。ODS虽小,却能被经常地修改,因而非常适合于建立在Adaptive Server Enterprise和Replication Server上。多维或OLAP(联机分析处理)市场 作为数据仓库应用环节中的一部分,OLAP在市场份额上得到快速增长,变得越来越大。简单来说,OLAP是从商业角度进行信息组织,而不象通常的由行、列和表构成。例如,在一个类似Arbor 或Oracle Express的OLAP数据中,信息是通过客户、产品、日期、销售部门和地域等属性来存取的,这对于数据理解和信息获取来说都显得非常直观。 OLAP产品取得关系数据后,将它放入一个非常简单的表格中,使之很容易分析。OLAP数据库和一个OLAP产品可被看做一个多维表格。这个市场相当热门,Arbor、Oracle的Express 和Microstrategy在此领域中各占一席之地,而Sybase的PowerDimentions(原名whitelight),Cognos的Impromptu和Powerplay,Brio Technology的BrioQuery处于优势地位。竞争对手与合作伙伴一览RDBMS公司:Sybase,Oracle,IBM,Teradata/NCR,Informix,Microsoft硬件公司:IBM,Teradata,Sun,Digital/Compaq,HP转换工具:VMARK,Infomatica,Carleton/Apertus,ETZ,Prism SolutionsOLAP:Sybase/PowerDimentions,Arbor,Oracle/Express,Microstrategy,Infomation Advantage。Sybase 的解决方案及其组成 Sybase拥有一个独特而强有力的点对点方案,用来设计、建立和管理数据仓库和数据集市。各个部门之间通过集中的元数据进行交互,这便具有了完整性、集中性和灵活性等特点。我们的工具也具有很多优越性能。下表列出了各个组成部分:(1)PowerDesigner Warehouse ArchitectPowerDesigner不但是业界知名的数据库设计工具,也是数据仓库模型设计工具。其中的Warehouse Architect模块支持多种数据仓库模型,包括星型模式、雪花模式、以及雪暴模式。这是同行业中最优秀、最灵活的开发工具,可用来设计一个关系的或OLAP的软件仓库。PowerDesigner在数据仓库设计工具市场中占有最大份额。它能从已有的数据库进行反向工程,从运行系统中将现存的数据结构抽取出来形成数据模型,使设计变得简单。(2) PowerStage强大的数据抽取和数据转换产品。它是领导市场的客户/服务器转换方法,使数据仓库模型用PowerDesigner实现起来更加容易,更加直观。PowerStage真正是安全并基于引擎的。它有一个简单的面向处理的图形用户接口,使得用户可以快速启动,重复利用以往的工作,从任何源中获得数据。(3)适用于数据仓库的Adaptive Server for the WarehouseAdaptive Server for the Warehouse (ASW),是一个包含Adaptive Server Enterprise (ASE)和Adaptive Server IQ (ASIQ)的新关系数据库管理系统。它具有一项新的数据库查询技术直接英文查询。该产品使得高性能的OLAP和高性能的DSS在同一服务器上得到集成。Adaptive Server IQ,是服务于数据仓库的最优秀关系数据库管理系统,可以对数据库进行压缩,也可以以传统关系数据库管理系统的10至100倍的速度执行快速查询,使得数据规模可以达到并超过十亿行数据。(4)PowerDimensions快速、可扩展的联机分析工具。 这是业界中最新的OLAP解决方案,对建立于ASIQ和ASW数据库的数据可以提供快速灵活的多维模型建立和分析。区别于多维数据库,Powerdimensions能支持几百千兆以至万亿字节的原始数据和多个角度。(5)Intellidex Control Center对元数据和分布式数据集市提供点对点集中管理的产品。它是业界中管理分布式数据集市的唯一的完全点对点的解决方案。作为一个新产品,它提供了建立分布式数据集市的点对点方案,并且从一个中心位置上管理它们,它同时解决了业界中在元数据管理方面的问题。(6)SAFE/DW建立数据仓库的一套完整的测试方法,在世界上得到广泛应用。(7)Sybase专业服务是一个全球范围的数据仓库协作组织,可快速、可靠地设计和提供数据仓库解决方案。Sybase方案的主要好处1、快速实现由于Sybase的解决方案是集成的,客户只需要挑选一套最适合的产品集,即可使它们无缝地工作。这样,一方面可以快速实现,另一方面只需要面对一个厂商就可以获得全部的支持和服务。2、数据集市与中心仓库的无缝集成在市场上,Sybase方案唯一地能够将多个数据集市和中心仓库管理集成在一起。我们的方案是为企业提供的“唯一的可行方案”,对进入数据集市的数据移动、安全和元数据管理进行调度。3、极高的查询速度ASIQ是世界上用于决策支持(DSS)的最快速数据库。由于具有先进的Bit-wise索引技术,它能够以10至100倍于其竞争对手的速度查询,这些对手包括Oracle,RedBrack,Informix和Teradata。这更有利于最终用户的特殊的、重复的分析,也支持了在以前根本做不到的应用开发。4、高效的数据压缩ASIQ和ASE的数据压缩结果是传统RDBMS方法的三分之一至七分之一。在一个典型的ASIQ实现上,如果以五年左右时间来计算,一个Sybase方案可以做到每增加100GB数据节省大约41.5万美元(包括磁盘购置、维护和操作)。5、无限的可扩展性区别于传统的RDBMS解决方案,ASIQ和ASE将共同支持客户存放更多的历史和详细数据。客户经常会关心对VLDB的支持。采用Sybase解决方案后,数据库规模比用非Sybase解决方案要小得多。今天,我们的用户已经可以利用ASIQ数据库来存取万亿字节(TB级)的数据。6、面向不同数据库环境Sybase解决方案也可以适用在混合的非Sybase环境中。在数据库网关方面,Sybase是世界上的先驱者,可以直接访问25种不同的主机,以及其它的客户机/服务器数据库系统,通过其DirectConnect系列产品。我们同时为基于软件的数据仓库和数据集市提供了具有数据变化捕捉能力的复制服务器Replication Server,它可以反映Sybase、Oracle、DB2、VSAM、IMS以及其它关系型数据库中的数据变化。7、安全性和易管理性利用intellidex,我们的方案使IT用户仅通过一个简单的承诺模式,就可以管理分布的数据集市,具有高度的安全性、用户可控制性。除此之外,我们还有一个管理整个企业元数据的解决方案,这样既可以使用户创建自己的数据集市,也可以得到一个“唯一可行的方案”。intellidex能自动告诉用户哪些数据是在他们的数据集市中,这些数据从哪里来,以及到哪里去取等附加信息。8、提供强大的、可扩展的OLAP集成业务分析人员希望通过利用数据仓库中的数据做一些复杂分析。利用PowerDimensions,用户可以快速建立简单或复杂的多角度模型,直接访问数据仓库中的数据。而这些模型可以被成百上千的用户共享,允许分析人员建立一些能为最终用户的决策者所使用的业务模型。9、Web上的基于软件的数据仓库解决方案Sybase的PowerDimensions包含一个用来分析和查询的基于Java的浏览器。它支持图形、主元选择和表格模型。Sybase的PowerDynamo自动将数据仓库并入Web,产生简单的基于HTML的查询。10、丰富的经验Sybase在数据仓库和数据集市的实现方面经验丰富,涉及金融服务、电讯、医疗保健、公用事业、交通运输、媒体和娱乐业。正由于在业务和技术上的特长,我们可以快速地为客户建立实用可行的高效的解决方案。Sybase IQ技术白皮书数据库背景知识SQL数据库长期以来,数据库管理系统一直被用于在线事务处理(Online Transaction Processing,简称OLTP),也就是将日常事务处理中的数据以表的形式存放在数据库里。为了在数据库中“加入”数据,OLTP系统通常要发出查询一个记录或少量几个记录的命令,比如OLTP系统中的一个查询可能会查找某一个客户的数据记录,如在一个航空订票系统中查找订票号为35的记录。由此可以看出,OLTP系统查询数据的用途主要为满足即时性的事务处理需求,在这种需求中,查询比较简单,查询获得的数据列的数量(相对于整个数据表的大小)也较少。换句话说,OLTP系统是被优化用来执行“大海捞针”类型的任务的,即在大量的数据中寻找符合给定查询条件的少量记录。最近一段时间,人们对数据仓库的兴趣越来越浓。数据仓库是应用于决策支持系统(Decision Support System,简称DSS),对于这类应用来说,数据库系统的主要任务并不是“加入”信息,而是“提取”信息。提供DSS的作法通常是将基于SQL的OLTP数据库引擎(如Sybase SQL Server、Oracle或Informix)加以扩展以用来处理DSS应用。但是,这样构造出的DSS功能性能普遍较差,原因非常简单:这些数据库的底层物理结构都是专门为事务处理而设计和优化的,并不适用于DSS的分析性处理,所以这些数据库在OLTP应用中的性能非常好,而在DSS应用中的性能则出现明显差异。为了说明这一点,让我们来做个比喻。十年前,如果你想要买一辆自行车,你只要到商店去买一辆即可,你虽然可以在不同的颜色和式样中做选择,但自行车还是自行车。而现在,我们有山地车、赛车和特技用车等不同种类的自行车。之所以有这么多种自行车的原因是不同任务对自行车的物理要求也不同,例如山地车轮胎所必需的物理结构就与赛车完全不同。你虽然可以在山地环境中凑合使用赛车,但效果一定不会好。 对于数据库也是一样,让OLTP数据库来做DSS的工作,就象骑着赛车翻山越岭,原因是OLTP与DSS的基本物理结构的不同导致解决方案的不同。在一条非常平坦的山路上,你可以若无其事地骑几次赛车,但当骑行的次数增加或山路变得陡峭时,采用山地车这样专门解决方案就会显得非常明智。数据库结构大多数现代关系型数据库由五个主要部件组成,即句法分析/语言层(Parser/Language layer)、SQL节(SQL Catalog)、查询优化(Query Optimization)、查询运行库(Query Runtime)和数据库存储管理系统(Database Storage Management System)。以下是一个典型的数据库结构的示意图:典型的数据库结构句法分析/语言层SQL节查询优化查询运行库存储管理系统 让我们再回到自行车的比喻上。山地车和赛车都有车把、车座和脚蹬,这其中的一些部件是相同的,有些则是不同的,其不同之处是为了更有利于不同的用途。对于数据库也是一样,我们发现有利于提供DSS性能的数据库结构与原始数据库结构的不同之处主要在于数据库存储管理系统。一个专门为DSS编写的数据库存储管理器(Storage Manager)在处理DSS方面要远远优于为OLTP编写的存储管理器。多维数据库为了提供更多的解决方案,一些厂商实施了具有DSS功能的非SQL系统。这些非SQL或“多维数据库(Multi-Dimensional Database,简称MDDB)”有PilotTM和ComshareTM等。这些系统采用了一个能够让用户以一个类似立方体的形式查看数据的非关系型模型。这些系统典型的运作方式是先从SQL数据库中导出数据记录,然后以各种不同的专用格式将这些数据保存起来。信息一旦从SQL格式转化为专用的格式,就被保存在一个或多个服务器上以便让用户通过专用界面进行访问,因此这些系统一般都集成了专用的客户端或前端系统。 大多数被称为在线分析处理(Online Analytic Processing,简称OLAP)引擎的多维数据库产品试图以牺牲一些灵活性为代价获得更好的性能。用自行车的比喻来说,MDDB就象一辆行驶在两旁都是悬崖峭壁的山路上的山地车,如果你希望离开现成的小路,不是根本行不通,就是要付出很大的代价。 虽然MDDB能够以很高的速度完成预先设定好的分析工作,但这种方法也存在着重大的劣势,特别是当数据的容量达到10GB以上时,即用户必须事先将数据导入并整理成各种专用格式。然而实际上,用户通常希望数据以最基本的形式存在于SQL数据库表中,这其中至少有两个原因:一是长期以来收集与积累起来的信息业已以SQL格式保存在数据库中;二是用户已经对诸如Sybase或Oracle等主要的SQL数据库厂商的客户端查询软件非常熟悉。如果实施DSS需要有附加工具,用户会比较喜欢采用那些与他们日常所用工具同属一个家族的产品。现在大多数关系型数据库厂商正在或计划将MDDB技术融入到自己的关系数据库引擎中,而且有些厂商已经推出了各种对SQL语言的扩展,以为各自的用户群提供OLAP功能。为什么DSS与众不同 现在需要的是具有更佳DSS性能的系统和方法,而且这些系统和方法应属于用户所喜闻乐见的传统的SQL/关系型模式。从用户的角度来看,这样的系统将完全是一个基于SQL的关系型系统,但它提供很高的DSS性能。Sybase IQ就是这样一个满足以上要求的系统。这份白皮书将试图描述与讨论分别为DSS和OLTP用途而优化的数据库存储管理系统之间的根本性区别。什么是DSS?对不同的人来说,DSS是不同的东西。Sybase IQ为DSS提供了以下这些使用特点:OLTP与DSS预先设定查询特定查询简单查询复杂查询小查询结果集大查询结果集事务数量大事务数量小事务历时短事务历时长更新/选择主要为选择实时更新批更新细节行提取整理分组高选择性查询条件低选择性查询条件同时用户数大,1000以上同时用户数小,100以上多用户/特定查询DSS数据库领域必须成功解决的一个最为重要的问题是多用户的特定查询性能。基于OLTP的数据库无法在大量的数据上很好地完成此类查询,因为这些数据库是为预先设定好的查询而建立的。现在看来,这种只限于预设查询的高性能并不能提供一个健全的解决方案。当今用于特定和复杂查询的OLTP数据库采用的是并行表扫描方法。这种方法在一个大型SMP上只有一个用户的情况下,效果是最好的,但在多用户查询环境中的性能会大打折扣。原因是现在的大多数SMP系统只能同时支持一至两个大型的并行表扫描,如果扫描数量增加,不是CPU资源不够,就是耗尽了I/O总线的带宽。每一个表的扫描同时也使数据库缓冲完全失效,因为大多数大型DSS应用的表扫描都远大于物理缓冲区的存储能力。 Sybase IQ在开发的时候就考虑到多用户特定查询在本质上的不可预测性和对于DSS市场成功的极端重要性,因此我们寻找了其它可以预测的方面来努力提供性能。我们发现,虽然查询本身无法预测,但数据的属性是可以预测的。Sybase IQ利用这一点提供了更高的性能,这些技术中的一部分将在这份白皮书中予以讨论。事务模型 DSS与OLTP的事务特性是极为不同的。OLTP模型中有许多很短的事务,这些读取与更新的短小事务组成了一个混合体。数据库厂商花了很大的精力来提高自己的事务速率,通常的作法是对CPU上下文开关进行内部管理并通过去除代码间的模块性来缩短代码的路径长度。为了表明这些短事务的性能,大多数OLTP数据库都提供了各自的每分钟事务速率(Transaction Per Minute,简称TPM)。现在,大多数数据库可以达到18000TPM以上的速率。 而DSS的事务特点则截然不同。DSS中有许多长时间运行的只读事务和少量一些长时间运行的更新事务。总的来说,是注重查询的反应时间与批量更新能力。 人们通常知道在SMP环境中,只读(非登录)系统的性能要大大高于非只读(登录)系统,原因是需要有更多的系统资源来管理SMP环境中的可更新系统和运行大量的内容锁定。 DSS系统的优点在于能够在大多数情况下以非登录方式运行,从而提高了查询的性能。复杂查询 DSS与OLTP之间另一个重大的区别是查询的复杂程度。在OLTP环境中,查询总是比较简单,只涉及到数据库中少量的行,查询返回的通常是实际的细节数据。DSS查询要复杂一些,经常要涉及到数据库四分之一或更多的行,查询通常不返回实际的数据行,而是先把数据整理压缩到少量的几行后再交给用户。在OLTP数据库环境中,复杂的DSS查询总是要造成TPM的大大降低。DSS数据库内核物理结构上面我们讨论了OLTP与DSS的应用模型的一些不同之处。接下来我们将讨论为了支持DSS和OLTP这两种不同模式,数据库的内核层应有的一些差别。如果仍以自行车作比喻,那么我们下面想要说明的是:为什么用来登山时,为比赛而设计的赛车的性能不如为登山而设计的山地车。我们将讨论的是为什么这两种不同应用模型的结构需要采取不同的方案才能达到卓越的性能。数据库页面大小大多数的数据库中有数据库页面大小这一概念。页面大小通常代表着数据库送数据到磁盘或从磁盘取数据时以字节计算的内部数据量。这是数据库的基石,数据库其余操作都会用到这一概念。有趣的是,基于OLTP的应用模型在页面较小时性能较好,而基于DSS 的应用模型则在页面较大时性能较好。在OLTP系统中,从磁盘一次读/写的信息量通常只是一条或几条记录,所以I/O页面一般不大,大约2K至4K。假设一页数据约有50至100条记录,而每次查询或更新操作只涉及其中一条记录,这样就可以通过减少一页上的无关数据量来达到更高的I/O检索效率。在这个例子中,查询只用到缓慢的I/O 操作所取到数据的1/100到1/50,而由于数据库内核所采用的存储方式,数据库系统不得不检索所有这些数据。当数据库的大小与物理内存大小之比达到或超过2:1(当前典型的大型系统均如此)时,这一影响因素就变得不容忽视了。让我们以一台有1GB物理内存的机器为例说明,假设在这台机器上有一个10GB的数据库。假设数据均匀分布并且请求是随机的,那么每10次I/O中仅有1次会命中Cache,而其余的不能命中Cache,而必然导致物理I/O。既然大多数I/O都会导致物理I/O(与CPU访问内存相比物理I/O是一个极慢的操作),那么仅仅取那些必需的信息或元组能带来更高的性能。因此,同时满足以下两条规则前提下,页面越小,OLTP系统越好: 页面大小应大于或等于记录大小。 页面大小应大于或等于操作系统最小I/O传输量(常为2K或4K)。除此以外还有别的需考虑的因素,但这是最基本的两条。与此相反,典型DSS系统为了响应一个查询需取得大量信息;其操作通常需要查询数据库中的大量数据。如果DSS查询所取来的数据页中很大的一部分确实是DSS查询所需的(大约25%至100%),那么I/O页面大小可以增加到对于环境/平台来说最优的水平,例如以64K为数据页面的大小。从我们的测试可以看出,读一张10GB的表,163,840个64K的I/O显然比5,242,880个2K的I/O快得多。数据分割方式典型的OLTP数据库内核中数据库的一张表常常表示为一条数据库页的链(页链),每一数据页中有一个或多个数据记录或元组。这种方式适用于事务处理,当数据库要检索某条特定记录时,只需将存有该记录的相关数据页读入。我们将这种按页存储记录的方式称为“水平数据分割”,在这种方式下数据库将一张表水平分割为N个数据页,每页上有Y条完整记录。在DSS应用模型中,从查询性能的观点出发,这种水平分割方式是所有可能的数据存储方式中最不可取的。较好的方式是采用“垂直分割”,在这种方式下,每张表是一组相互独立的页链的集合,每一页链代表表中的一列。所以有100列的表将有100条相互独立的页链,每一列都有一条页链与之对应,而不是象OLTP中那样一张表对应一条页链。垂直按列进行页面链接所固有的优越性在于:大多数DSS查询只关心表中所有列的一个很小的子集。让我们以一个DSS应用为例,这个应用有两个较大的表,分别是Customers表和Transactions表。描述顾客的信息在Customers表中,而当一个顾客购买了某样东西,这一事件被记录到Transactions表中。Customers表和Transactions表通过顾客帐号(Account number)字段形成一对多的关系。为简单起见,不妨设每张表大小均为100GB且各有100列,两张表共有200列数据。我们发现大多数DSS类的查询只关注10个甚至是更少的列。此例中,数据的垂直按列存储方式将使得从磁盘检索的数据量至多是原来的1/20。这是由200(总列数)除以10(查询涉及的不同列的总数)得到,结果为20。磁盘检索数据量减少20倍,通常会使查询响应时间提高20倍。使用这一技术,Sybase IQ在最坏的情况下的查询方案是对查询涉及的所有列进行并行扫描,而不是象大多数的OLTP数据库内核那样进行并行的表扫描。然而,Sybase IQ也极少使用对查询涉及的所有列并行扫描的方式,而常常采用附加的技术以进一步减少查询时间。Cache命中率典型的大型数据库应用中,DSS类查询的Cache命中率很低。这是因为数据库大小与物理内存之比很大,而大多数被传统OLTP数据库内核执行的DSS型查询会导致对表的并行扫描。表扫描使Cache命中率降低,并且也使得后续查询也停留在如此低的命中率。Sybase IQ由于使用按列的垂直数据分割方式存储数据,Cache命中率大大提高。所以在反复查询或多用户查询的情况下,查询响应加快。这一提高是源于数据的更好的聚集方式,某些列,如连接字段或其它一些公共字段,由于数据垂直存储,将有更大的机会得以留在Cache中。数据压缩数据压缩在数据库中被广泛采用已有多年。Stacker公司为数据压缩在PC领域中的推广做出了很大的贡献,它把透明数据压缩加入到Microsoft的MS-DOS操作系统中。这使得用户可以在硬盘上存储更多信息,而代价只是应用性能很小的降低。OLTP应用不能以一种通用的方式进行数据压缩,主要是由于存在以下三个问题:1. 第一个问题是其数据存储方式(按行)不利于压缩。这是因为这些数据(大多为二进制数据)在以这种方式存储时重复并不多。我们发现,以传统方式存储的数据,最多能有5-10%的压缩比例;2. 第二个问题是对于许多的2K和4K的二进制数据的页来说,为压缩和解压缩而增加的开销太大;3. 第三个问题是在OLTP环境中,大量读取和更新混杂在一起。每一次更新需要进行压缩操作,而读取只需解压缩操作,大多数的数据压缩算法在压缩时比解压缩时慢4倍。这一开销将明显降低OLTP数据库内核的TPM率而使得数据压缩的代价昂贵到几乎不能忍受。DSS应用中,数据压缩可以用小得多的代价换取更大好处。其中包括减少对于存储量的要求;增大数据吞吐量,这相当于减少查询响应时间。Sybase IQ在其Cache管理器或Buffer管理器中使用了数据压缩。由于数据垂直(按列)存储,可以更多地实现压缩。数据按列存储,其二进制值的范围通常要小得多,所以压缩更容易。Sybase IQ对垂直存储的数据通常能得到大于50%的压缩。更大的压缩比例,加上大页面I/O,使得Sybase IQ在获得查询应有的所有优良性能的同时,减少了对于存储量的需求。前面我们已经看到垂直按列分割能减少95%的来自磁盘的数据,因而得以将查询响应速度提高20倍。使用数据压缩我们可以把20倍的速度进一步提高到40倍,因为按列的数据压缩在大多数情况下可以减少50%的数据量。DSS而进行了优化的索引技术通常,索引是数据库内核建立的,并用以减少针对给定查询和更新的工作量的数据结构。这种工作量的减少主要是围绕着避免对在相应查询时对下层的表的全部或部分进行搜索。工作量(多为I/O)的减少的结果是查询响应速度的加快。大多数流行的基于OLTP的RDBMS使用相似的索引方法,即“B-树索引”。尽管B-树索引有许多不同形式,它们基本上都努力解决同一问题“大海捞针”问题。也就是说,一张表中或许有数百万条记录,我们要找的只是其中之一。例如,在一张以帐号为主码的表中,有一个查询需要找出帐号为4032的记录。基于OLTP的数据库内核的编写和优化都是针对这种查询的,这种类型的查询具有高选择性,这就意味着为了满足查询需要,表中仅有少数几行需要被检索到。现在仍被OLTP数据库使用的传统B树索引技术在以下两件事上做得较好。首先,B树索引技术使得系统能迅速找到某条特定记录。其次,B-树索引技术允许个别记录的迅速更新,所以任何一条单独的记录都能迅速修改。而不幸的是,对于用户来说,大多数DDS查询都不会做以上两件事,因而也就几乎不能从B-树索引技术中得到什么好处。所以,在DSS应用中使用传统索引技术通常不能带来什么优越性(甚至于可能带来系统性能的降低)。DSS应用中通常不是高选择性查询而是恰恰相反。大多数DSS查询具有高度的非选择性,所以在OLTP数据库中负有盛名的B-树索引技术不适用于DSS应用和查询。一个数据库内核要针对DSS进行优化,就必须采用一些别的可随意使用的索引技术。事实上Sybase IQ产品针对DSS应用有四种完全不同的可随意使用的索引技术,这些技术中每一个都与DSS查询问题相吻合。我们将在此白皮书中讨论其中的一部分。数据属性与SQL使用方式的关系Sybase公司的开发人员发现了列的秩(即不同的值的个数)与该列在SQL语言和DSS应用模型中的使用方式之间存在联系。如果一列的秩较低(也就是少于1000个不同的值),在DSS中该列会被最频繁地用在SQL的WHERE子句和GROUP BY子句中。当用在SQL WHERE子句中,低秩的列通常被用在EQ()和NE()谓词中。在DSS中很少发现低秩的列被用在范围查询和聚集中。一个具有特别高的秩的列(超过100,000个不同的值),在DSS中常被用于SQL的WHERE子句和聚集中。当用在SQL的WHERE子句中时,高秩的列常用于范围谓词。我们还发现许多数据属性随时间变化保持相对稳定。也就是说,秩、分布和范围保持相对稳定。一个初始时秩为52的列(例如:州名),或许随着时间的推移其秩会增加到100,但很可能永远也不会增加到100,000。数据的分布也保持相对稳定。仍以州名这一列为例,对大多数公司,在California的顾客数或许比在Rhode Island的顾客数更多,并且可能总是这样。数据的范围也趋向于保持稳定。数据属性的这些相对稳定的特性可被利用以获得更高的查询性能。通常的想法是:虽然针对特定目的的查询按其定义是不可预测的,数据自身和它在DSS中的使用方式是可预测的。这种可预测性可以用来提高查询的性能。低秩的索引技术此项位图索引技术从1960年开始推广,如今许多产品都采用了这项技术,Sybase IQ是第一个将这项技术用于解决关系型SQL查询问题的数据库产品。针对非选择性(低秩)的数据,此项技术能提供比传统的B-树索引高得多的查询性能。值得指出的是,在典型的DSS数据库中,低秩的列占了所有列的75%。既然低秩数据的分布如此广泛,那么能否对其进行高效的处理就显得尤其重要。低秩索引为维护索引字段上的每一个唯一的值创建一个称为位图(Bitmap)的数据结构。每一个位图是数据库中数据页面的一个独立的链。简单地说,它就是一个二进制位的数组,这个二进制位的取值可以是0也可以是1。在此方法中,相对的位号(例如,第1位,第2位,等等)用来表示数据库中的表中的元组。因此,我们就可以有一个纽约州的位图,其中的第一位、第七位和第八位的位置置为1,就表示第一个,第七个和第八个记录满足条件state =“New York”。对于非选择性的查询谓词,这项技术可以显著改善查询的响应时间。让我们以下面的查询为例,将传统的B-树索引技术和我们的低秩索引技术进行一下对比:SELECT COUNT(*) FROM customersWHERE state=“NY”我们假设customers表中有10,000,000个元组,其中有2,000,000个的state列的值为“NY”。传统的B-树索引中将有10,000,000个实体,表中的每一个元组对应索引中的一个实体。每一个实体通常大约包含16字节(或128位)的信息。对传统的B-树进行浏览就需要从磁盘中读取大约32MB(16*2,000,000)的数据。低秩方法只需要从磁盘读取1.25MB(10,000,000/8)的数据,这是采用B-树方法所要读取的数据的1/25。因此,采用低秩方法的效率至少要比采用传统的B-树方法要高25倍。正如我们在前面所指出的,低秩数据在DSS中的使用十分普遍,主要用于使用量化谓词的WHERE子句和SQL的GROUP BY子句中。此项索引技术针对这些操作进行优化。例如,在GROUP BY的情况下,如果索引已经是按照GROUP组织好的,并且不再需要进行排序,就可以很快将结果返回。Sybase IQ低秩索引技术与其它技术的对比Sybase IQ实现上述的低秩索引技术的方法有别于对同样技术的其它的一些实现方法。大多数实现(包括Oracle的实现)只适用于指标非常低的情况(例如,秩50)。这是因为随着秩的增长,索引的大小也将随之增长,而随着索引的大小的增长,开销增大,实用性降低。形象地说,建立在50个唯一值和10,000,000个元组上的低秩索引需要62.5MB的磁盘空间。当秩由50增至500时,所需要的磁盘空间猛增至625MB。索引空间的爆炸性增长是使得此项技术只有在低秩情况下才有实用价值的重要原因。Sybase IQ通过增加数据压缩技术成功地解决了这一问题。通常,随着秩的增长,位图中的值为0的位的个数迅速增长。值为1的位的个数随着元组个数的增长而增长。因此,如果秩的增长幅度与元组个数的增长幅度相同,那么,所增加的值为0的位的个数将远远大于所增加的值为1的位的个数。由于0的个数的增加,使得压缩的效果非常显著。由于采用了这样的技术,Sybase IQ可以将秩的范围由50(此时,大多数数据库产品就不再使用此项技术了)扩展到500-1000。Sybase在此项技术上取得了专利,这就使得我们的竞争对手要想超越我们就更加困难了。高秩索引技术Sybase IQ所采用的另一项索引技术是获得专利的高秩(HC)索引技术。这项技术专门为具有HC数据的DSS查询(包含聚集和WHERE子句中的范围谓词)进行了优化。在这种方法中,数据列被分割成N个分离的位图。每一个位图对应索引所在的数值的一个有效位。例如,假设revenue域是一个32位的无符号数,在这种情况下,Sybase IQ HC索引就建立32个分离的位图,每一个位图对应一个有效位。以这种方式组织数据大大减小了数据的大小。大多数的revenue数据通常没有使用32位有效数字中的全部。商务数据通常都有一个自然的数值的聚集区域,只使用了40亿种可能的取值中的很小的一部分。这种数值的聚集,加上Sybase IQ的数据压缩功能,使得索引只要使用实际数据所占用的空间的20%,甚至更少,就可以表示所有的数据了。所用空间的减小,具有在位图之间使用SET操作(SET操作的使用与AND、OR和XOR操作完全相同)的能力,这些使得Sybase IQ能够快速计算出哪些元组在所指定的范围内,以及有关的SUM、AVG等统计结果。此项索引技术使得范围查询操作很快由芯片微代码演变成为软件,并以向量的形式加以实现。采用此项技术比采用传统的B-树要快10至100倍,这没有什么可惊讶的,因为它存储数据的方式是独一无二的。目前,我们不知道还有哪一家其他的数据库公司采用了这项技术。Sybase在此项技术上拥有专利。High Cardinality IndexingRow 23.If we Inserted the number 7 into the index atDecimal 7 = 0111 BinaryTurn On Bit 23 in Bitmap 1,2,4. 8 Bitmap 4 Bitmap 2 Bitmap 1 Bitmap基于用户的并行传统的基于OLTP的数据库核心所采用的并行方法,如今已集中在一项简单的技术,以解决DSS查询的有关问题,这项技术称为“并行表扫描”。这种方法是专门为具有多处理器SMP硬件,并且一次运行一个预先规划好的查询的情况而设计的,它带来了新的性能上的重大突破。它与早先的主机批处理类似,在一次运行多个复杂查询的情况下,这种方法就会变得很慢,并导致总体性能的降低。Sybase IQ还采用了一项围绕DSS应用模型而设计的方法。“并行表扫描”确实不是解决查询速度问题的最佳方法。Sybase IQ采用的是针对用户的并行模型。这就是说,在多处理器SMP环境中,Sybase IQ会在用户之间对CPU资源进行分布。它是为特定的多用户DSS应用环境而设计的。Sybase IQ的设计目的在于最大限度地增加多个同时进行的查询的吞吐量,而不是为了支持一次一个的查询的吞吐量的提高。它的每一个查询平均使用1.2个CPU。因此,在20个CPU的SMP机器上同时做15个特定查询,Sybase IQ的查询性能与单机上处理一个查询的性能大体相当。DDS数据仓库市场正在不断发展,如今,没有人再考虑做单用户的OLTP性能对比测试了。对DSS也是同样,大多数公司都不希望为了创建和维护只有一个用户的数据仓库花几百万美元。查询优化OLTP和DSS中的查询优化都是非常重要的,这两个问题的关键性的差别在于它们所能够用于优化的时间的多少不同。OLTP引擎可以用于查询优化的时间非常少,没有必要花30秒钟来为一个执行时间仅仅1/10秒的查询选择最优的查询方案。存储过程对此有所帮助,但是从总体上讲,大多数OLTP数据库查询优化用在选择查询方案上的时间都不到一秒。另一方面,DSS的查询优化器可以花大量的时间来确定最佳的查询方案。如果大多数的DSS查询的执行时间都是5-10分钟的话,那么花5-15秒来选择一个最终可能节省20分钟的执行时间的查询方案就显得非常必要了。优先线索模型Sybase IQ使用的是一个非传统型的数据库核心线索模型。大多数OLTP数据库核心都实现了非优先的或基于产量的线索模型。它们的每一个重型的进程中都有许多非优先性的重型的用户线索。每一个引擎使用共享内存来进行重型的进程间的数据共享。对OLTP来讲,这是一个不错的模型,因为OLTP常常需要管理非常小的工作单元,在这种情况下,费时太多的操作系统的上下文切换会极大的降低OLTP的性能。Sybase IQ采用的是一个截然不同的线索模型,对每一个并发的连接都有一个重型的进程。在每一个重型的进程中,Sybase IQ又有许多轻型的或核心的线索。这些线索是优先的,OS对它们进行独立的调度。由于Sybase IQ是在DSS应用模型中运做的,而DSS应用模型中的平均工作单元是以秒,而不是以千分秒来计的,因此Sybase IQ能够充分利用这种新的方法所带来的优势。下图是Sybase IQ进程模型的示意图。解决特定的的查询问题Sybase IQ通过大幅度降低索引的开销和以异于大多数基于OLTP的数据库系统的方式对数据进行存储和访问,来达到解决特定的查询问题的目的。在大多数基于OLTP的数据库中,核心索引的代价很高,主要原因如下: 索引的创建非常慢 索引通常都非常大 在增量更新中索引通常都非常慢Sybase IQ针对这三点都进行了相应的处理。索引的创建速度快首先,由于Sybase IQ采用的是针对DDS类型的操作而设计的索引数据结构,所以创建索引能够做得很快。Sybase IQ通常对每一列数据都创建一个索引,尽管我们这样做,在性能上还是大大超出那些只在10-15%的列上创建索引的竞争对手。我们创建索引的速度是普通的OLTP数据库创建索引的速度的10-20倍。另外,与其它的数据库一样,我们也采用并行技术以便进一步提高索引的创建速度。这样,通过加快索引的创建速度,我们扫除了使用重型索引方法的第一个障碍。索引很小Sybase IQ还顺利地解决了有关索引的第二个问题。典型的OLTP数据库核心在存储数据的基础上附加数量较少的索引来帮助提高查询的速度。基于DSS应用的OLTP数据库的大多数实现需要的磁盘空间的数量大约是原始数据的3-6倍。这就是说,如果你有100GB的原始数据,你还需要300-600GB的磁盘空间来存储OLTP索引,这样,总的磁盘需求量大约是400-700GB。甚至在这种磁盘空间爆炸的情况下,也只有10-15%的数据上创建了索引。Sybase IQ解决了索引大小的问题。Sybase IQ装入数据,在数据库中的每一列上创建索引,并且所占用的空间远远小于辅助数据所占用的空间。这样,如果有100GB的原始数据,在Sybase IQ中只需要一个100GB或不足100GB的数据库。索引可以增量式装入大多数OLTP数据库在数据的增量式装入方面都存在严重的问题。这就是说,如果你一次装入了100GB的原始数据并在其上创建了索引,再在此基础上增加100MB或几个GB的数据都会非常非常慢。这一过程实在是太慢了,以至于如果先删除所有的OLTP索引,装

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论