您的位置： >>
今天听了MSDN的WebCast，是关于Entlib的数据访问的讲座，末尾我问了两个自己所关心的问题：
在一个较大型的应用中，如果需要用到两套以上的数据库（如：SQL Server和Oracle），是否可以把需要的sql查询全部封装在存储过程里，这样就只需要一套访问代码了，有没有更好的方法解决这个问题？
在数据库的主键的设立中（同时支持多种数据库）直接用GUID作为主键来得简单，但是在查询的时候影响性能的因素大不大，还有没有更好的解决方法？
以上两个问题，由于时间的关系吧，微软的工程师解答的比较简略，第一个应该需要针对具体的应用来考虑，但是第二个问题，性能影响肯定是有的，但是影响大不大呢，带着这个问题，我做了这个小试验。
注：如果您有更好的建议不防贡献出来大家探讨探讨^_^！
测试环境：
Dell笔记本电脑 迅驰1.5G
Win XP professional
512MB DDR&RAM
SQL Server 2000 个人版
测试方法：
建立有10个字段的数据库[test_GUID]，使用GUID作为主键，以及其他常用的字段类型，模拟现实中的使用情况，建表的SQL代码如下：
CREATE TABLE [dbo].[Test_GUID] (&[GUID] [varchar] (50) COLLATE Chinese_PRC_CI_AS NOT NULL ,&[test1] [varchar] (50) COLLATE Chinese_PRC_CI_AS NULL ,&[test2] [datetime] NULL ,&[test3] [varchar] (50) COLLATE Chinese_PRC_CI_AS NULL ,&[test4] [varchar] (100) COLLATE Chinese_PRC_CI_AS NULL ,&[test5] [varchar] (100) COLLATE Chinese_PRC_CI_AS NULL ,&[test6] [varchar] (50) COLLATE Chinese_PRC_CI_AS NULL ,&[test7] [text] COLLATE Chinese_PRC_CI_AS NULL ,&[test8] [int] NULL ,&[test9] [int] NULL ) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]GO
ALTER TABLE [dbo].[Test_GUID] WITH NOCHECK ADD &CONSTRAINT [PK_Test_GUID] PRIMARY KEY& CLUSTERED &(&&[GUID]&)& ON [PRIMARY] GO
建立有10个字段的数据库[test_IIDD]，使用IIDD作为主键，以及其他常用的字段类型，模拟现实中的使用情况，建表的SQL代码如下：
CREATE TABLE [dbo].[Test_IIDD] (&[IIDD] [numeric] (9) IDENTITY(1,1) NOT NULL ,&[test1] [varchar] (50) COLLATE Chinese_PRC_CI_AS NULL ,&[test2] [datetime] NULL ,&[test3] [varchar] (50) COLLATE Chinese_PRC_CI_AS NULL ,&[test4] [varchar] (100) COLLATE Chinese_PRC_CI_AS NULL ,&[test5] [varchar] (100) COLLATE Chinese_PRC_CI_AS NULL ,&[test6] [varchar] (50) COLLATE Chinese_PRC_CI_AS NULL ,&[test7] [text] COLLATE Chinese_PRC_CI_AS NULL ,&[test8] [int] NULL ,&[test9] [int] NULL ) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]GO
ALTER TABLE [dbo].[Test_IIDD] WITH NOCHECK ADD &CONSTRAINT [PK_Test_IIDD] PRIMARY KEY& CLUSTERED &(& [IIDD]&)& ON [PRIMARY] GO
可以看到，第一个表使用全局唯一标识(GUID)来作为主键，而第二个表使用普通numeric（类似Int型）的数据类型来作为主键，关于GUID这里做一个小小介绍：
GUID，全局唯一标识，常用在COM组件的标识里，因为此几乎不可能生成重复的两个值，所以在各个领域经常用到，具体的值如：&A89C60-ABB5-6EAEAVE934D5&所示，你一定看到过类似的字符串吧，^_^，在SQL Server2000 中使用newid()函数来获取一个唯一的GUID
分别运行如下两个SQL语句对两个表分别插入10万条语句，我所关心大数据量的情况下的效果，所以不要怪我开始点选择10万条数据的情况^_^。
declare @num intset @num = 0while(@num & 100000)begin
insert into test_Guid values(newid(),'X222222',getdate(),'AAAAAAAAAAAAAAAAAA','BBBBBBBBBBBBBBBB','CCCCCCCCCCCCCCCCCCCCCC','DDDDDDDDDDDDDDDDD','479C8AAD--B53A-D6AF085AD38A479C8AAD--B53A-D6AF085AD38A479C8AAD--B53A-D6AF085AD38A479C8AAD--B53A-D6AF085AD38A479C8AAD--B53A-D6AF085AD38A479C8AAD--B53A-D6AF085AD38A479C8AAD--B53A-D6AF085AD38A479C8AAD--B53A-D6AF085AD38A','1','0')
set @num = @num+1end
declare @num intset @num = 0while(@num & 100000)begin
insert into test_IIDD values('X222222',getdate(),'AAAAAAAAAAAAAAAAAA','BBBBBBBBBBBBBBBB','CCCCCCCCCCCCCCCCCCCCCC','DDDDDDDDDDDDDDDDD','479C8AAD--B53A-D6AF085AD38A479C8AAD--B53A-D6AF085AD38A479C8AAD--B53A-D6AF085AD38A479C8AAD--B53A-D6AF085AD38A479C8AAD--B53A-D6AF085AD38A479C8AAD--B53A-D6AF085AD38A479C8AAD--B53A-D6AF085AD38A479C8AAD--B53A-D6AF085AD38A','1','0')
set @num = @num+1end
开始测试，测试代码及显示结果如下：
＃测试一 （GUID）
--------------------declare @times& datetimeset @times = getdate()--------------------select * from test_guid where guid='A89C60-ABB5-6EAEA0E934D5' orguid='FFFA8619-BC9F-4B76-ACE8-B3324105BBDE' orguid='FFFC26D5-6ECF-479D-838D-0D3E23AC7D2D' orguid='FFF9FA53-E115-450A-A52D-B0AET36FF539' orguid='A89C60-ABB5-6EAEAVE934D5' orguid='FFF90A0B-CB5B-446F-81FC-CFA661D03CF8' orguid='FFF85F4A-D1A-05C8BA3C1266' orguid='FFFF354A-ED3E-4C3A-A033-'order by guid desc
---------------------select datediff(second,@times,getdate()) as 秒,datediff(ms,@times,getdate()) as 毫秒---------------------
0秒，0毫秒，有时会有10毫秒的情况
＃测试二 （IIDD）
--------------------declare @times& datetimeset @times = getdate()--------------------select * from test_IIDD where IIDD='1' orIIDD='2' orIIDD='200' orIIDD='8000' orIIDD='8900' orIIDD='3' orIIDD='8' orIIDD='10000'order by IIDD desc
---------------------select datediff(second,@times,getdate()) as 秒,datediff(ms,@times,getdate()) as 毫秒---------------------
0秒，0毫秒，有时会有10毫秒的情况
可以看到在10万条数据的情况下，普通Select查询的时候效率影响还不大
＃测试三 （GUID）
--------------------declare @times& datetimeset @times = getdate()--------------------select count(*) from test_guid---------------------select datediff(second,@times,getdate()) as 秒,datediff(ms,@times,getdate()) as 毫秒---------------------
29秒，28793毫秒，效果不好啊！
＃测试四（IIDD）
--------------------declare @times& datetimeset @times = getdate()--------------------select count(*) from test_IIDD---------------------select datediff(second,@times,getdate()) as 秒,datediff(ms,@times,getdate()) as 毫秒---------------------
第一次运行3秒，第二次运行1秒，第三次运行0秒，50毫秒，my god！
这可如何是好，GUID在没有where子句的聚合运算时吃大亏了
＃测试五 （GUID）
--------------------declare @times& datetimeset @times = getdate()--------------------select count(*) from test_guid where test2 & ' 21:05:33.330' ---------------------select datediff(second,@times,getdate()) as 秒,datediff(ms,@times,getdate()) as 毫秒---------------------
29秒，29093毫秒，尽管查询出来只有200多条数据但速度没有变化！
＃测试六（IIDD）
--------------------declare @times& datetimeset @times = getdate()--------------------select count(*) from test_IIDDwheretest2 & ' 21:05:33.330'---------------------select datediff(second,@times,getdate()) as 秒,datediff(ms,@times,getdate()) as 毫秒---------------------
第一次运行2秒，第二次运行0秒，160毫秒，比没有Where的情况稍慢
如结果所示，效果很不理想
＃测试七 （GUID）
把test_GUID这个表的test2这一列（datetime）添加为索引列
运行【测试三】0秒，50毫秒，原来如此。。。
运行【测试五】0秒，0毫秒，非常明显了吧。
＃测试八（IIDD）
把test_IIDD这个表的test2这一列（datetime）添加为索引列
运行【测试四】0秒，40毫秒
运行【测试六】0秒，40毫秒
上面的测试七和测试八在返回值方面不尽相同造成一些微小的差别这个可以忽略（因为我测试了在相同返回值的情况下差别是很小的）
可以看出在以GUID作为主键的表中加一个时间类型或是Int类型的索引可以弥补以GUID作为主键带来的性能损失。
此次测试由于时间的关系，测试的比较片面也很肤浅，还望能有高手把不足和疏漏的地方进行补充和改进，在这次测试后我想我还会做更多的关于性能方面的测试，有精力再做吧。
此次测试就只得出这么一点肤浅的东西，希望没有浪费您宝贵的时间^_^！
精彩评论：
我想这个测试还存在一些问题，不是三言两语能说清楚的。挑几个我认为比较关键的说一说：
1、设计表时为什么用[GUID] [varchar] (50) ，是否出于兼容Oracle考虑？SQL Server中有UniqueIdentifier类型。&
2、测试结论有问题&在以GUID作为主键的表中加一个时间类型或是Int类型的索引可以弥补以GUID作为主键带来的性能损失&在SQL
Server中，如果在一个有聚簇索引的表上再建立其它索引，那么其它索引链接的就不是页节点了，而是聚簇索引节点。也就是说，一个普通索引上的查询先检索普通索引，然后索引会告诉你对应数据的聚簇索引是什么，然后聚簇索引再告诉你数据再哪里。（可以参考微软SQL
Server培训教程）。不过这并不是问题的关键。关键在下面：&
3、在上面的测试中，测试命令是：select count(*) from ... where test2 &
21:05:33.330'。问题发生在了count(*)上面。这里的查询只是计数，因此我们管它叫做索引覆盖查询，也就是只查时间索引就可以得到计数值，聚簇索引根本没有派上用场，也就是说根本没有比较聚簇索引的效率，所以你得到了速度一致的结论。这里，测试设计上有问题。你可以试试select
*替换select count(*) ，我想结果差异应当非常明显。关于索引可以参考
希望楼主再实验一下。
dragonpro: 　　我非常想用GUID做主键用在我们开发的系统里面，但是这涉及到的问题也是需要充分考虑的，为了这些问题，特别是性能问题，我都考虑很久了，希望能有个满意的处理方式，我的系统希望支持至少两种数据库，特别需要支持Oracle。
　　但在做表的时候，如果在表里不使用另外的非聚集索引，我想很多查询都会比较慢，那就比较可怕了。　　又做了下测试，用UniqueIdentifier类型的话跟Int型的在查询方面相差不大，但是用varchar类型者需要在其他字段建立非聚集索引来为查询优化创造条件，不知道这样认为是否合适。
　　再有，在插入数据的时候如果GUID字段为聚集索引的话，由于字段值是随机的，我插入的数据并不知道要放在什么位置，这样是否也需要选择新记录插
入的位置而消耗操作时间，所以我想索性指定一个日期型字段来作为聚集索引，这样增加记录基本上都是在末尾，这样是否能有效减少了数据操作时间呢？
吕震宇: 非常佩服楼主的敬业精神。我还想说两句，不知楼主是否赞同我的看法：
1、"看来用GUID作为主键必须要另外加索引才能保证入count这样的计算不至于消耗太多时间"，在这里另外的索引必须是你的Where短语中用到的字段，否则是不会带来性能提升的。
2、&我插入的数据并不知道要放在什么位置，这样是否也需要选择新记录插入的位置而消耗操作时间&，我以前也一直是这么想的，但感觉自己想法有问
题。我猜测加入GUID的聚簇索引主键时不会为选择新的插入位置消耗太多的时间。因为聚簇索引的页节点是数据节点，因此完全可以在枝节点上做文章以减少系
统的消耗。这只是我的猜测。所以用GUID与用时间做聚簇索引性能应当差别不大。当然这也是我的猜测。
3、我不太赞同用时间做聚集索引，说不出为什么，感觉不太好。似乎没有做到&专职专责&。
数据库热门文章
数据库最新文章8129人阅读
大数据（90）
随着开源Hapdoop、Map/Reduce、Spark、HDFS、HBASE等技术的商用化，大数据管理技术得到了突飞猛进的发展。一般来说，大数据具有3V特性，即Volume（海量）、Velocity（高速）和Variety（多样）[1]。TPC联合主席、Cisco高级工程师Raghunath Nambiar进一步认为大数据还面临Value（价值）和Veracity（精确）的挑战。如何客观地比较不同数据管理系统，即大数据测试基准的选择，成为一个重要的研究课题。
事务性能管理委员会(TPC)是目前最知名的数据管理系统评测基准标准化组织。在过去二十多年间，该机构发布了多款数据库评测基准，如TPC-A、TPC-D、TPC-H和TPC-DS，在业界得到了广泛应用[2]。BigBench和BigFrame是对TPC-DS进行多样化的数据扩充的测试基准。近年来，Apache开源社区针对Map/reduce架构开发了多款性能测试用例，如TestDFSIO、teraSort。国内对大数据测试基准的研究起步较晚，尚未建立起权威的测试基准。目前由中国信息通信研究院牵头，联合中科院计算所及国内外知名公司和机构共同制定的大数据测试基准正在金罗密布的测试中[3]。
为了方便企业选择合适的大数据测试基准，本文将在分析总结现有成果的基础，进一步讨论大数据测试基准应该具有的要素；并以此为基础，对比现有的大数据测试基准；然后重点讨论TPC-DS测试基准。
一、大数据测试基准的选择
企业在选择大数据测试基准时，首先应考虑基准与其自身业务的相关性。
1. 与其自身业务的相关性
它主要描述测试基准设定的应用场景是否与企业的实际业务场景类似，如基于社交网络应用的评测基准与银行系统的应用场景就没有什么相关性。不相关的基准，测试结果再好，也没有实际意义。相关性还要考虑测试基准所采用的数据模型是否代表数据仓库的发展方向，如基于星型模型的开发要比基于传统的关系模型开发更加有效。
当然，一套行之有效的大数据测试基准包含许多其它要素。Jim Gray及金澈清等学者[4]已经对度量选取、模拟数据生成器、工作负载设定、审计等要素进行了详细论述。除此之外，本文还认为测试基准的健壮性、SQL标准的兼容性和通用性/可移植性也是重要的要素。
2. 模拟数据生成要具有真实性
它描述了测试基准是否仿真真实应用场景，所产生的模拟数据是否与真实数据相似。
3. 工作负载的设定具有可扩展性
它描述该评测基准是否适用于不同规模的计算机系统，许多评测基准会使用标度因子来决定模拟数据的规模，通过调整标度因子来得到不同规模的工作负载。
4. 度量的选取的可理解性
它衡量该评测基准是否易于为用户理解，不易为用户理解的基准的可信程度也较低。
5. 客观性与公正性
众所周知，在竞技比赛中，一个人不能既是运动员又是裁判员。测试基准好比竞技比赛中的裁判员，应该由中立的第三方机构制定。事实也证明，在各个领域最受欢迎的测试基准都是有第三方机构设计的。过去20多年的经历证明TPC系列基准是数据库领域最为广泛接受的基准。除此之外，第三方机构的审计也是保证证评测结果的客观性与公正性的重要手段。
测试基准要足够健壮，不能轻易被“hack”，这对测试结果的公平性非常重要。例如对TPC-H的前身TPC-D，通过物理化视图，Oracle的性能比Micosoft的SQLServer高100倍，这些显然是不公平的。因此TPC组织规定TPC-H测试中物理化视图是不和法的。但是除非是专业人员，一般用户很难判定测试过程中视图有没有被物理化。TPC-DS在健壮行方面要好很多，因为它的SQL本身比较复杂，也比较多，Hack起来相对困难，并且只hack几个SQL对整体性能提高有限。
7. SQL标准兼容性
SQL是ANSI为统一各个数据库厂商之间的编程差异定义的标准，已发布SQL86、SQL92、SQL99、SQL2003等版本。这些标准已经被主流的商用（例如Oracle、DB2、SQL server）以及开源的数据库产品（例如MySQL、mSQL和PostgreSQL）的广泛采用。对整个数据库产业的发展起到了巨大的推动作用。大数据是个新兴的领域，它的发展不能完全抛弃原有的应用。如果不能全面支持SQL标准，现有系统的移植非常困难，学习曲线就会变长。
8. 通用性/可迁移性
通用性描述是否可在不同数据库系统和架构上实现指定的评测基准。测试基准不应该规定实现的细节，而只需要定义测试规范。DBMS只要遵循规范得到正确的结果，就是合理的测试，无论其基于Map/Reduce、Spark还是其他的技术，也不管其底层存储是用HDFS、HBASE还是其他方式。
二、大数据测试基准对比
经过30几年的研究，传统数据库测试基准的研究已经相当成熟，在各个领域出现了行之有效的测试基准。随着大数据应用的发展，大数据测试基准的研究最近几年逐渐兴起，但大都是在传统的测试基准的基础进行裁剪、扩充、综合。金澈清等学者[4]对数据库基准的发展概述如图1所示。
本文重点关注被列为大数据测试基准的相关基准、BigFrame[5]以及TPC-DS，对其它的基准本文不再赘述，有兴趣的读者请参阅文[4]。
1. Map/reduce性能测试
如文[4]中所述，MRBench、HiBench、TestDFSIO、Sort/teraSort只是针对Map/Reduce框架，目的是评测运行Map/Reduce框架的集群的性能。CALDA基准尝试比较不同架构在数据管理方面的性能。这些测试过于简单，无法模拟复杂的应用，也不通用。
2. YCSB/YCSB++/LinkBench
这是一组针对网络应用的测试基准。YCSB（Yahoo! Cloud Serving Benchmark）及其扩展YCSB++测试查询回复的延时等云服务系统中云计算的特点，如查询回复的延时、纵向扩展和弹性加速比、并行性测试等。LinkBench是一个基于社交网络应用的评测基准。它仿真Facebook公司的图数据管理应用，包括数据特性、工作负载以及度量等。这些都是公司开发的针对自己特定应用场景的测试基准，很难在整个行业内进行推广。
3. BigBench
BigBench是一款面向商品零售业的基准，它扩展了TPC-DS，综合考虑多种数据模态，增加了半结构化数据Web Log和非结构化数据Reviews。其负载的生成是TPC-DS定制化的版本。BigBench包含30个查询。BigBench基本数据模型如图2所示：
4. BigFrame
BigFrame是一个测试基准生成器[5]，用户可以根据自己的需求定制专有测试基准。在目前实现中，其关系模型与BigBench类似，也是基于TPC-DS。同时它扩展了半结构化和非结构化的数据Tweets以及图形化数据Followee/Follower。BigFrame基本数据模型如图3所示：
如文[5]所述，大数据与决策支持系统（DSS）并不是完全独立的，大数据也不能抛弃传统。DSS系统中，只要数据量足够大，都可以认为是大数据问题。被化为大数据测试基准的BigBench和BigFrame的大部分内容都来自于TPC-DS，从这个意义上讲，TPC-DS不但是一种结构数据的大数据测试基准，而且是其它大数据测试基准的基础。
三、TPC-DS
TPC-DS测试基准是TPC组织推出的用于替代TPC-H的下一代决策支持系统测试基准。因此在讨论TPC-DS之前，先介绍一下TPC-H。
TPC-H是一款面向商品零售业的决策支持系统测试基准，它定义了8张表，22个查询，遵循SQL92。TPC-H的数据模型如图4所示。TPC-H基准的数据库模式遵循第三范式，叶晓俊教授等学者[6]认为“它的数据表数据特征单一(如数据不倾斜) ，其数据维护功能仅仅限制了潜在的对索引的过度使用，而没有测试DBMS 执行真实数据维护操作——数据提取、转换和加载(ETL) 功能的能力”。同时，新兴的数据仓库开始采用新的模型，如星型模型、雪花模型。TPC-H已经不能精准反映当今数据库系统的真实性能。为此，TPC组织推出了新一代的面向决策应用的TPC-DS
TPC-DS采用星型、雪花型等多维数据模式。它包含7张事实表，17张纬度表平均每张表含有18列。其工作负载包含99个SQL查询，覆盖SQL99和2003的核心部分以及OLAP。这个测试集包含对大数据集的统计、报表生成、联机查询、数据挖掘等复杂应用，测试用的数据和值是有倾斜的，与真实数据一致。可以说TPC-DS是与真实场景非常接近的一个测试集，也是难度较大的一个测试集。
TPC-DS的这个特点跟大数据的分析挖掘应用非常类似。Hadoop等大数据分析技术也是对海量数据进行大规模的数据分析和深度挖掘，也包含交互式联机查询和统计报表类应用，同时大数据的数据质量也较低，数据分布是真实而不均匀的。因此TPC-DS成为客观衡量多个不同Hadoop版本以及SQL on Hadoop技术的最佳测试集。这个基准测试有以下几个主要特点：
一共99个测试案例，遵循SQL’99和SQL 2003的语法标准，SQL案例比较复杂分析的数据量大，并且测试案例是在回答真实的商业问题测试案例中包含各种业务模型（如分析报告型，迭代式的联机分析型，数据挖掘型等）几乎所有的测试案例都有很高的IO负载和CPU计算需求
叶晓俊等学者对这些查询的分部总结如表1所示[6]。典型的Store_Sales的数据模型如图5所示。这个基准测试的完整信息请参考。
3. TPC-DS认证现状
TPC-DS以其高标准、高要求得到大家的广泛认知，理应得到广泛的应用，但是到目前为止还没有任何厂商得到TPC官方的认证。究其原因，本文认为：
传统的数据库厂商，DBMS系统比较成熟，SQL的支持也相当完善，但是其分布式、并行处理能力欠缺，导致其性能很差。所以传统的厂商不愿意发布测试结果。
新型的计算模型如Map/Reduce、spark，具有较好的并行处理能力，但是SQL的兼容性比较差，如HiveSQL、SparkSQL只支持40个SQL，从而也无法发布TPC-DS测试报告。尽管如此，各厂商还是通过非TPC官方的途径发布TPC-DS的部分测试结果，以展现其在性能方面的提升。由此可见大家对TPC-DS的程接受度。
四、结束语
大数据评测基准用于公平、客观地评测不同大数据库产品/平台的功能和性能，对人们选择合适的大数据分析决策系统具有重要的参考价值。随着国内外各代表性的Hadoop发行版厂商以TPC-DS为标准测评产品，TPC-DS也就逐渐成为了业界公认的大数据系统测试基准。但是随着大数据应用在各行各业的发展，测试基准也需不断与时俱进。大数据测试基准仍然面临着诸多挑战，还需要政府、学术界和工业界的紧密合作。
[1]Big data: Science in the petabyte era. Nature, : 1-136
[2]www.tpc.org
[4]金澈清, 钱卫宁, 周敏奇, 周傲英，数据管理系统评测基准：从传统数据库到新兴大数据，计算机学报, 2014.
[5]M. Barata, etc, Survey on Big Data and Decision Support Benchmarks, LNCS –182, 2014.
[6]陈旦，叶晓俊，施霖, TPC-DS性能测试工具的实现, 计算机应用，第31 卷，第9期, 2011.
&&相关文章推荐
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：231132次
积分：3250
积分：3250
排名：第9441名
原创：89篇
转载：105篇
评论：25条
(14)(1)(2)(6)(2)(1)(12)(11)(15)(22)(22)(14)(9)(2)(1)(2)(1)(5)(3)(1)(1)(3)(2)(2)(4)(24)(15)本帖子已过去太久远了，不再提供回复功能。企业如何选择合适的大数据产品测试基准
　作者: 谭磊　编辑:
　　【IT168 技术】随着开源Hapdoop、Map/Reduce、Spark、HDFS、HBASE等技术的商用化，大数据管理技术得到了突飞猛进的发展。一般来说，大数据具有3V特性，即Volume(海量)、Velocity(高速)和Variety(多样)[1]。TPC联合主席、Cisco高级工程师Raghunath Nambiar进一步认为大数据还面临Value(价值)和Veracity(精确)的挑战。　　今天越来越多的企业认识到，大数据的掌控和分析能力将成为竞争力的核心，企业对大数据的投资也在不断扩大。Gartner调查显示，73%的企业计划在未来两年内投资大数据。然而对于很多企业用户来说，如何评价一个大数据平台的综合能力，客观地比较不同数据管理系统，即大数据测试基准的选择，常常是选型、平台建设和系统优化时面临的一大挑战。　　事务性能管理委员会(TPC)是目前最知名的数据管理系统评测基准标准化组织。在过去二十多年间，该机构发布了多款数据库评测基准，如TPC-A、TPC-D、TPC-H和TPC-DS，在业界得到了广泛应用[2]。BigBench和BigFrame是对TPC-DS进行多样化的数据扩充的测试基准。近年来，Apache开源社区针对Map/reduce架构开发了多款性能测试用例，如TestDFSIO、teraSort。国内对大数据测试基准的研究起步较晚，尚未建立起权威的测试基准。目前由中国信息通信研究院牵头，联合中科院计算所及国内外知名公司和机构共同制定的大数据测试基准正在紧罗密布的测试中[3]。　　为了方便企业选择合适的大数据测试基准，本文将在分析总结现有成果的基础，进一步讨论大数据测试基准应该具有的要素;并以此为基础，对比现有的大数据测试基准;然后重点讨论TPC-DS测试基准。　　大数据测试基准的选择　　企业在选择大数据测试基准时，首先应考虑基准与其自身业务的相关性。　　与其自身业务的相关性　　它主要描述测试基准设定的应用场景是否与企业的实际业务场景类似，如基于社交网络应用的评测基准与银行系统的应用场景就没有什么相关性。不相关的基准，测试结果再好，也没有实际意义。相关性还要考虑测试基准所采用的数据模型是否代表数据仓库的发展方向，如基于星型模型的开发要比基于传统的关系模型开发更加有效。　　当然，一套行之有效的大数据测试基准包含许多其它要素。Jim Gray及金澈清等学者[4]已经对度量选取、模拟数据生成器、工作负载设定、审计等要素进行了详细论述。除此之外，本文还认为测试基准的健壮性、SQL标准的兼容性和通用性/可移植性也是重要的要素。　　模拟数据生成要具有真实性　　它描述了测试基准是否仿真真实应用场景，所产生的模拟数据是否与真实数据相似。　　工作负载的设定具有可扩展性　　它描述该评测基准是否适用于不同规模的计算机系统，许多评测基准会使用标度因子来决定模拟数据的规模，通过调整标度因子来得到不同规模的工作负载。　　度量的选取的可理解性　　它衡量该评测基准是否易于为用户理解，不易为用户理解的基准的可信程度也较低。　　客观性与公正性　　众所周知，在竞技比赛中，一个人不能既是运动员又是裁判员。测试基准好比竞技比赛中的裁判员，应该由中立的第三方机构制定。事实也证明，在各个领域最受欢迎的测试基准都是有第三方机构设计的。过去20多年的经历证明TPC系列基准是数据库领域最为广泛接受的基准。除此之外，第三方机构的审计也是保证证评测结果的客观性与公正性的重要手段。　　健壮性　　测试基准要足够健壮，不能轻易被“hack”，这对测试结果的公平性非常重要。例如对TPC-H的前身TPC-D，通过物理化视图，Oracle的性能比Micosoft的SQLServer高100倍，这些显然是不公平的。因此TPC组织规定TPC-H测试中物理化视图是不和法的。但是除非是专业人员，一般用户很难判定测试过程中视图有没有被物理化。TPC-DS在健壮行方面要好很多，因为它的SQL本身比较复杂，也比较多，Hack起来相对困难，并且只hack几个SQL对整体性能提高有限。　　SQL标准兼容性　　SQL是ANSI为统一各个数据库厂商之间的编程差异定义的标准，已发布SQL86、SQL92、SQL99、SQL2003等版本。这些标准已经被主流的商用(例如Oracle、DB2、SQL server)以及开源的数据库产品(例如MySQL、mSQL和PostgreSQL)的广泛采用。对整个数据库产业的发展起到了巨大的推动作用。大数据是个新兴的领域，它的发展不能完全抛弃原有的应用。如果不能全面支持SQL标准，现有系统的移植非常困难，学习曲线就会变长。　　通用性/可迁移性　　通用性描述是否可在不同数据库系统和架构上实现指定的评测基准。测试基准不应该规定实现的细节，而只需要定义测试规范。DBMS只要遵循规范得到正确的结果，就是合理的测试，无论其基于Map/Reduce、Spark还是其他的技术，也不管其底层存储是用HDFS、HBASE还是其他方式。
第1页：第2页：
大学生分期购物销量榜
IT168企业级