技术开发 频道

四款主流列式数据库横评

  三、功能比较

  各种数据库提供的主要功能在前面的文章中有过详细介绍,这里简述一下它们有区别的地方。

  1. 对SQL标准的支持

  SybaseIQ对SQL标准的支持程度较高,具备其他列式数据库不具备的建立索引和主键功能。其他列式数据库还不支持分析函数和group by cube等扩展语法。

  2. 数据库指定数据存储位置

  我们在安装过程中特别关注能否改变数据存储位置,因为一般Linux系统的/usr/local空间很有限,主要用于保存软件的二进制文件,而用户数据需要保存在其它位置,现在我们看到,各种数据库都具备了这方面的能力。无论是通过配置脚本、操作系统系统命令或SQL语句,都能最终完成任务。如果是不支持软连接的Windows操作系统,InfiniDB的存储位置在安装后不可改变,因此要特别注意将软件安装到空间较大的硬盘分区。

  3. 数据加载错误处理

  默认情况下,如果数据加载时错误Sybase IQ会报错并中止导入,所有数据回滚,而Infobright和InfiniDB会忽略错误继续导入。Sybase IQ也可以忽略错误继续导入,但需要在Load脚本中加入ON FILE ERROR CONTINUE语句。

  4. 数据库空间扩展

  Sybase IQ、Infobright和InfiniDB都可以自动自动增长,SybaseIQ 还可以人工创建和维护数据库空间,并支持裸设备。

  四、性能测试

  测试项目包含三方面,第一是加载,数据仓库要处理的数据量巨大,数据加载能力是选择数据库软件要考虑的重要因素之一,我们将测试包括外部文本数据加载和从数据库内部抽取部分数据到其他表的性能。第二是压缩,数据压缩时常被作为列式存储数据库的一个卖点来宣传,因此我们单独把它拿出来测试。由于多数数据库没有单独的表压缩命令,都是依靠参数指定是否压缩或根本无法指定不压缩(Sybase IQ),只测试压缩后的占用空间对原始外部文件的压缩率。第三是测试重点,数据查询,分别采用tpc-h scala=10,SSB (星型模式基准)scala=10数据作全表分组查询。

  (一) 数据加载

  1. 从外部文本文件导入

  4种数据库分别采用各自推荐的最快的导入方式。Oracle用sqlldr直接路径加载,Infobright用自带的加载引擎使用load data命令。InfiniDB利用cpimport 采用8个读入和写入进程的参数,Sybase利用前面介绍的Load table方式。为了解决末尾一个列分隔符的问题,利用了命名管道,这个转换的负担很轻,基本不影响导入速度。

  Gzip解压缩“管道”的负担对数据加载而言很轻,因为此时解压缩无论是消耗的CPU还是I/O比起文件加载到数据库都不是瓶颈。如果实际工作中经常需要将大量数据搬移到另一台机器使用,采用gzip格式是个很不错的选择。采用并行gzip工具pigz可以充分利用cpu资源大幅度提升压缩速度。

[oracle@redflag11012501 oradata]$ gzip --stdout -d /user1/app/oradata/hui1.csv.gz > /user1/app/oradata/hui_np.txt &
[1] 7993
[oracle@redflag11012501 oradata]$ date;sqlldr rk/RK control=/user1/app/oradata/hui_sqlldr.ctl streamsize=8192000 direct=true;date

  InfiniDB只支持外部数据数据来源被重定向到STDIN标准输入,而不支持其它的命名管道,另外3种数据库都支持命名管道方式。不过cpimport是一个独立的可执行文件,而不需要用命令行工具登录后再执行内部命令,不支持命名管道也不是什么大问题。

[root@redflag11012601 bin]# cat /user1/app/data/lineitem.tbl | tr -d "\r" | /usr/local/Calpont/bin/cpimport -j 5 -fSTDIN -r8 -w8

[root@redflag11012601 bin]# gzip --stdout -d /user1/app/hu.csv.gz |/usr/local/Calpont/bin/cpimport -j 1 -fSTDIN -r8 -w8

  由于原始数据当中存在一些不是数字的非法值,导入SybaseIQ失败。我们在Sybase IQ导入整数类型的HUI表时也采用了命名管道,与前一个转换相比,这个awk转换大大降低了加载速度,时间达到11118.569秒,缺乏可比性,因此利用Sybase导出此表的文本文件,重新导入再计时。其他数据库都是利用Sybase导出的文本文件加载的。

  Infobright不知何故,当数据加载引擎设为Infobright的文本方式(set @BH_DATAFORMAT='txt_variable')时,导入SSB数据集某些表总是出错,但最大的lineorder表反而能够导入成功,因此其它小表采用mysql加载引擎加载,速度稍慢,但总时间影响不大。由于ren表记录实在太多,原始数据又带有一些不是整数的非法值,因此没有在Oracle和SybaseIQ中进行字符到整数类型的转换,依靠hui表已经足够说明问题。

  对于RK数据集,Infobright在利用Infobright加载引擎并关闭自动提交的情况下,仍然比其他数据库慢很多,耗费时间大约是InfiniDB的4到5倍,原因是它的高压缩比要耗费大量的CPU等资源,拖累了导入的性能,如果它能适当地在压缩比和时间之间取得一个平衡,就更实用了。

5
▲各种数据库加载外部文本文件时间 (单位:秒)

  把上述数据制作成统计图如下:纵坐标是时间,单位:秒。

5

  我们看到对TPC-H数据和SSB数据,Sybase IQ的导入时间最短,对于用户自定义数据,InfiniDB的导入时间最短,Oracle的sqlldr导入一般不如列存储数据库,除了自定义数据集,但Oracle的导入时间不包括数据压缩,若指定导入压缩表,则时间大大增加,不如导入完成以后在数据库中并行转换为压缩格式来得高效。对于Infobright和InfiniDB,导入列类型为整数的表速度更快,而SybaseIQ则不是,对rk的hui表平均比字符类型的hu表慢50%。

  SybaseIQ不但从外部文本格式文件导入文本表比导入整数类型更快,导出也是同样的结果,看来它的数据类型转换的开销还真的很大。

2
相关文章