登录 / 注册
IT168技术开发频道
IT168首页 > 技术开发 > 技术开发评测 > 正文

赢在云端 微软SQL Azure云数据库首测

2012-08-31 00:05    it168网站 原创  作者: 谢昀 编辑: 王玉圆

  【IT168 评测】SQL Server 2012,IT168评测室又对微软SQL Azure数据库进行了产品体验。云数据库作为云计算时代的产物,将数据库作为一种服务以云的形式提供给企业。本文为SQL Azure的体验报告。

  一、SQL Azure数据库简介

  SQL Azure是微软基于Microsoft SQL Server Denali,也就是SQL Server 2012构建的云端关系型数据库服务.SQL Azure建构在Windows Azure云操作系统之上,运行云计算 (Cloud Computing)的关系数据库服务 (Database as a Service),是一种云存储(Cloud Storage)的实现,提供网络型的应用程序数据存储的服务。

  SQL整个服务架构分为三层结构,服务层,平台层,以及基础架构层。SQL Azure的构建于SQL Server 2012,以Windows Azure为基座平台,配合Windows Azure的特性,因此,SQL Azure也是可以被看作为一种分散在许多实体基础架构(Physical Infrastucture)与其内部许多虚拟服务器(Virtual Servers)的一种云存储以及云数据库应用服务,外部应用程序或服务可以不用在乎数据库实际存储在哪里,就可以利用SQL Azure提供的数据服务接口接受外部连接,并且在内部使用连接绕送(connection routing)的方式,让连接可以对应到正确的服务器,而且数据库是在云中由多个服务器来提供服务,每一次连接所提供服务的服务器可能会不同,因此也可以保证云存储的高度可用性(High availability)。

  微软官方所提供的SQL Azure的架构图如下:

赢在云端 微软SQL Azure云数据库首测

  笔者就根据这次测试的步骤,结合SQL Azure的三个层次进行简单介绍。

  1. 服务提供层 (Service Layer)

  SQL Azure 应用服务地址为http://www.windowsAzure.com/zh-cn/,其中用户可以选择购买直接购买服务,或者选择90天的免费试用,免费试用的限制如下图所示:

赢在云端 微软SQL Azure云数据库首测

  目前,SQL Azure 暂不支持对中国大陆开放,需通过中国香港和中国台湾进行注册,且需绑定windows live ID、信用卡以及对应地区的手机号,并通过手机号进行验证。

  经过注册后,登陆完成后打开门户网站如下图所示,在该门户页面中可以创建web网站、数据库服务器以及数据库和存储。

赢在云端 微软SQL Azure云数据库首测

  点击数据库进行创建,通过以下界面进行设置相应的参数。

赢在云端 微软SQL Azure云数据库首测

  其中web 版数据库提供数据库大小为1~5G,BUSINESS数据库最大可支持150G的数据库创建,由于笔者本次采用试用账号,上限为35G,因此本次创建采用30G的数据库为测试数据库,在创建数据库的同时,同时创建了数据库服务器。

赢在云端 微软SQL Azure云数据库首测

  创建完成后,SQL Azure服务提供层自动提供SQL Azure对外服务接口。包括在线对数据库进行设计,以及创建对外数据服务接口。

赢在云端 微软SQL Azure云数据库首测

${PageNumber}

  对外数据服务接口如下图所示:

赢在云端 微软SQL Azure云数据库首测

  SQL Azure 创建完成后,可以通过功能管理页面查看容量等信息,但是功能页面能实现的功能太少,还需要进一步丰富。

赢在云端 微软SQL Azure云数据库首测

  用户需要对接入的IP进行防火墙设置,将访问该数据库的IP加入允许列表中。否则系统将禁止访问,增加了数据库的安全性。

