Sybase-Sun数据仓库参考架构性能基准测试报告
关于数据库的知识数不胜数,今天,小编为大家带来了新的关于数据库的内容。目录
数据仓库对的新需求
摘要
详细报告
平台配置概览
增至10亿条记录
性能测试详细情况
多表查询集
数据仓库对数据库的新需求
利用完整的信息及时作出正确的决策,这就是数据仓库所要完成的任务。随着数据仓库的不断发展,市场对数据仓库的核心组件——数据库引擎提出了新的需求。本次测试正是基于对这些需求的深刻认识。
1、海量数据
随着信息系统的不断发展,来自客户、产品、业务运营等的数据量不断膨胀,数据库容量逐渐成为 access数据库 事实上影响数据仓库性能的瓶颈,当传统的操作型数据库对海量数据的支持能力表现不佳,亟需一个经过验证的能够支持海量数据达到100TB以上的数据仓库参考模型。
2、实时数据加载
要及时准确的作出决策,就需要更接近实时的数据更新、即席查询、甚至人工智能。BI已经逐渐成为事务处理的完整部分。从数据库的角度来讲,不仅要求数据能够实时更新,而且要保证数据的实时加载对查询响应速度的影响最小。
3、复杂查询
商业智能从根本上来说已经不再是简单的查询,而越来越成为客户行为模式与客户特征及客户行为之间复杂的相互关系。“客户”数据库常常包含众多的客户属性,“客户”数据库是对家庭关系、复杂的企业组织、财务关系等的模型化。 数据的复杂性与问题的深度表明:商业智能的许多查询相当复杂。这要求数据库不仅能够处理单表的复杂查询,更要处理海量数据量下的跨表查询。
4、并行查询
基于Web,公司正逐步向客户、供应商、代理商以及其他商业合作伙伴开放对数据的访问,而不象从前只有总部的25个分析员或者公司高层在使用数据仓库,而且今天的信息交互模式远比从前复杂。这要求数据库必须能够处理大量的用户群,以及由此产生的大量并发查询。
5、快速响应
Internet的广泛使用对数据仓库带来重要影响:大量交互式的在线数据访问。用户希望在秒或分钟内获得结果,而不是几小时或整晚。这要求数据库引擎能够提供交互式的快速响应,即使是在海量数据、复杂查询、多用户与并行查询的情况下。
这些客户包括:
中国联通
中国电信
泰康保险
大鹏证券
兴业证券
招商银行
浙江地税
全国铁路局(客票系统)
山东烟草
上海**
兴澄钢铁
上海社保
美林证券
摩根斯坦利
Internal Revenue Service(IRS)
韩国朝兴银行
土耳其Yapi Kredi银行
比利时Fortis银行
挪威Lindoff资产管理机构
爱尔兰联合银行
加拿大蒙特利尔银行
MasterLink oracle数据库视频证券公司
韩国人寿保险公司
GE Capital保险服务公司
AT&T
澳大利亚Telstra移动公司
西班牙Telefonica电信公司
西班牙Airtel电信公司
英国RSL电信公司
葡萄牙Telecel电信公司
洛杉机时报
尼尔森媒体机构
North Jersey媒体集团
德国EMI唱片公司
AOL
加拿大统计局
巴西圣保罗财政局
美国尤他州财政局
美国航空
法国铁路运输局
美国运输管理局
……
一万亿行
Sybase-Sun数据仓库参考架构
摘要
2004年3月,应Sybase及Sun公司的要求,我对Sybase-Sun数据仓库参考架构的性能进行了检验,测试平台建于美国加州Palo Alto,基于该平台,我对基准测试进行了设计及检测。
这一企业级数据仓库参考架构,基于两台Sun Fire服务器以及 Sybase IQ,经过验证取得了众多意义重大的成就:
◆事实表的总行数达到1万亿行,这是迄今为止经过独立验证的最大的数据库;足以记录20多年来全美可以出售的每一笔铝矿。
◆深度数据存储及压缩比例,155TB的原始数据在存储到该数据仓库的星型模型中,实际只占用55TB的存储空间
◆在不断增加查询压力至5倍的情况下,同时维持查询响应时间及数据加载速度性能的能力(如下图所示)。
图1 |
#p#分页标题#e#
详细报告
数据仓库测试平台包括两**立的Sun服务器节点与一个共享磁盘架构,通过光纤与Sun磁盘阵列连接,数据库系统为Sybase IQ 12.5.0。
平台配置概览
图2 |
Sybase IQ Server配置
◆一个IQ 写(Writer)服务器,安装于A节点服务器。写服务器绑定了oracle数据库学习 24个CPU中的16个CPU,分配了4GB的主缓冲(Main IQ Cach)和4GB的临时缓冲(Temp IQ Cach)。
◆一个IQ查询服务器,安装于A节点服务器。该查询服务器绑定了剩下的8个CPU中的7个(剩余一个留给操作系统使用),分配了28GB的主缓冲和48GB的临时缓冲。
◆一个IQ查询服务器,安装于B节点服务器。该查询服务器绑定了24个CPU中的7个CPU(其余的CPU基本保持空闲),分配了20GB的主缓冲和20GB的临时缓冲。
增至10亿条记录
建立数据库 – Sybase IQ数据库以一个基本星型结构建立,以大量事实表为中心——每个事实表装载一个月的事实数据(每行25列)。建立四个维表用以对事实数据进行钻取。装载于维表的数据可以提供更大范围的表基数(从5千行到5亿行)。下图描述了维表的数据装载情况:
维表 | 行数 | 列数 | 行的大小 |
Customer(客户) | 500,000,000 | 11 | 246 Bytes |
Product(产品) | 1,000,000 | 8 | 144 Bytes |
Channel(渠道) | 5,00 | 6 | 106 Bytes |
Location(地址) | 30,000 | 7 | 108 Bytes |
初始装载 – 首先,建立一组事实表共60张。每张表装载1999年到2003年间的一个月的事实数据。数据由1亿条种子记录生成,通过对种子记录的一个或多个相关的域值进行多次修改以保证行的唯一性,然后对记录进行复制。使用Sybase IQ的索引技术,事实表完全被索引化。另外,在主键上建立一个high-group索引,在四个对应于维表的外键上也建立high-group索引。
第一次验证 – 接着定义了几张包含12张事实表的联合(UNION ALL)视图,为每年的数据各定义一张。同时,建立了一张包含所有5年的事实数据的视图。这样,确定了数据库的内容,接下来,我们进行了一系列的性能测试(详见后述)。
继续增加 – 在第一次验证之后,更多的事实表被建立,同时与第一次验证类似,装载了各年份的事实数据。Sun存储系统的配置相应的增加,为新建立的事实表提供空间。
跨越1万亿行的界限 – 总共对44张事实表进行了数据加载。然后定义了一个联合所有104张事实表的全局视图,涵盖了全部8年6个月的事实数据。下表描述了加载到事实表一万亿行中的数据的详细情况:
事实表 | 行数 | 列数 | 原始记录大小 | 原始数据大小 |
ALL_FACTS(所有事实表) | 1万亿 | 25 | 170 Bytes | 154.6 Terabytes |
最终验证 – 一万亿行数据加载的验证,以及对基于全局视图的跨表查询的执行,用以验证数据库是否依然运转正常,响应时间是否显著下降(详见后述)。
性能测试详细情况
执行以下的测试手段以验证性能:
◆基于6千亿条记录的多表连接
◆在已有6千亿条记录的情况下追加事实数据
◆基于6千亿条记录的并行加载与查询
◆基于1万亿条记录的多表连接
多表连接 – 定义了一组跨表连接(见后述),并基于6千亿条记录执行查询access数据库软件 。这些查询被一条一条的执行以获取基准响应时间。被测试的响应时间在5秒到500秒之间。
追加事实数据 – 在已有6千亿条记录的情况下,建立新的事实表。向新建的事实表追加新的数据,测量该加载速度以建立一个基准。接着删除该表,建立两张新表,同时向两张新表中追加数据,同样,测量并行加载的速度也可以建立一个基准。在并行加载的情况下,合计的加载速度为每分钟3千万条。
并行加载与查询 – 在执行两表并行加载的同时,不断增加执行的查询数目,直到有8条查询并行运行于同一个节点服务器。然后在另一台节点服务器上同时执行8条查询,共享同一个数据库。
在两台节点服务器上并行执行16条查询对两表并行加载的影响非常小,如下图所示,25分钟内有6700万条记录被加载。
图3 |
#p#分页标题#e#
包含10个连接查询的16条查询彼此之间对响应时间的影响也非常小(增加了不到10秒),相比于增加了5倍的查询流量。如下图所示:
图4 |
基于1万亿行的连接查询 – 在事实表行数增加到1万亿行之后,从查询集中挑选了一些查询进行执行。对查询语句“Where”从句中的时间参数进行调整以覆盖所有事实表中的时间范围。
通过对由Sybase IQ查询优化器选择的执行计划进行研究,证实了在这个巨大的一万亿行的“UNION ALL”的视图中,所有事实表都可以被这些查询访问到。尽管数据库的大小增加了65%,达到创记录的1万亿行,查询响应速度与先前测试的并行查询相比,并没有明显的影响。
多表查询集
用于大部分性能测试的查询集由下列10个查询组成,“WHERE”从句中的参数值根据每条查询而改变。
Query 1
SELECT LOCATION.STORE_NAME, |
Query 2
SELECT LOCATION.STORE_NAME, |
Query 3
SELECT STORE_NAME, |
Query 4
SELECT LOCATION.STORE_NAME, |
Query 5
SELECT CUSTOMER_FNAME, |
Query 6
SELECT STORE_NAME, |
#p#分页标题#e#
Query 7
SELECT CUSTOMER_FNAME, |
Query 8
SELECT CUSTOMER_SCORE, |
Query 9
SELECT CUSTOMER_SCORE, |
Query 10
SELECT CUSTOMER_SCORE, |
更多详情请咨询课课家官网,了解更多内容.