【IT168 专稿】2012年5月,达梦数据库发布了最新一代的数据库产品DM7,以及海量数据处理及云数据库技术。DM7.0作为新一代支持“云计算”的大型数据库管理系统,主要的特性是具备大规模并行计算(MPP)技术、海量数据分析技术、大规模并发处理技术、行列混合储存、高安全性。
一、数据库安装
我们对于一个数据库的了解往往从数据库的安装开始,DM最新版本7.0的安装包大小为356M,加载上安装光盘后,安装目录下具有4个安装文件夹,如下图所示:
双击setup 点击运行后,我们开始达梦数据库的安装:
首先安装过程显示了达梦数据库的版本信息,从上图中我们可以看到本次安装达梦数据库的版本为V7.1,点击下一步进行正式安装。
与其他的数据不同的是,DM数据库试用需要找厂商进行许可的申请,本次测试申请的许可见上图,试用版对授权用户和并发连接数做了很大的限制。
点击下一步,我们可以选择本次安装所需要安装的内容,有服务器安装和客户端安装等几种选择,在安装中,我们选择典型安装:
在接下来的安装步骤中,选择完安装路径后,中间过程没有需要修改的地方,截图省略,本次安装过程大致执行时间为5分钟,在安装目录下生成了一个352M的文件系统。
我们对本次安装过程进行分析,先打开安装文件夹中的install文件夹,从名字上来看,install文件夹中的文件应该是控制达梦数据库安装过程的文件,文件夹目录结构如下图,本文挑选其中几个文件对本次安装过程进行分析。
Lib 文件夹中存放了安装过程中所需要用到的java lib包,从jar包的名称来看,大部分以ant开头。使用过apache-ant工具的进行过开发的开发人员就能发现,建议一个ant 工程中所需要包含的jar包基本包含在lib文件夹内,因此我们猜想DM的安装过程是基于java的ant工具进行执行数据库的部署。
在lib文件夹后为build.xml和properties两个文件,这两个文件为ant工程所必须的文件。用IE或者编辑器打开build.xml文件,build文件中为如下代码:
- <!--
=================================================================
2007-7-5 下午10:49:56
project Install
description
DM6.0 Install
by chenqi
=================================================================
-->
- <project name="install" default="install" basedir="">
<taskdef resource="net/sf/antcontrib/antlib.xml" />
<description>DM Install</description>
<property file="${java.io.tmpdir}/dm_build.properties" />
<import file="ent-build.xml" />
<target name="install" />
- <!--
<if>
<equals arg1="${installStatue}" arg2="cs" />
<then>
<property name="src.dir" value="d:/setup"/>
</then>
<else>
<property name="src.dir" value=".."/>
</else>
</if>
-->
</project>
在该文件配置中引用了外部文件ent-build.xml。
打开ent-build.xml文件,截取其中服务器部署的源码为例:
- <copy todir="${des.dir}/bin/" overwrite="true" failonerror="false">
<fileset dir="${src.dir}/bin/" />
</copy>
- <copy todir="${des.dir}/bin2/" overwrite="true" failonerror="false">
<fileset dir="${src.dir}/bin2/" />
</copy>
- <copy todir="${des.dir}/tool/assistant" overwrite="true" failonerror="false">
<fileset dir="${src.dir}/tool/assistant" />
</copy>
- <copy todir="${des.dir}/include/" overwrite="true" failonerror="false">
<fileset dir="${src.dir}/include/" />
</copy>
- <copy todir="${des.dir}/samples/" overwrite="true" failonerror="false">
<fileset dir="${src.dir}/samples/" />
</copy>
</target>
从以上几个文件可以看出,DM的安装基于ant工具进行,且安装过程为将安装文件包下的相应文件拷贝到用户指定的安装位置。通过对比安装目录下的bin文件夹和安装位置的文件夹可以看出,文件夹目录结构大题一致。
Creatlink.bat 为批处理文件,通过编辑器打开内容如下:
G@md "%DM_SHORTCUT%\客户端\"
M@md "%DM_SHORTCUT%\用户手册\"
X@Shortcut.exe /f:"%DM_SHORTCUT%\服务器\数据库配置工具.lnk" /a:c /t:"%DM_HOME%\bin\dbca.exe" /w:"%DM_HOME%\bin"
G@Shortcut.exe /f:"%DM_SHORTCUT%\服务器\启动web服务器.lnk" /a:c /t:"%DM_HOME%\bin\startWebServer.bat" /w:"%DM_HOME%\bin"
G@Shortcut.exe /f:"%DM_SHORTCUT%\服务器\停止web服务器.lnk" /a:c /t:"%DM_HOME%\bin\stopWebServer.bat" /w:"%DM_HOME%\bin"
G@Shortcut.exe /f:"%DM_SHORTCUT%\客户端\DM控制台工具.lnk" /a:c /t:"%DM_HOME%\tool\console.exe" /w:"%DM_HOME%\tool"
G@Shortcut.exe /f:"%DM_SHORTCUT%\客户端\DM审计分析工具.lnk" /a:c /t:"%DM_HOME%\tool\analyzer.exe" /w:"%DM_HOME%\tool"
G@Shortcut.exe /f:"%DM_SHORTCUT%\客户端\DM管理工具.lnk" /a:c /t:"%DM_HOME%\tool\manager.exe" /w:"%DM_HOME%\tool"
G@Shortcut.exe /f:"%DM_SHORTCUT%\客户端\DM性能监视工具.lnk" /a:c /t:"%DM_HOME%\tool\monitor.exe" /w:"%DM_HOME%\tool"
G@Shortcut.exe /f:"%DM_SHORTCUT%\客户端\DM数据迁移工具.lnk" /a:c /t:"%DM_HOME%\tool\dts.exe" /w:"%DM_HOME%\tool"
Y@Shortcut.exe /f:"%DM_SHORTCUT%\客户端\INI文件配置工具.lnk" /a:c /t:"%DM_HOME%\bin\iniedit.exe" /w:"%DM_HOME%\bin"
M@Shortcut.exe /f:"%DM_SHORTCUT%\用户手册\DM_DBA.pdf.lnk" /a:c /t:"%DM_HOME%\doc\DM_DBA.pdf" /w:"%DM_HOME%\doc"
M@Shortcut.exe /f:"%DM_SHORTCUT%\用户手册\DM_Program.pdf.lnk" /a:c /t:"%DM_HOME%\doc\DM_Program.pdf" /w:"%DM_HOME%\doc"
M@Shortcut.exe /f:"%DM_SHORTCUT%\用户手册\DM_SQL.pdf.lnk" /a:c /t:"%DM_HOME%\doc\DM_SQL.pdf" /w:"%DM_HOME%\doc"
Y@Shortcut.exe /f:"%DM_SHORTCUT%\DM服务查看器.lnk" /a:c /t:"%DM_HOME%\bin\dmservice.exe" /w:"%DM_HOME%\bin"
Y@md "%DM_SHORTCUT%\"
Y@Shortcut.exe /f:"%DM_SHORTCUT%\卸载.lnk" /a:c /t:"%DM_HOME%\uninstall.exe" /w:"%DM_HOME%"
该文件中主要在于对达梦数据库中服务进行注册,在开始菜单栏创建相应的内容。从数据库安装过程来看,其中并没有什么难点以及特别要注意的地方,安装过程较为简单。数据库安装完成后,我们进行数据库实例的创建和初始化配置,DM数据库的初始化可以通过GUI图形化工具或者命令行进行,在windows环境下,我们采用图形化方式进行数据库的创建、配置等操作。
达梦数据库和oracle一样,区分不同的用途,这里可选项有:联机分析处理、联机事务处理等等。我们选择一般用途,并以配置状态启动数据库。
点击下一步设置数据文件存放的目录,设置完成后下一步设置数据库的标识符,也就是数据库名、实例名以及所占用的端口。
接下来我们对数据库文件进行设置,和ORACLE一样,达梦数据库也有一个控制文件dm.ctl,与Oracle一样,该控制文件也是一个二进制文件,经过查阅相应的资料,该控制文件含有以下内容:
1.数据库名称
2.数据库服务器模式
3. OGUID 唯一标识;
4. 数据库服务器版本;
5. 数据文件版本;
6. 表空间信息,包括表空间名,表空间物理文件路径等,记录了所有数据库中使用的表空间,数组的方式保存起来;
7. 控制文件校验码, 校验码由数据库服务器在每次修改控制文件后计算生成,保证控制文件合法性,防止文件损坏及手工修改。
同时为了我们可以通过旁边的“+”,为控制文件创建一份或者多份备份文件。接下来对数据库初始化参数进行设置:
在这个页面的设置中,首先选择数据文件簇大小,有16K和32K两个选项,默认为16K,然后选择数据页大小,有4、8、16、32K四个选项,默认是8K,这两个参数有点类似ORACLE数据库中的页大小以及区块大小。
随后是:
是否设置大小写敏感,推荐为否;
使用UNICODE字符集,推荐为否;
这里设置完成后,下一步为口令管理,为用户账号设置相应的口令。
口令设置完成后,点击完成,开始数据库设置:
大概半分钟,数据库设置完成,经过测试,能顺利的连上创建完成的数据库,至此,数据库创建完成。
纵观整个数据库安装过程,其中的步骤并没有什么需要特别注意的地方,相信一般初学者都能很容易的在windows环境下完成数据库的安装并启动实例。
${PageNumber}二、 达梦数据库行存储TPCH 测试
2.1 数据导入准备工作
数据库创建完成后,会自动创建5 个表空间:SYSTEM 表空间、ROLL 表空间、MAIN 表空间、TEMP 表空间和HMAIN 表空间。新建用户时,如果不指定表空间,达梦数据库会将MAIN表空间作为用户的默认表空间。
在达梦数据库测试中,我们新建用户TPCH,以及建立属于该用户的表空间TPCH,本次测试数据为10G TPCH数据,数据库建表、查询语句均和SQL AZURE保持一致,使得相应的数据有一定的对比性。首先在C盘创建30 的表空间以及相应的用户,创建语句如下。
创建表空间以及相应用户:
执行成功, 耗时246毫秒. 执行号:555
影响了0条记录
create user "TPCH" identified by tpchit168 password_policy 2
encrypt by tpchit168 limit failed_login_attemps 3, password_lock_time 1, password_grace_time 10 default tablespace "tpch";
执行成功, 耗时72毫秒. 执行号:676
创建表,采用TPCH的提供的创建表的SQL语句,在达梦数据库中可以直接执行。本次创建中,不创建主键,用来测试数据库导入性能,以语句一为例,其余的不一一列举。
N_NAME CHAR(25) NOT NULL,
N_REGIONKEY INTEGER NOT NULL,
N_COMMENT VARCHAR(152));
执行成功, 耗时9毫秒. 执行号:1,187
8条语句执行成功后,下面进行数据库数据导入测试。
2.2 数据导入测试
SQL SERVER 提供了BCP的方式用以数据导入,和BCP方法类似,达梦数据库提供了dmfldr工具用以导入文本数据,由于对dmfldr工具不是很熟悉,我们使用help命令查看相应的解释:
格式: DMFLDR KEYWORD=value
例程: DMFLDR SYSDBA/SYSDBA CONTROL='c:\fldr.ctl'
USERID 必须是命令行中的第一个参数
CONTROL 必须是命令行中的第二个参数
字符串类型参数必须以引号封闭
关键字 说明(默认)
--------------------------------------------------------------------------------
USERID 用户名/口令 格式:USER/PWD@SERVER:PORT#SSL_PATH@SSL_PWD
CONTROL 控制文件,字符串类型
LOG 日志文件,字符串类型 (dfldr.log)
BADFILE 错误数据记录文件,字符串类型 (dfldr.bad)
SKIP 初始忽略逻辑行数 (0)
LOAD 需要装载的行数 (ALL)
ROWS 提交频次 (50000)
READSIZE 读取缓冲区大小 (16M)
DIRECT 是否使用快速方式装载 (TRUE)
SET_IDENTITY 是否插入自增列 (FALSE)
SORTED 数据是否已按照聚集索引排序 (FALSE)
INDEX_OPTION 索引选项 (1)
1 不刷新二级索引,数据按照索引先排序,装载完后再
将排序的数据插入索引
2 不刷新二级索引,数据装载完成后重建所有二级索引
GEN_LOG 服务器是否生成日志 (TRUE)
ERRORS 允许的最大数据错误数 (100)
CHARACTER_CODE 字符编码,字符串类型 (GBK)
MODE 装载方式,字符串类型 IN表示载入,OUT表示载出 (IN)
MPP_LOCAL 装载mpp模式服务器的单节点数据,不分发
LOB_DIRECTORY 大字段数据文件存放目录
HBUF_BLOCK_NUMBER 水平分区缓冲区块数 (50)
NULL_MODE 是否将NULL字符串导入为NULL值,是否将空值导出为
NULL字符串
HELP 打印帮助信息
从上面说明中可以看出,和数据加载的性能有关的参数为如下几个:
1. ROWS:数据提交频率,根据数据库手册,我们可以根据数据库服务器设置的buffer来调整提交的频率。
2. Readsize:读取缓冲区的大小,默认为16M。
3. Character_code:数据文件的字符编码格式,默认为GBK,如果导入的数据文件中全部为单字节数据,可以用此选项来提升加载速率。
4. index_option :在表为空表的情况下,设置为1 ,可以提升装载效率。
根据以上参数,本次测试的控制文件首次采用的参数如下:
(
SKIP = 0
readsize = 16
ROWS = 1000000
DIRECT = TRUE
INDEX_OPTION = 1
hbuf_block_number =50
)
在windows环境下,通过批处理文件来对导入数据进行执行,批处理文件如下:
path c:\dmdbms\bin
echo 开始时间:%date% %time% >> loadtime.log
dmfldr userid=tpch/tpchit168@localhost:5236 control='C:\TPCH\dm.ctl'
echo 结束时间:%date% %time% >> Loadtime.log
echo "OVER!"
在上文中,我们分析了DM7 配置文件中的几个参数对数据导入的影响,对此,我们通过调节控制文件中的参数,对数据导入进行了测试,以Part表和Partsupp表为例:
表名 | readsize | hbuf_block_number | 耗时(秒) |
Part | 16 | 50 | 201.633 |
Part | 128 | 200 | 43.273 |
Part | 512 | 200 | 36.589 |
Partsupp | 16 | 50 | 1264.951 |
Partsupp | 512 | 200 | 195.157 |
从上表的测试可以看出,控制文件中,导入参数的设置对数据导入有较大的影响,经过查询相关的参数说明以及进行了相应的测试后,优化后的控制文件如下:
(
SKIP = 0
readsize = 1024
ROWS = 1000000
DIRECT = TRUE
INDEX_OPTION = 1
hbuf_block_number =200
)
在TPCH提供的建表语句中,并未提供主键的设定,在导入数据的过程中,并不对数据在数据库中的位置进行排序,在导入完成后再将导入的数据插入索引,而若创建了主键聚集索引后进行数据导入,在导入的过程中,数据按照B+树进行排序,同时插入索引,这样影响了导入的性能。
通过对TPCH提供建表语句进行修改,在创建表的同时创建主键,DM7数据库在创建主键的同时,会产生两种情况,若不指定由主键来创建聚集索引,则系统默认才有ROWID作为聚集索引。本次测试指定主键作为聚集索引,相关的原因在数据查询测试中进行分析。
我们可以通过两种方式来指定主键的聚集索引:
方式一、在创建表的同时,指定主键为聚集索引:
N_NAME CHAR(25) NOT NULL,
N_REGIONKEY INTEGER NOT NULL,
N_COMMENT VARCHAR(152));
方式二、在DM.INI配置文件中,可以指定配置项使表中的主键自动转化为聚镞索引,该配置项为PK_WTIH_CLUSTER.我们可以在创建表之前,将该配置项有0改为1。默认的情况下,该参数为0,则创建的主键不会自动的升级成为聚集索引。
在本次测试中,我们采用了第二种方式进行创建主键,有主键以及无主键两种情况下进行了导入性能测试,并将达梦数据库DM7导入性能与SQL AZURE、SQL SERVER 进行了对比,导入数据见如下表:
Table | 文件大小 | Sql azure(聚集索引) | DM7(无索引) | DM7 (主键聚集索引) | SQL SERVER |
Supplier | 13.6 M | 56.238秒 | 1.166秒 | 4秒 | 1秒 |
Part | 234 M | 1022.04秒 | 38.700秒 | 52秒 | 26秒 |
Customer | 236 M | 848.709秒 | 39.130秒 | 47秒 | 20秒 |
Lineitem | 7.29 G | 35093.39秒 | 1030.804秒 | 1421秒 | 889秒 |
Nation | 3 K | 109ms | 34.556(ms) | 130(ms) | 0秒 |
Region | 1 K | 110ms | 29.790(ms) | 110(ms) | 0秒 |
Orders | 1.64 G | 8584.426秒 | 247秒 | 371秒 | 183秒 |
Partsupp | 1.12 G | 4607.037秒 | 179秒 | 288秒 | 106秒 |
从以上数据可以看出,DM7数据库在导入数据时,无索引的表导入时间耗费远远的低于有索引的表。而从DM7数据库数据导入整体而言,DM7导入速度相比较SQL SERVER较慢,而且在导入数据的过程中发现dmsvc服务进程迅速的占用了整个数据库的内存,从启动的188M内存到占用了2.2G的内存,而且在数据导入完成后,并不能立即释放该部分内存。
经过数据导入测试,我们可以看到,经过优化后的DM7数据库,数据导入数据虽然还是比SQL SERVER较慢,但是二者之间的差距并不是相差很大,相信经过进一步的优化措施,完全能赶上SQL SERVER的导入性能。
${PageNumber}2.3数据查询测试
在本次DM7数据查询测试中,我们继续使用TPCH提供的查询语句,首先在DM7数据库中表无主键和无索引的情况下,对查询情况进行测试。
select
l_returnflag,
l_linestatus,
sum(l_quantity) as sum_qty,
sum(l_extendedprice) as sum_base_price,
sum(l_extendedprice * (1 - l_discount)) as sum_disc_price,
sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge,
avg(l_quantity) as avg_qty,
avg(l_extendedprice) as avg_price,
avg(l_discount) as avg_disc,
count(*) as count_order
from
lineitem
where
l_shipdate <= dateadd(day,-73, '1998-12-01')
group by
l_returnflag,
l_linestatus
order by
l_returnflag,
l_linestatus
执行成功, 耗时2分4秒70毫秒.
select top 10
s_acctbal,
s_name,
n_name,
p_partkey,
p_mfgr,
s_address,
s_phone,
s_comment
from
part,
supplier,
partsupp,
nation,
region
where
p_partkey = ps_partkey
and s_suppkey = ps_suppkey
and p_size = 15
and p_type like '%NICKEL'
and s_nationkey = n_nationkey
and n_regionkey = r_regionkey
and r_name = 'AMERICA'
and ps_supplycost = (
select
min(ps_supplycost)
from
partsupp,
supplier,
nation,
region
where
p_partkey = ps_partkey
and s_suppkey = ps_suppkey
and s_nationkey = n_nationkey
and n_regionkey = r_regionkey
and r_name = 'AMERICA'
)
order by
s_acctbal desc,
n_name,
s_name,
p_partkey
执行超过半个小时,未成功,放弃;
select top 10
l_orderkey,
sum(l_extendedprice * (1 - l_discount)) as revenue,
o_orderdate,
o_shippriority
from
customer,
orders,
lineitem
where
c_mktsegment = 'HOUSEHOLD'
and c_custkey = o_custkey
and l_orderkey = o_orderkey
and o_orderdate < '1995-03-09'
and l_shipdate > '1995-03-09'
group by
l_orderkey,
o_orderdate,
o_shippriority
order by
revenue desc,
o_orderdate
执行成功, 耗时5分8秒231毫秒.
通过对上述语句进行的分析,我们可以看到,当表中无索引的情况下,查询语句执行的是对全表进行的扫描,严重的影响了效率。
这些表增加主键和外键关联,通过主键和外键的建立来建立相应的索引:
ALTER TABLE REGION ADD CONSTRAINT REGION_PK PRIMARY KEY (R_REGIONKEY);
-- For table NATION
ALTER TABLE NATION ADD CONSTRAINT NATION_PK PRIMARY KEY (N_NATIONKEY);
ALTER TABLE NATION ADD CONSTRAINT NATION_FK1 FOREIGN KEY (N_REGIONKEY) references REGION;
-- For table PART
ALTER TABLE PART ADD CONSTRAINT PART_PK PRIMARY KEY (P_PARTKEY);
-- For table SUPPLIER
ALTER TABLE SUPPLIER ADD CONSTRAINT SUPPLIER_PK PRIMARY KEY (S_SUPPKEY);
ALTER TABLE SUPPLIER ADD CONSTRAINT SUPPLIER_FK1 FOREIGN KEY (S_NATIONKEY) references NATION;
-- For table PARTSUPP
ALTER TABLE PARTSUPP ADD CONSTRAINT PARTSUPP_PK PRIMARY KEY (PS_PARTKEY,PS_SUPPKEY);
-- For table CUSTOMER
ALTER TABLE CUSTOMER ADD CONSTRAINT CUSTOMER_PK PRIMARY KEY (C_CUSTKEY);
ALTER TABLE CUSTOMER ADD CONSTRAINT CUSTOMER_FK1 FOREIGN KEY (C_NATIONKEY) references NATION;
-- For table LINEITEM
ALTER TABLE LINEITEM ADD CONSTRAINT LINEITEM_PK PRIMARY KEY (L_ORDERKEY,L_LINENUMBER);
-- For table ORDERS
ALTER TABLE ORDERS ADD CONSTRAINT ORDERS_PK PRIMARY KEY (O_ORDERKEY);
-- For table PARTSUPP
ALTER TABLE PARTSUPP ADD CONSTRAINT PARTSUPP_FK1 FOREIGN KEY (PS_SUPPKEY) references SUPPLIER;
ALTER TABLE PARTSUPP ADD CONSTRAINT PARTSUPP_FK2 FOREIGN KEY (PS_PARTKEY) references PART;
-- For table ORDERS
ALTER TABLE ORDERS ADD CONSTRAINT ORDERS_FK1 FOREIGN KEY (O_CUSTKEY) references CUSTOMER;
-- For table LINEITEM
ALTER TABLE LINEITEM ADD CONSTRAINT LINEITEM_FK1 FOREIGN KEY (L_ORDERKEY) references ORDERS;
ALTER TABLE LINEITEM ADD CONSTRAINT LINEITEM_FK2 FOREIGN KEY (L_PARTKEY,L_SUPPKEY) references PARTSUPP;
在上文中,我们提到在达梦数据库中, 每个表(列存储表, LIST 表除外) 都含一个聚集索引, 默认以 ROWID 建立, 创建完主键和外键关联后,由于索引并未指定通过主键建立聚集索引,因此系统默认的采用了ROWID创建了聚集索引。两种情况下测试数据见如下表所示:
两种聚集索引的执行状况如下表所示:
编号 | 聚集索引(ROWID) | 聚集索引(主键) |
1 | 130.076 | 155.651 |
2 | 15.387 | 26.988 |
3 | 309.757 | 179.547 |
4 | 74.764 | 199.650 |
5 | 80.993 | 177.052 |
6 | 68.231 | 77.970 |
7 | 114.202 | 171.755 |
8 | 135.374 | 321.579 |
9 | 253.147 | 1297.770 |
10 | 116.866 | 364.190 |
11 | 13.228 | 14.586 |
12 | 75.490 | 108.759 |
13 | 47.645 | 169.567 |
14 | 64.373 | 96.261 |
15 | 62.961 | 90.377 |
16 | 9.242 | 21.325 |
17 | 118.103 | 182.596 |
18 | 192.394 | 421.212 |
19 | 78.923 | 97.131 |
20 | 72.931 | 107.592 |
21 | 249.871 | 480.422 |
22 | 18.435 | 21.984 |
从上表中可以看到,当加载了聚集主键后,查询性能却有显著下降,但是相比较缺少索引的表查询。在上述测试中,所建的表均以B+树索引结构为管理,指定聚簇索引键后,如果查询条件中含有聚簇索引键,可以定位记录在B树上的位置,使查询性能大大提 高。然而,插入记录也需要根据聚簇索引键定位插入位置,有可能导致页面的分 裂而影响插入性能 。
${PageNumber}三、 达梦数据库列存储TPCH 测试
从以上测试可以看到,DM7普通行存储的查询性能较低,接下来我们测试DM7的列存储,列存储表是相对普通的行存储表而言的,它们主要的不同在于列存储表的每一个列都是存储在一起的,而不是以记录为单位存储,所有行的同一列存储在一起。本章通过对达梦数据库进行列存储测试,用来查看其列存储用TPCH来测试的相关性能。
首先创建表中各列对应的列存储空间,以LINEITEM为例,首先对各个列创建对应的表空间:
create tablespace tbsp_l_partkey datafile 'tbsp_l_partkey.dbf' size 2600;
create tablespace tbsp_l_suppkey datafile 'tbsp_l_suppkey.dbf' size 2600;
create tablespace tbsp_l_linenumber datafile 'tbsp_l_linenumber.dbf' size 2600;
create tablespace tbsp_l_quantity datafile 'tbsp_l_quantity.dbf' size 4900;
create tablespace tbsp_l_extendedprice datafile 'tbsp_l_extendedprice.dbf' size 4900;
create tablespace tbsp_l_discount datafile 'tbsp_l_discount.dbf' size 4900;
create tablespace tbsp_l_tax datafile 'tbsp_l_tax.dbf' size 4900;
create tablespace tbsp_l_returnflag datafile 'tbsp_l_returnflag.dbf' size 2000;
create tablespace tbsp_l_linestatus datafile 'tbsp_l_linestatus.dbf' size 2000;
create tablespace tbsp_l_shipdate datafile 'tbsp_l_shipdate.dbf' size 2000;
create tablespace tbsp_l_commitdate datafile 'tbsp_l_commitdate.dbf' size 2000;
create tablespace tbsp_l_receiptdate datafile 'tbsp_l_receiptdate.dbf' size 2000;
create tablespace tbsp_l_shipinstruct datafile 'tbsp_l_shipinstruct.dbf' size 8500;
create tablespace tbsp_l_shipmode datafile 'tbsp_l_shipmode.dbf' size 4000;
create tablespace tbsp_l_comment datafile 'tbsp_l_comment.dbf' size 18000;
在表空间创建结束后,创建相应的列存储表:
(
L_ORDERKEY int storage(on tbsp_l_orderkey, section(1)),
L_PARTKEY int storage(on tbsp_l_partkey, section(10) ,stat none),
L_SUPPKEY int storage(on tbsp_l_suppkey, section(10), stat none),
L_LINENUMBER int storage(on tbsp_l_linenumber, section(10), stat none),
L_QUANTITY float storage(on tbsp_l_quantity, section(10) ,stat none),
L_EXTENDEDPRICE float storage(on tbsp_l_extendedprice, section(10), stat none),
L_DISCOUNT float storage(on tbsp_l_discount, section(10), stat none),
L_TAX float storage(on tbsp_l_tax, section(10), stat none),
L_RETURNFLAG char(1) storage(on tbsp_l_returnflag, section(10), stat none),
L_LINESTATUS char(1) storage(on tbsp_l_linestatus, section(10), stat none),
L_SHIPDATE date storage(on tbsp_l_shipdate, section(10), stat none),
L_COMMITDATE date storage(on tbsp_l_commitdate, section(10), stat none),
L_RECEIPTDATE date storage(on tbsp_l_receiptdate, section(10), stat none),
L_SHIPINSTRUCT char(25) storage(on tbsp_l_shipinstruct, section(10) ,stat none),
L_SHIPMODE char(10) storage(on tbsp_l_shipmode, section(10), stat none),
L_COMMENT varchar(44) storage(on tbsp_l_comment, section(10), stat none)
);
列存储表创建过程中,需要将每列对应到相应的表空间中,并设定列区大小(列镞个数),列区大小是指将表空间分为几个列区,一批数据存储在一个区中,区中记录有最大值,最小值。列存储的存储特点,最明显的重要好处之一,就是由于查询中的选择规则是通过列来定义的,每个区描述项中都存储了区数据中的最大值及最小值,并且每个列的数据都是连续存储,因此整个列存储表的每个列是自动索引化的。
表空间和相应的列表创建完毕后,我们测试导入性能。本次测试中,DM7 的设置参数与前次测试保持一致,本次导入的时间分别如下:
Table | 文件大小 | DM7 列存储 | DM7(无索引) | DM7 (主键聚集索引) |
Supplier | 13.6 M | 3 | 1.166秒 | 4秒 |
Part | 234 M | 100 | 38.700秒 | 52秒 |
Customer | 236 M | 36 | 39.130秒 | 47秒 |
Lineitem | 7.29 G | 2759 | 1030.804秒 | 1421秒 |
Nation | 3 K | 1 | 34.556(ms) | 130(ms) |
Region | 1 K | 13(ms) | 29.790(ms) | 110(ms) |
Orders | 1.64 G | 674 | 247秒 | 371秒 |
Partsupp | 1.12 G | 304 | 179秒 | 288秒 |
从上述测试的数据来看,数据导入速度相比较行存储的格式来看速度更加的缓慢,原因是由于数据导入需要同时写入好几个表空间中,增加了磁盘的I/O。为了得到更好的性能,建议将列存储的表空间分散到各个磁盘中。
${PageNumber}四、达梦数据库DM7 优化
达梦数据库DM7提供了性能监视工具来查看DM7数据库的性能情况。DM7性能监视工具包括以下功能:
1. 统计分析
统计分析主要是对服务器的物理资源进行了监控,通过点击页面可以看到目前DM7数据库中的内存、I/O、SQL等一些执行情况的趋势图,通过点击相应的选项就能看的系统的实时运行状况,由于操作比较简单,本文中不对此进行详细描述。
2. 性能监视
在性能监视标签页中,列举了如下图所示的功能列表,可以监控数据库中资源的利用情况。在本次压缩测试中,我们通过其中的存储监控来对表空间的利用情况进行测试。
DM7中,可以通过以下两种方式来对表进行压缩,一种方式是通过设置DM.INI中的COMPRESS_MODE 进行对表进行压缩,0为默认不压缩,1默认为压缩。另一种方式通过建表语句实现,在建表过程中加上COMPRESS参数也能实现表压缩的效果。
我们用PARTSUPP表来进行测试,分别测试行存储和列存储情况下的压缩比例:
(1)列存储下压缩和非压缩对比
列存储 | 非压缩表 | 压缩表 | 列存储大小 |
Partkey | 32% | 32% | 100M |
Suppkey | 32% | 13% | 100M |
Availqty | 32% | 19% | 100M |
Supplyeast | 31% | 12% | 200M |
Comment | 97% | 19% | 10000M |
从上表中计算数据可得,非压缩情况下,PartSupp一共占用了约9858M,压缩后,占用空间为1988M。
(2)行存储压缩情况
行存储 | 非压缩表 | 压缩表 |
TPCH | 4.399% | 3.55% |
在行存储结构中,TPCH表空间大小为30G,非压缩表占用空间为13197M,压缩情况下占用了10650M。从以上数据的对比中我们可以看出,在列存储的情况下,能获得较大的压缩比例,从而减少空间的占用。
3. 调优向导
对于数据库来,性能调优往往是DBA的日常工作之一,与其他数据库的优化不同的是,DM7提供了丰富的性能调优工具,在调优向导页面,我们可以看到以下调优选择:
但是在本次测试中,性能瓶颈分析与调优向导以及索引优化向导均未能提供有效的帮助以及提示,希望达梦厂商进一步对此项功能进行更新、优化。
五、小结
经过这次测试,我们对达梦数据库DM7已经有了初步的印象,安装比较简单,熟悉SQL SERVER或者ORACLE的人很容易上手,且安装时间较短,启动方便。
首先数据导入方便,通过调试相应的参数以及设置,能较快的导入数据,经过调试,导入的性能和SQL SERVER差不多,能满足数据导入导出的要求。
其次,达梦数据库所宣扬的支持数据的列存储形式,在本次测试中具有较好的表现,能对列存储进行较大的压缩比例。
达梦管理工具界面也是其一大亮点,有利于编写应用程序的开发人员更好地利用数据库,也便于管理员提高数据库管理效率。
但是在本次测试中,我们也发现达梦数据库DM7有以下问题:
数据库服务的不稳定性,较大事务的处理容易导致数据库服务的崩溃,在本次测试中发现,达梦数据库在处理TPCH查询语句时,容易出现执行卡住的情况,需进一步的改善数据库服务的性能以及相应的处理机制,避免这种情况的发生。
相应功能不完善,虽然达梦在图形化工具中提供了很多功能,但是优化功能并不是很完善,其中部分功能仍然存在报错的情况,需加强功能开发。
总的来说,达梦数据库为国产数据库中较为优秀的数据库,虽然性能和使用程度上与SQL SERVER 2012相比仍然有一些差距,但是相信经过不断的发展,达梦数据库能赶上ORACLE等国外厂商,在数据库市场上拥有一席之地。