赢在云端 微软SQL Azure云数据库首测

  当用户连接接入 SQL Azure 时,SQL Azure Load Balancer 会分派连接到不同的 SQL Azure Gateway 中。SQL Azure Gateway系负责处理 TDS 连接,管理连接层安全性 (connection-level security) 以及解析指令是否有内含潜在威胁的指令,再交由连接管理员 (Connection Manager) 将连接分派到位于平台提供层内不同的 SQL Azure 数据库服务器中进行处理,SQL Azure Gateway 也会管理对 SQL Azure 的连接,以避免可能会封锁住服务器的连接 (例如过长的查询或过长的数据库交易等)。

  2. 平台层 (Platform Layer)

  平台提供层则是以 Windows Azure Computes 的虚拟机簇 (Cluster),每台虚拟机都安装有 SQL Server 2008 以及管理一定数量的数据库。根据微软官方文档说嘛,通常一份数据库会分散到三至五台的 SQL Server VM 中,而每台 SQL Server VM 也安装了 SQL Azure Fabric 中控软件,并通过 SQL Azure Fabric 与 SQL Azure Gateway 的管控下,所有对单一数据库的连接都不一定会持续连入同一台 SQL Server VM 中。

  SQL Server VM 内也安装了 SQL Azure Management Service,它会负责对每个数据库间的数据复写工作,以保障 SQL Azure 的基本高可用性要求。每台 SQL Server VM 内的 SQL Azure Fabric 和 Management Service 都会彼此交换健康与监控信息等,以保持整体服务的健康与可监控性。

  通过这种架构设计,将服务基于SQL Server VM 架构之上,使得平台层服务器的故障不会影响到应用层的使用,提高了服务的可靠性。

  3. 基础建设层 (Infrastructure Layer)

  基础建设层由 Windows Azure Computes 以及其高度可扩充性的运算与网络基础架构来组成,以支持 SQL Azure 所需的高可用性以及高扩充性等云特色。

  SQL Azure数据库以SQL SERVER 2012 为基础,减少了用户对服务器资源以及数据库资源的投入,降低了系统的安装、维护以及运营的成本,同时也提高了数据库系统的健壮性,有效的降低了因服务器或者应用故障所导致的服务中断。

${PageNumber}

  二、SQL Azure数据恢复TPCH测试

  云数据库SQL Azure基于SQL SERVER 2012 ,因此应该也适合采用TPC-H进行测试。一个数据库之所以能成为云数据库,主要特点体现为可扩展、按需分配、对外提供数据存储与计算服务,满足这个特征就可以称为云数据库。

  针对云数据库与本地数据库的不同特性,本次云数据库主要测试点为数据加载、查询性能,以及数据压缩。

  1.数据加载

  SQL Server 2012的大容量文本数据文件导入主要有2种方式,第一种在操作系统下,用bcp命令导入,这个命令的优点是支持各种文件格式,功能强大,缺点是比较复杂。第二种是在SQL Server交互界面中用Bulk insert语句导入,这个语句的语法简单,但支持的文件种类不如bcp多。两种方式都可以有效地减少日志的产生,达到高速导入的目的。

  SQL Azure 云数据库虽然基于 SQL SERVER 2012 进行构建,但是SQL Azure 并不支持BUCK INSERT方式进行数据导入。

  SQL Azure 支持的数据导入方式有以下几种:

  a.采用BCP模式进行;

  b.采用SQLAzureMW;

  c.脚本生成向导(Generate Script Wizard,GSW)。

  BCP命令是SQL Server提供的一个快捷的数据导入导出工具。使用它不需要启动任何图形管理工具就能以高效的方式导入导出数据。SQLAzureMW和GSW的方式均以图形方式启动,能通过对原有数据的结构进行分析,得到数据库schema和数据脚本,然后进行迁移。本次测试采用BCP方式进行纯数据导入,用来对SQL Azure云数据库进行测试数据恢复的性能,不采用SQLAzureMW和GSW的方式进行测试。

  bcp命令的命令行格式是:

  bcp /?

  用法: bcp {dbtable | query} {in | out | queryout | format} 数据文件

  [-m 最大错误数] [-f 格式化文件] [-e 错误文件]

  [-F 首行] [-L 末行] [-b 批大小]

  [-n 本机类型] [-c 字符类型] [-w 宽字符类型]

  [-N 将非文本保持为本机类型] [-V 文件格式版本] [-q 带引号的标识符]

  [-C 代码页说明符] [-t 字段终止符] [-r 行终止符]

  [-i 输入文件] [-o 输出文件] [-a 数据包大小]

  [-S 服务器名称] [-U 用户名] [-P 密码]

  [-T 可信连接] [-v 版本] [-R 允许使用区域设置]

  [-k 保留 Null 值] [-E 保留标识值]

  [-h"加载提示"] [-x 生成 xml 格式化文件]

  [-d 数据库名称]

  对于我们的数据,如果像bulk insert命令一样只限制分隔符,bcp认为信息不够,需要人工确认每一列的格式,我们如果采用默认值是无法导入成功的。在导入TPC-H的测试数据时,建议采用-c参数,指定文件类型是文本格式。

  需要注意的是,如果采用TPC-H中的建表脚本,则需要修改脚本,增加对表的聚簇索引。SQL Azure 允许建表时无簇约束,但是在表插入数据之前,必须建立聚簇索引。

