SQL SERVER 2000压力测试
SQL SERVER 2000压力测试
-- 大记录量,大信息容量
随着Microsoft的新一代关系数据库系统SQL SERVER 2000(以下简称SQL2K)的发布,业界纷纷瞄准了它的性能,尤其是针对于Oracle 8的性能比较。在一系列的测试中,SQL2K的的确确没有辜负微软对它的期望,获得了相当不错的成绩,终于肩负起对抗Oracle,抢占高端数据库市场的使命。
在关系数据库的应用当中,当随着数量级或者容量级的数据急剧膨胀,很多数据库的性能就飞速下降。因此在要求严格的应用中,通常Oracle数据库是作为用户的首选,然而其高昂的价格却让人望而却步。随着SQL2K的到来,我们期待着Microsoft的SQL2K在大记录量和大容量的情况下能有优秀的表现。在此,我们针对SQL2K在这两方面表现的性能作了测试。
测试计划:
整个测试过程分为两个部分,第一部分是数据库大容量状态下的执行情况,第二部分是数据库在大记录量下的执行情况。为了方便测试,我们编写了一个程序进行各种数据库操作,并进行效率纪录。
在两个部分的测试中,我们分别在空数据库环境下进行各种数据库基本操作,并记录各个操作所需要的时间,然后再插入了大容量/大记录量的数据后,再作同样的操作并纪录操作所需时间。最后对前后的时间进行比较。当然,由于网络传输等问题,可能导致一些误差,但是这对我们的测试不会有太大的影响。
测试准备:
★ 测试环境:
OS:Windows 2000 Server
Database:Microsoft SQL Server 2000
Database Server:ADV2000
★ 创建数据库:
使用“企业管理器”在数据库服务器上创建数据库test,并且设置其大小为10GB,以避免在默认容量大小下,随着数据库容量增加而导致服务器动态分配磁盘空间的时候引起开销。
随后再在test数据库上创建一个Tab表,包含以下几个字段:
字段名 | 数据类型 | 字段情况 | 可否为空 |
id | Int,4 | 主键,自加 | 不可 |
name | Char, 10 | 不可 | |
age | Int, 4 | 不可 | |
Photo | Image, 16 | 可 |
(表一)
★ 并且我们使用Delphi 6编写了一个测试程序,采用ADO接口,连接数据库服务器ADV2000。测试程序主要完成一下的功能:
1、 插入2000条数据(insert)
2、 选择1000条数据(select)
3、 更新1000条数据(update)
4、 删除1000条数据(delete)
5、 插入100,000条带图片数据(用于大容量测试)/插入1,000,000条不带图片测试(用于大记录量测试)
测试过程
整个测试过程分为大容量数据测试和大记录量数据测试:
大容量数据测试:
在大容量的数据测试中,我们通过插入图片来使数据库的容量膨胀,所以在以下的所有数据库操作中,例如插入数据,都是指的插入带图片的数据。测试中选择了一张41,958字节的图片,并且大容量测试是在插入100,000条记录以后的测试,因此我们可以大致估计当时的数据表的容量为 (41958 * 100000) / (1024 * 1024) = 4001.43MB。
首先通过测试程序按顺序进行如下测试,在空表中“插入2000条纪录->选择1000条记录->更新1000条记录->删除1000条记录”,并记录下各操作所需要的时间。测试结果如下图和表中:
(图一)
Insert 2000条纪录 | Select 1000条纪录 | Update 1000条纪录 | Delete 1000条纪录 |
132.781 S | 41.94 S | 0.841 S | 1.552S |
(表二)
上面的测试是在空数据表中进行数据库各种基本操作的测试,并且记录了所需要的时间。然后我们插入100,000条带有图片的纪录,使数据表的数据量膨胀到4001.43MB,接下来的工作就是测试大容量环境下的各种数据库操作情况。
(图二)
同样按照以上的的步骤进行测试:“插入2000条纪录->选择1000条记录->更新1000条记录->删除1000条记录”,并记录下各操作的时间,如下:
(图三)
Insert 2000条纪录 | Select 1000条纪录 | Update 1000条纪录 | Delete 1000条纪录 |
139.05 S | 42.36 S | 0.971 S | 2.264 S |
(表三)
通过对比,我们发现:
在大记录量(百万条记录得数据量下),对SQL2K的影响并不算大,其性能影响也比较小,从下图以看出来:
(图四)
从这个柱状图可以反映出在需要大量时间的SQL操作中,SQL2K在大容量数据环境下的性能基本能保持,不会有太多的性能下降。但是从后面两个只需要极短时间执行的SQL操作从图中无法反映出什么情况。
那让我们通过计算再来看一下了,下面是在大容量数据环境下,同样操作增加的时间与初始数据库环境下所需时间的百分比:
Insert 2000条纪录 | Select 1000条纪录 | Update 1000条纪录 | Delete 1000条纪录 |
4.72% | 1.001% | 15.46% | 45.88% |
(表四)
从表中中可以看出,Update和Delete操作的时候,好像在大容量环境下的性能损失严重。但是考虑到,因为存取的数据库服务器与客户端位于不同的机器上,虽然通过100M的内部网连接,但是由于网络的问题,导致了存取中网络的延时。当操作所需要的时间比较大的时候,这一点延时对时间比例影响不大,而一旦操作所需要的时间比较短的时候,这个延时就显得尤为突出了。
对于Delete操作中的45.55%的性能损失,还有一个原因是,当删除纪录的时候,数据库会重建索引。当数据量太大的原因下,导致了重建索引耗费了较多的时间。
大记录量数据测试:
在大记录量环境下的测试,为了让大容量测试不影响这次测试,首先我们彻底删除掉大容量测试中使用的表Tab,并且重新创建一个完全一样的新表Tab用于此次测试。
这个测试中的步骤和上一个测试基本一样,同样测试了空表状况下的各个基本数据库操作所需要的时间,但是,这个测试中我们没有插入图片,photo字段没有插入任何东西,保持为空:“插入2000条纪录->选择1000条记录->更新1000条记录->删除1000条记录”,如下所示:
(图五)
Insert 2000条纪录 | Select 1000条纪录 | Update 1000条纪录 | Delete 1000条纪录 |
16.274 S | 0.07 S | 0.04 S | 0.04 S |
(表五)
在大容量数据环境下,我们插入的是100,000条带有图片的数据,从而导致了数据量达到了4001MB,而在这次的大记录量环境下的测试,100,000条数据量可能已经不能满足我们的需要,我们希望能在更高数据量环境下进行测试,以便于增大添入大数量级数据前后操作效率的差异,因此选择了插入1,000,000条数据。
(图六)
完成我们的大数量级的数据插入以后,进行下一步的测试纪录:“插入2000条纪录->选择1000条记录->更新1000条记录->删除1000条记录”,记录下每一个操作所需要的时间,如下所示:
(图七)