CREATE CLUSTERED INDEX SUPPLEY_INDEX ON SUPPLIER (S_SUPPKEY)

  复制supplier表数据,数据量10万条,文件大小13M。

C:\TPCH>bcp AZURE_DB.dbo.supplier in supplier.tbl -S TCP:y4dd8yyciw.database.windows.net-U AZUREUSER -P Xie1983yun -t"|" -r"|\n" -c  -a 10240 -b 20000

  上述命令执行结果如下图:

SQL Azure数据恢复TPCH测试

  复制Part文件数据,数据量200万条,文件大小113M。

C:\TPCH>bcp AZURE_DB.dbo.part in part.tbl -S TCP:y4dd8yyciw.database.windows.net -U AZUREUSER -P Xie1983yun -t"|" -r"|\n" -c  -a 10240 -b 1000000

  执行结果如下:

SQL Azure数据恢复TPCH测试

  其他表执行过程在这不一一列举,在执行过程中,均采用了–a 10240 –b 1000000 参数进行执行,8张表导入执行时间见下表:

 Table
文件大小(
数据量(条)
执行时间
每秒插入行数(均值)
Supplier
13.6 M
100000
56.238秒
1778.16
Part
234 M
2000000
1022.04秒
1956.87
Customer
236 M
1500000
848.709秒
1767.39
Lineitem
7.29 G
59986052
35093.39秒
1709.30
Nation
3    K
25
109ms
 
Region
1    K
5
110ms
 
Orders
1.64 G
15000000
8584.426秒
1747.35
Partsupp
1.12 G
8000000
4607.037秒
1736.47

  从上表中可以看出,SQL Azure处理数据大部分均稳定在1700条/秒左右。对表lineitem进行处理的过程中,处理速度稍微下降,共花费9个多小时。在本次测试中,通过BCP方式在SQL Azure云数据库中恢复数据是一个较为漫长的过程。笔者进一步测试发现,虽然SQL Azure支持多个客户端同时进行恢复操作,但是多客户端恢复数据同样会对恢复速度造成影响。

 

 

${PageNumber}

  在本地测试中,参数-a(增加提交的包的字节大小),-b(限制每批提交的数据行数)对本机数据库测试结果影响是显著的,参见行式数据库评测:SQL Server2008 R2版,在本次针对SQL Azure的测试中,我们先后采用了4K、10K、16k的网络包大小,1000行、20000行、100000行对supplier表进行测试,对比数据请见下表。

表名

参数(-a/-b

耗时(MS

每秒插入行数(均值)

Supplier

10K/20000

56582

1767.35

Supplier

16K/20000

56816

1760.07

Supplier

16K/100000

56129

1781.61

Supplier

4K/1000

56036

1784.57

  由于SQL Azure对接入客户端强制采用SSL加密连接,当参数-a指定的数据包大于约17K时候,BCP会报如下网络错误。

SQL Azure数据恢复TPCH测试

  为了更好的判断云数据库性能影响因素,笔者在原环境中进行了二次测试,测试结果见下表:

表名

参数(-a/-b

耗时(MS

每秒插入行数(均值)

Customer

4k/1000000

597250

2511.51

Customer

16K/1000000

591852

2534.42

Customer

4K/100000

590292

2541.2

Supplier

16K/1000000

34757

2877.12

Supplier

4K/1000000

34897

2865.58

  采用低端服务器环境,对supplier表测试结果见下图:

SQL Azure数据恢复TPCH测试

  同时,我们测试从云数据库SQL Azure通过BCP导出数据:

C:\TPCH>bcp AZURE_DB.dbo.supplier out supplier1.tbl -S TCP:y4dd8yyciw.database.windows.net -U AZUREUSER -P Xie1983yun -t
"|" -r"|\n" -c -a 10240
开始复制...
已成功将
1000 行大容量复制到主文件。总共接收到: 1000
已成功将
1000 行大容量复制到主文件。总共接收到: 2000
。。。。。。。。。。。。。。。。。。。。。。。。。。
已成功将
1000 行大容量复制到主文件。总共接收到: 99000
已成功将
1000 行大容量复制到主文件。总共接收到: 100000

已复制
100000 行。
网络数据包大小
(字节): 10240
总时钟时间
(毫秒) : 60669 平均值: (每秒 1648.29 行。)

  从上述测试中我们可以发现,在某一时间段内,云端对SQL Azure云数据库分配的基础架构windows Azure资源是恒定的,因此在这段时间内,数据处理速度相对来说比较的稳定。在第二天的测试中,数据处理速度有明显提升,由于SQL Azure利用的是Windows Azure平台,且SQL Azure并未提供SQL SERVER的运行监控页面,因此只能猜测由于云端在第二天中动态分配给该数据库的资源较多。同时,在测试中发现,数据处理的速度也受到客户端服务器的影响,在上面测试中我们发现当服务器性能较低时,数据处理速度性能有较大的降低。当导出数据时候,由于无法通过-b参数来设定提交次数,因此对数据处理的性能影响较大。

  在tpc-h所提供的表创建语句中,并没有设定表的主键等参数,因此用脚本创建完数据库表后,没有建立索引。但是由于SQL Azure规定必须对每张表设定唯一的聚集索引才能进行数据插入,因此在上文中,我们在插入数据库表数据之前,已经建立了索引,该索引中键值的逻辑顺序决定了表中相应行的物理顺序,因此在数据插入之前,数据的在表中间的顺序已经确定,因此这种模式会影响数据插入的速度。这种表的索引也是影响表数据插入的原因之一。

  综上所述,通过BCP恢复云数据库SQL Azure数据性能受到以下因素的影响:

  1. 服务器性能

  2. 网络环境

  3. -a参数(影响较小)

  4. -b参数

  5. SQL Azure 云数据库服务性能

  6. 聚集索引

  数据完全导入后,可以在SQL Azure管理界面看到导入的行数,占用空间大小,以及各个表之间的关联,同时可以查看整个数据库所使用的表空间大小。导入10G的数据后,整个SQL Azure数据库占用了12.96G的空间。

SQL Azure数据恢复TPCH测试

SQL Azure数据恢复TPCH测试

${PageNumber}

  三、数据查询测试

  1.查询数据的产生

  本次查询查询语句仍然采用TCP-H中所提供的查询语句,语句产生过程不再叙述。利用qgen工具产生查询语句后,用位于压缩包queries 目录的qgen工具产生,需要针对SQL Server的特性作修改。

  SQL Server对SQL语句的特殊要求主要有4点:

  (1)取前若干行的语法。使用Top n写法。比如select top 1 * from t。

  (2)日期间隔的表达式。不支持date,interval 'n' year/month等SQL 92写法,要改为 DateAdd函数。比如:date '1998-12-01' - interval '73' day 要改为dateadd(day,-73, '1998-12-01')。其中,用字符串'1998-12-01'直接代表日期。

  (3)从日期提取年月日的表达式。不支持extract year from 等写法,要改为 DatePart函数或更简洁的Year函数。如:extract (year from o_orderdate)改为year(o_orderdate)。

  (4)用go命令执行SQL语句,可以在最后用1个GO命令批量执行一组分号结尾的SQL语句。这些SQL语句既可以是查询语句,也可以是DDL语句和DML语句。

  将修改完成后的22个查询语句保存为mssql_tpch.sql文件。同时在文件开始处加入:

usetpch
go
setstaticstics
time on
go

  以限制查询的数据库,并显示SQL解析和运行时间。在文件末加上go命令。

  查询语句的篇幅过长,不在正文列出。

  四:数据库查询性能测试

  在上文中,我们提出过SQL Azure的每张表都有聚集索引,聚集索引的存在会增强查询的速度。我们同时通过增加表的主键和外键关联进行了测试,相关测试数据如下:

编号

聚集索引

增加主键以及外键索引

第一次测试耗时

第二次测试耗时

第一次测试耗时

第二次测试耗时

1

00329

00323

00322

00317

2

00001

00001

00003

00001

3

00205

00115

00052

00051

4

00010

00013

00010

00010

5

00013

00022

00019

00013

6

00026

00031

00026

00025

7

00037

00043

00057

00040

8

00041

00042

00036

00037

9

00314

00307

00148

00133

10

00107

00115

00029

00030

11

00009

00009

00009

00009

12

00037

00035

00033

00034

13

00109

00107

00034

00033

14

00030

00028

00029

00028

15

00028

00027

00027

00028

16

00016

00015

00009

00008

17

00056

00054

00028

00027

18

00046

00052

00046

00047

19

00031

00035

00030

00032

20

00035

00032

00030

00032

21

00142

00134

00113

00112

22

00012

00012

00012

00012

  从上表数据中可知,如果使用聚集主键约束,SQL Azure在大约18分钟运行完22个查询,大部分查询的运行时间均在1分钟左右,第1个查询速度最慢,用时3分32秒。而加上主外键索引后,在表不压缩的情况下,整体性能能提高4~5分钟,大部分查询的运行时间均在1分钟以内,第9、10、13、21的速度提升比率较为明显,可见,主外键索引对执行结果的影响仍然具有较大影响。

  同时,我们将在SQL Azure与SQL SERVER 2012中同时采用聚集主键不压缩的情况下进行对比,对比数据如下:

编号

聚集主键不压缩(SQL 2012

聚集主键不压缩(SQL AZURE

01

0:00:55

0:03:23

02

0:00:07

0:00:01

03

0:01:05

0:01:15

04

0:01:03

0:00:13

05

0:01:03

0:00:22

06

0:00:53

0:00:31

07

0:01:03

0:00:43

08

0:01:03

0:00:42

09

0:01:17

0:03:07

10

0:01:04

0:01:15

11

0:00:07

0:00:09

12

0:01:03

0:00:35

13

0:00:17

0:01:07

14

0:00:53

0:00:28

15

0:00:53

0:00:27

16

0:00:09

0:00:15

17

0:00:53

0:00:54

18

0:00:56

0:00:52

19

0:00:53

0:00:35

20

0:01:00

0:00:32

21

0:07:32

0:01:34

22

0:00:11

0:00:12

合计

0:24:31

0:19:12

  注:SQL SERVER 测试数据来源于数据库性能评测MSSQL 2012。

${PageNumber}

  经过对比可以发现,SQL Azure的整体性能完全优于本地SQL SERVER的执行速度,且从语句的对比可以发现,大部分语句的执行时间效率较高,部分查询语句能提高50%,但也有部分查询语句执行反而增加了时间,笔者初步怀疑是SQL Azure的SQL 引擎与SQL SERVER 2012发布版本的引擎不一致所造成的,还需进一步深化研究。

  SQL Azure 提供了查询的统计分析页面,可以统计相应语句执行的次数,占用时间,占用CPU时间,以及执行的最长以及最短时间等等指标,具体的以下截图:

数据库查询性能测试

数据库查询性能测试

数据库查询性能测试

  SQL Azure提供对语句的执行分析器,见下图,能对语句进行分析,解析其中的步骤,解析器能直观的分析语句的相关开销。

数据库查询性能测试

数据库查询性能测试

数据库查询性能测试

  五、数据查询测试

  由于SQL Azure不支持数据压缩,因此,本压缩测试没有进行。

  六、总结

  经过这次测试,我们对SQL Azure云数据库已经有了初步的印象,不需要经过安装、测试、版本升级等一系列的工作,仅仅需要通过windows live ID进行申请,就能获得一个功能很强大的数据库。云数据库减少了IT企业在数据库方面的投入,减少了企业的开销,使得企业能将资源更好利用在数据库的内在表结构设计上。

  从测试数据可以看出,SQL Azure数据恢复性能开销较大,且受到影响的因素较多,不利于数据库的备份以及恢复。但是SQL Azure的稳定性又是用户考虑的另一个方面,通过windows Azure平台架构的设计,增强了SQL Azure的稳定性,资源的动态分配可以在需要的时候进行添加,对企业而言节省硬件资源开销,降低了企业成本。

  SQL Azure采用了最新的SQL引擎,因此用户无需对自身的数据库进行版本维护,企业用户无需进行数据库备份以及迁移,就能实现能将数据库平稳的进行版本过度,这也是云数据库吸引企业用户的另一个特点。

  云数据库基于自身的特点,也具有自身的缺点:

  1. 网络依赖性强:整个云数据库对网络的依赖性较大,网络速度的性能将影响应用服务的质量,对用户体验而言是个不利因素。

  2. 数据库提供功能有所弱化:由于SQL Azure将数据库的运行与维护有云数据库端进行,因此就数据库功能应用而言,SQL Azure能提供的功能较少,只提供一些基础的查询以及显示功能,功能性较SQL 2012较为减弱。

  3. SQL Azure 不支持T-SQL部分语句、不支持数据压缩等。

  4. 数据备份与数据恢复的开销较大,由于数据库的备份与开销均通过网络进行,备份与数据恢复速度明显低于本地,这样将对海量数据库备份产生较大的影响。而由于SQL Azure是根据流出流量进行计费,频繁的备份数据库必然导致企业的支出增加,增加企业成本。

  SQL Azure是构建在SQL Server 2012之上,底层通过windows Azure运行基础服务架构服务,应用层运行云计算 (Cloud Computing)的关系数据库服务,是一种云存储(Cloud Storage)的实现,它可以随时随地为我们提供关系型数据服务。本文在TCP-H测试的基础之上分析了SQL Azure的功能以及优缺点,通过这些介绍给现在或将来使用SQL Azure的用户一个理论性的认识。

  • IT168企业级IT168企业级
  • IT168文库IT168文库

扫一扫关注

行车视线文章推荐

首页 评论 返回顶部